在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。 (上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate) 昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队 ...
自从 月 日我们从ASP.NET线程的角度对 黑色 秒 问题进行分析之后,我们采用了新的线程设置,然后观察 黑色 秒 是否再次出现。 采用以上设置之后,Requests Queued出现的频率的确少了。之后的几天,也没出现 黑色 秒 。 于是,ASP.NET线程设置问题引起 黑色 秒 的可能性已经提升到了 . ,对阿里云的怀疑只剩下 . 。 但是: . 上次的总结中提到 如果把 黑色 秒 问题归因 ...
2014-05-05 19:41 32 4718 推荐指数:
在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。 (上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate) 昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队 ...
非常非常抱歉!16:30 ~ 17:00 左右我们用于跑 ASP.NET Core 站点的 docker swarm 集群再次出现宕机,由此给您带来了很大很大的麻烦,恳请您的谅解! 受此次故障影响的站点有:博问,闪存,班级,园子,短信息,招聘,小组,网摘,新闻,openapi 故障 ...
为了更好地分享我们解决“黑色1秒”问题的过程,在这篇博文中我们将专门描述一下“黑色1秒”问题的表现。 “黑色1秒”是我们使用阿里云以来继“黑色10秒”之后遭遇的最奇特、最诡异、最难以捉摸、最富有戏剧性的问题。 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视 ...
云上真是无奇不有,这两天我们什么也没动,“黑色30秒”招呼不打一声就走了,而来了一位不速之客——“黑色1秒”;就写了一篇博文,30秒就变成了1秒,看来多写博客是硬道理。 在上篇博文的评论中有人说——就30秒,有必要这么较真吗——当时想,别说30秒,哪怕1秒,我们也会较真。结果说1秒,1秒就来 ...
今天下午访问高峰的时候,主站的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 ...