非常抱歉,这次故障给您带来麻烦了,请您谅解. 今天早上 10:54 左右,我们所使用的数据库服务(阿里云 RDS 实例 SQL Server 2016 标准版)CPU 突然飙升至 90% 以上,应用日志中出现大量数据库查询超时的错误. Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired. The timeout period elapsed prior to completion of the

问题描述 2020年7月13日一大早收到告警,测试环境数据库CPU告警. 登录aws查看监控如下图   问题分析 出现这种cpu 100%的问题,都是因为sql性能问题导致的, 主要表现于 cpu 消耗过大,有慢sql造成.慢sql全表扫描,扫描数据库过大,内存排序,队列等等 并发现写入相对于查询来说比较高(这是一个关键点) 有了大概的思路下边开始排查吧   查看进程 show full processlist; 发现有大量的语句状态为 sending data sending data: sq

悄悄地它又突然来了 -- 数据库服务器 CPU 100% 问题,上次光临时间是 3-30 8:48,这次是 4-28 9:41. 这次我们做出了快速反应,发现后立即进行主备切换,这次一次切换成功,CPU 很快恢复正常. 但是,这次来的"真"是时候(访问高峰),虽然数据库 CPU 恢复正常,但高并发下的博客站点在数据库恢复后来不及建缓存,大量请求503或者访问缓慢,估计今天整个上午都扛不住. 幸运的是,我们估计错了,10:15左竟然抗住了,博客站点开始恢复正常. 但是,就在我们准备发布故

13:52-14:03,由于访问量突增,博客web服务器全线CPU 100%,造成博客站点不正常访问,由此给您带来麻烦,请您谅解. 为了迎接访问量的增长给web服务器CPU带来的巨大压力,上周我们已经将博客web服务器换成了阿里云独享型服务器. 今天下午故障前,博客站点一共投用了3台4核8G+1台8核8G阿里云服务器. 13:50左右,为了防止4台服务器撑不住,我们使用阿里云的弹性伸缩服务,创建了一个根据CPU占用情况自动增加服务器的“报警任务”. 哪知刚创建完,访问量就突增上去了,负载均衡中有

非常抱歉,今天下午14:40-15:00左右,web服务器突然雪崩似的出现CPU 100%问题,造成博客站点无法访问(503).由此给您带来很大的麻烦,请您谅解. 在问题出现之前,博客站点运行着5台web服务器,4台4核8G的阿里云-计算型(原独享)sn1系列II-服务器,1台8核8G的阿里云c1型系列I服务器.本来今天下午并不是一周的访问最高峰,这5台服务器绰绰有余.但14:40左右开始,某种未知的情况引起这5台服务器雪崩似的接连地出现CPU 100%.雪上加霜的是,倒下去的服务器没能很快地站

非常非常抱歉,今晚 19:34 ~ 21:16 园子所使用的阿里云 RDS 数据库服务器突然出现 CPU 100% 问题,造成全站无法正常访问,由此您带来了很大的麻烦,请您谅解. 故障经过是这样的.19:34 这个时间点本来是一个访问低峰,数据库压力比访问高峰时低很多,但数据库服务器却异想天开.吃饱了撑着地让自己的 CPU 满负荷工作(到现在我们都没想通,难道是服务器晚饭吃多了想帮助消化?).开始我们以为是某个应用引起的,一个一个应用排查与重启, 但 CPU 不为所动,依然百分百.接着,我们一边

今天上午11:10,我们又中"奖"了,我们使用的阿里云 RDS 实例(SQL Server 2016 标准版,16核32G)突发出现 CPU 100%,引发全站故障,直到 12:15 才完全恢复,由此给您带来很大的麻烦,请您谅解. 这是我们今年的第3次中"奖",前2次分别发生在 2020-06-24 3:20~8:30 (详见故障公告)与 2020-08-20 20:55~21:14(详见故障公告). 相比前2次,这次中了一个大"奖",发生在访问

今天 11:12-12:03 期间,园子使用的阿里云 RDS 实例(SQL Server2016 标准版,16核CPU)出现 CPU 100% 问题,引发全站故障,由此给您带来麻烦,请您谅解. 发现故障后,我们进行了 RDS 的主备切换,第1次切换失败,再次进行主备切换,再次失败,改为重启实例后才恢复正常. 上次出现同样问题是在2021年5月1日,详见 [故障公告]访问高峰数据库服务器 CPU 100% 引发全站故障

今天五一劳动节的一大早 5:50-6:30 期间,我们使用的阿里云 RDS SQL Server 数据库实例再次出现 CPU 100% 问题,引发全站故障,由此给您带来麻烦,请您谅解. 我们发现故障后立即进行主备切换,与上次故障不同的是,这次主备切换没有成功,再次切换,依然没有成功,后来尝试重启实例,重启后恢复正常. 上次故障发生于4月28日上午,两次故障相隔如此之近之前很少遇到,我们最近会密切关注数据库的运行状况.

非常抱歉,昨天的服务器CPU 100%问题是达到 memcached 的连接数限制引起的,不是阿里云服务器的问题. 之前我们用的是阿里云“云数据库 memcached 版”,上个周末我们换成了自己搭建——基于阿里云“内存网络增强型”服务器用 docker 跑 memcached . docker run -d --net=host --restart unless-stopped memcached -m 15360 但我们在部署 memcached 时没有设置 conn-limit 参数(默认

昨天客户反馈业务系统很慢,而且偶尔报错. 查看nginx日志: [root@s2 nginx]# tail log/error.log 2017/03/14 12:54:46 [error] 17042#17042: *9305256418 upstream timed out (110: Connection timed out) while reading response header from upstream 看来是请求超时了.再查看nginx.conf配置,读取时间已经设置得比较长了

非常抱歉,今天 8:48 开始,我们使用的阿里云 RDS SQL Server 数据库实例突然出现 CPU 100%  问题,引发全站故障,由此给您带来麻烦,请您谅解. 发现故障后立即进行主备切换,和往常一样,第1次主备切换失败,第2次主备切换完成后恢复正常. 上次同样故障发生在2020年11月3日,详见 [故障公告]访问高峰数据库服务器 CPU 100% 引发全站故障 阿里云 RDS CPU 100%  问题,不知为何,不知何时,但每年总要发生几次,至今仍是未解之谜.

非常抱歉,今天下午14:20-14:55期间,由于同一个负载均衡中的2台服务器都出现CPU 100%问题,造成博客后台无法正常访问,由此给您带来了很大很大的麻烦,请您谅解. 博客后台是CPU消耗很低的应用,这2台服务器通常CPU占用在5%左右,之前从来没有出现CPU 100%的问题(所以连云监控都没添加CPU监控报警).这次问题很突然,我们发现问题后,远程连接不上服务器,只能重启,重启后立马恢复正常. 对于问题的具体原因,目前还没找到.我们正在进一步排查,也反馈给了阿里云,阿里云也在排查.

今天下午14:30左右开始,不知道怎么回事,博客站点负载均衡中的web服务器轮番CPU 100%.平时访问高峰5台服务器就能稳稳支撑,而今天发现CPU出现100%问题后就开始加服务器,结果到目前加到了9台,也无济于事,只是从5台服务器轮番CPU 100%变成9台服务器轮询100%. 非常抱歉,由此给您带来麻烦,请您谅解.当您打开页面很慢或者出现503错误,就是因为所访问的服务器当时CPU 100%.

系统导出数据到excel,数据量过大(大约10W)条,导致服务器 cpu 100%解决方法

昨天 22:00~22:30 左右与 23:30~00:30 左右,有1台服役多年的阿里云负载均衡突然失灵,造成通过这台负载均衡访问博客站点的用户遭遇 502, 503, 504 ,由此给您带来麻烦,请您谅解. 问题非常奇怪,从表现看,似乎负载均衡与后端服务器之间的内网通信出现了问题.有时健康检查成功,但转发请求到后端服务器会失败:后端服务器明明正常,有时健康检查却失败:最糟糕的时候,所有后端服务器都健康检查失败.而其他使用同样后端服务器的负载均衡都没出现这个问题,最终通过下线这台负载均衡解决了

背景: 突然有一天,服务器访问很慢很慢,进程查看发现CPU是100%,而且没有任何降低的意思 收集: 打开任务管理器,进程查看中CPU排序,发现一个System的进程,第一想法以为是空闲利用,发现结束掉之后瞬间又起来的 查了下描述中写的“Xmrig miner ”,全是挖矿病毒,试了好几个方法,不行 整理: 自动重启,大概率是病毒,描述中写的“Xmrig miner ” 最后,进程中右键--属性--安全--编辑权限-拒绝,结束进程后,再未重启 汇总: [Xmrig miner ]CPU 100%

Linux系统cpu 100%修复案例 ​阿里云技术支持团队:完颜镇江 案例背景: Linux主机连续三天CPU% 处理思路: 1.  登录服务器查看/var/log/messages+/var/log/messages.1+/var/log/messages.3里恰好没那三天的日志 2.  dmesg里也无有用的信息 ​ 3.  至此怀疑是被攻击了,自然而然的去看对应时间点的带宽占用情况,查看之后发现带宽一切正常,继续排查 4.  怀疑是某个程序的异常,首先的从web进程开始查,通过httpd

在任务管理器中看到sql server 2000进程的内存占用,而在sql server 2005中,不能在任务管理器中查看sql server 2005进程的内存占用,要用 以下语句查看sql server 的实际内存占用: select * from sysperfinfo where counter_name like '%Memory%' 其中, Total Server Memory 表示内存占用. select locked_page_allocations_kb  from sys

做一个积极的人 编码.改bug.提升自己 我有一个乐园,面向编程,春暖花开 工欲善其事,必先利其器 00 本文简介 作为一名搞技术的程序猿或者是攻城狮,想必你应该是对下面这两个问题有所了解,说不定你在实际的工作或者面试就有遇到过: 第一个问题:Java死锁如何排查和解决? 第二个问题:服务器CPU占用率高达到100%排查和解决? 第三个问题:有哪些工具能够快速查看线程使用情况? 本文对这三个问题进行总结整理,通过实例演示讲解,精彩干货,不容错过啊! 前戏就这么多,高潮会很多,做好了,让我们直奔主

非常非常抱歉,今天上午的故障又一次给大家带来麻烦了,再次恳请大家的谅解. 在昨天升级阿里云 RDS SQL Server 实例的配置后(详见昨天的博文),万万没有想到,今天上午更高配置的阿里云 RDS 实例依然出现了 CPU 居高不下的问题. 在数据库 CPU 高的情况下,有时对访问速度影响不大,有时巨慢无边,在今天上午的故障期间,我们通过2次主备切换才恢复了正常. 下午,我们我们调整了服务器的部署,用了更多服务器进行混合部署(docker-compose与docker swarm),情况有了明