如果说2013年云计算之路的主题是“踩坑”，那么2014年我们希望云计算之路的主题变成“填坑”——当然填坑是阿里云来完成的，我们只是见证曾经的坑坑洼洼变成平坦大道。 15号（周四）晚上我们发现了SLB会话保持的坑，16号晚上阿里云成功定位并进行修复，这两天正式发布后会填平这个坑。这次从踩坑 ...

今天下午访问高峰的时候，主站的Web服务器出现奇怪的问题，开始是2台8核8G的云服务器（ECS），后来又加了1台8核8G的云服务器，问题依旧。 而且3台服务器特地使用了不同的配置：1台是禁用了虚拟内存的临时磁盘云服务器，1台是启用了虚拟内存的临时磁盘云服务器，1台是禁用了虚拟内存的云盘云服务器 ...

针对Web服务器“黑色30秒”问题（详见云计算之路-阿里云上：Web服务器遭遇奇怪的“黑色30秒”问题），经过分析，我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况（为什么请求会排队）？ 首先， 通过Windows性能监视器去观察，看能不能找到 ...

在昨天针对“黑色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 ...

云上真是无奇不有，这两天我们什么也没动，“黑色30秒”招呼不打一声就走了，而来了一位不速之客——“黑色1秒”；就写了一篇博文，30秒就变成了1秒，看来多写博客是硬道理。 在上篇博文的评论中有人说——就30秒，有必要这么较真吗——当时想，别说30秒，哪怕1秒，我们也会较真。结果说1秒，1秒就来 ...

为了更好地分享我们解决“黑色1秒”问题的过程，在这篇博文中我们将专门描述一下“黑色1秒”问题的表现。 “黑色1秒”是我们使用阿里云以来继“黑色10秒”之后遭遇的最奇特、最诡异、最难以捉摸、最富有戏剧性的问题。 它有2个最显著的特征： 第一个是最直观的表现，在Windows性能监视 ...