这篇博文记录一下6月1日在阿里云上遇到的奇怪的CPU 100%问题，希望多年以后能真相大白。 那天负载均衡（SLB）中只放了1台云服务器（平时都放2台），由于是节假日，虽然只放了一台，但这台服务器的负载也没有平时高。但在上午的时候突然出现了CPU 100%问题，然后切换到另外一台云服务器恢复正常 ...

一周的万里无云是我们的第一个目标，这周天气情况好转，但昨天/今天下午依然有乌云飘过。 昨天下午16:40~16:48左右，博客站点的两台Web服务器突然出现CPU坐过山车的波动情况。 今天下午14:26~14:32左右再次出现CPU坐过山车的波动情况，之后又出现了几次短时间的波动 ...

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

本来美美地想着用阿里云的磁盘快照功能进行发布程序的版本管理。 将程序放在一个单独的数据磁盘中，每次发布前创建一个快照，如果发布后出现问题，立即回滚快照。 可是后来发现回滚快照时，竟然要将整个云服务器关机，美好的想法就这么破灭了。。。 了解了一下AWS，回滚数据磁盘快照并不需要将整个EC2关机。 ...

今天下午14:30左右开始，不知道怎么回事，博客站点负载均衡中的web服务器轮番CPU 100%。平时访问高峰5台服务器就能稳稳支撑，而今天发现CPU出现100%问题后就开始加服务器，结果到目前加到了9台，也无济于事，只是从5台服务器轮番CPU 100%变成9台服务器轮询100%。 非常抱歉 ...

非常抱歉，今天 10:05-10:20 左右，我们用阿里云服务器搭建的 docker swarm 集群又出现故障，又是因为突然的节点 CPU 波动。 受这次故障影响的站点有 闪存，博问，班级，园子，短信息，招聘，小组，网摘，openapi ，由此给您带来很大的麻烦，请您谅解。 故障前先是有一个 ...

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

今天上午 10: 40 左右，我们所使用的阿里云 RDS 实例的 CPU 突然飙高到近 100% ，造成大量数据库查询操作缓慢、超时，在这个恶劣条件下大量 memcached 缓存无法建立，这样的雪上加霜让 Web 服务器的 CPU 跟着不堪重负，于是要么访问缓慢，要么直接 503 。。。造成 ...