在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。 (上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate) 昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队 ...
上图是今天出问题期间Web服务器性能监控图,紫色表示的是Request Execution Time 昨天我们发布了一篇博客分享了我们这两天遇到的OCS 开放缓存服务 问题,详见云计算之路 阿里云上:愚人节被阿里云OCS愚。 后来,阿里云确认了问题的原因:在OCS升级过程中造成了写入的缓存数据过期时间丢失,只需删除这些有问题的缓存数据就不会再出现这个问题。 今天一大早访问低峰的时候,我们进行了清 ...
2014-04-02 14:19 3 2645 推荐指数:
在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。 (上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate) 昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队 ...
今天中午我们在 docker swarm 集群上发布应用时遇到了一个奇怪的 docker swarm 内置负载均衡的问题,该应用的 2 个新容器成功启动后,在容器内访问正常,但通过服务名访问时一会正常一会缓慢或超时,似乎 docker swarm 内置负载均衡与其中某个容器的网络通信有问题 ...
今天下午访问高峰的时候,主站的Web服务器出现奇怪的问题,开始是2台8核8G的云服务器(ECS),后来又加了1台8核8G的云服务器,问题依旧。 而且3台服务器特地使用了不同的配置:1台是禁用了虚拟内存的临时磁盘云服务器,1台是启用了虚拟内存的临时磁盘云服务器,1台是禁用了虚拟内存的云盘云服务器 ...
在昨天针对“黑色30秒”问题的分析中,我们猜测Requests Queued上升是由于正在处理的请求出不去(到达不了客户端)。今天我们结合IIS日志验证这个猜测。 IIS日志中有一个重要的指标——time-taken,time-taken不仅包含了请求在服务端执行的时间,还包含了响应的内容 ...
今天下午15:11-15:13间出现了类似“黑色30秒”的状况,我们用强大的IIS日志分析工具——Log Parser Studio进行了进一步的分析。 分析情况如下—— 先看一下Windows性能监视器中的问题表现: 然后用Log Parser Studio分析07:11:55与07 ...
在这篇博文中,我们抛开对阿里云的怀疑,完全从ASP.NET的角度进行分析,看能不能找到针对问题现象的更合理的解释。 “黑色30秒”问题现象的主要特征是:排队的请求(Requests Queued)突增,到达HTTP.SYS的请求数(Arrival Rate)下降,QPS(Requests/Sec ...
针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到 ...
12日开始使用阿里云OCS的(详见云计算之路-阿里云上:用上了开放缓存服务OCS)。OCS是保证网站性 ...