云计算之路-阿里云上:服务器CPU 100%问题是memcached连接数限制引起的

非常抱歉,昨天的服务器CPU 100%问题是达到 memcached 的连接数限制引起的,不是阿里云服务器的问题。

之前我们用的是阿里云“云数据库 memcached 版”,上个周末我们换成了自己搭建——基于阿里云“内存网络增强型”服务器用 docker 跑 memcached 。

docker run -d --net=host --restart unless-stopped memcached -m 15360

但我们在部署 memcached 时没有设置 conn-limit 参数(默认值是 1024) 。

由于周一周二两天服务器没出现问题,而且周二的访问量超过了上周的最高,我们误以为这次 memcached 的部署调整没问题。而没问题的背后是因为周一周二的web服务器数量比昨天少,刚好没达到 memcached 的连接数限制。

昨天(周三)我们收到 1 台服务器的 CPU 报警后,多加了 1 台服务器,刚好让 memcached 的连接数达到了临界值,在下午并发连接数上去后,很容易触发 memcached 的连接限制,web 服务器因无法使用缓存而让 CPU 不堪重负。在这样的情况下,减服务器反而是有利的,而我们慌乱之下依照 CPU 负载高就加服务器的错误直觉操作则是雪上加霜。。。

当今天上午再次有服务器出现 CPU 100% 问题时,我们才想到 memcached 的连接数限制

STAT max_connections 1024
STAT curr_connections 960

赶紧将 max_connections 由默认的 1024 修改为 2048

docker run -d --net=host --restart unless-stopped memcached -m 15360 -c 2048 && docker stop 51bd3b240ede

之后 CPU 100% 的问题就解决了

STAT max_connections 2048
STAT curr_connections 1232

非常抱歉,由于我们在处理故障时不够冷静、考虑不周,给您带来了麻烦,请您谅解。

我们会吸取教训,提高我们在处理故障时的判断与定位能力。

原文地址:https://www.cnblogs.com/cmt/p/8572862.html

时间: 2024-08-03 21:42:35

云计算之路-阿里云上:服务器CPU 100%问题是memcached连接数限制引起的的相关文章

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:奇怪的CPU 100%问题

这篇博文记录一下6月1日在阿里云上遇到的奇怪的CPU 100%问题,希望多年以后能真相大白. 那天负载均衡(SLB)中只放了1台云服务器(平时都放2台),由于是节假日,虽然只放了一台,但这台服务器的负载也没有平时高.但在上午的时候突然出现了CPU 100%问题,然后切换到另外一台云服务器恢复正常. 下午的时候,我们将负载又切换回那台出问题的服务器,正常运行一段时间后,CPU又飙到100%.切换回之前正常的那台服务器后又恢复正常. 对比两台服务器,虽然那台正常的服务器CPU波动也挺大,但即使偶尔串

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload

程咬金有三板斧,我们有三招.在这篇博文中我们要出第三招,同时也意味着昨天在"希望的田野"上的第二招失败了. 前两招打头(CPU)不凑效,这一招要换一个部位,但依然要坚持攻击敌人最弱(最忙最累)部位的原则.那除了CPU,最忙最累的部位是哪里呢?对于Web服务器来说,毫无悬念,当然是网卡.而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它,RDS(数据库服务)也用它.所以,就对它出招! 招式受这篇博文(XenServer – Wind

云计算之路-阿里云上:因为网络问题,物理机换回虚拟机

今天早上7:00开始的从阿里云虚拟机到物理机的切换(详见切换至物理机验证“黑色1秒”是否与虚拟机有关),由于遭遇阿里云网络问题提前结束,14:38更改了DNS解析将流量切换回虚拟机. 网络问题是我们在14:30左右发现的,当时用浏览器打不开网站.用Firefox测试,显示连接超时. Ping发现很多丢包: 780 packets transmitted, 737 packets received, 5.5% packet loss round-trip min/avg/max/stddev =

云计算之路-阿里云上-容器难容:容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队

http://www.cnblogs.com/cmt/p/3682642.html 针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到这样的线索——在什么条件下会触发请求排队? 我们在性能监视器中增加了1个监视指标——\HTTP Service Reques

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进