100ms的SQL把服务器搞崩溃了

一个项目上线了两个月，除了一些反馈的优化和小Bug之外，项目一切顺利；前期是属于推广阶段，可能使用人员没那么多，当然对于项目部署肯定提前想到并发量了，所以早就把集群安排上，而且还在测试环境搞了一下压测，绝对是没得问题的；但是，就在两个月后的一天，系统突然跑的比乌龟还慢，投诉开始就陆续反馈过来了。

经过排查，原来是频繁执行一条耗时100ms的SQL导致，100ms感觉不长，但就是把系统搞崩了，具体细节如下。

项目采用ABP进行开发，集成统一的认证中心(IDS4)，部分数据对接第三方系统，拆分后的这个项目架构相对简单。

考虑并发量不高，就算是高峰期也不会超过1000，于是就搞了个单台的数据库服务器(MySQL)，测试环境中经过压测，完全能抗住。

上线时，由于线上资源的关系，DB服务器的配置没有按测试环境的标准来分配，相关人员想着后续看情况进行补配。上线推的比较紧，简单评估了配置风险，初步判断没啥大问题，于是就推上线了。

相关技术栈：ABP、IdentityServer4、Autofac、AutoMapper、QuartzNET、EF Core、Redis、MySQL等，这都不重要，重要的是100ms的SQL把系统搞崩了。

由于系统相对不大，并没有把分布式日志、调度监控，性能监控集成上去。

上线期间，前期处于使用推广阶段，一切正常。两个月后的一天，系统处于使用高峰时段，突然陆续收到反馈：系统有点卡！！！于是赶紧进行排查。

由于系统已经是集群部署的，慢这个问题首先怀疑是数据库服务器，于是让DBA的同事排查了一下，没有锁，只是有大量事务等待提交(waiting for handler commit)，通过如下命令可查的：

看到都是插入审计日志记录导致，一看日志记录频率，差不多一秒500条记录。DBA同事说可能是记录插入频繁导致，此时CPU已经爆到100%了，为了快速解决问题，于是就赶紧关掉了一些不必要的日志记录。

这么一改，稍微降了一点，没有事务提交的记录，系统勉强可以撑着用，但是CPU还是在85%~97%波动；

看到这种情况，当然还是不放心，继续排查。 中间有对服务器的配置产生过怀疑，但非常肯定的是这不是主要原因，于是和DBA的同事继续排查。

系统虽然可以正常使用，但时不时的也看看监控屏，CPU一直处于高水位状态，还是有点慌的，因为一有问题，信息和电话都要爆。

突然DBA同事发现有一个单表查询的SQL执行比较频繁，于是单独拿出来试了一下，查询时间150ms左右，这个表的数据量不大，8万左右，但没有加任何索引，因为想着数据量不大，查询时长还可接受，所以当时就没有加相关索引。

定位到这条SQL后，想到的第一步就是增加索引，在测试环境上试了一把，执行效率直接飞速提高到1ms；效果如下：

所以和DBA同事达成一致意见，在生成环境上增加复合索引( 创建索引一定要注意字段顺序 )，在中午时候，系统使用频率不太高，于是就在生成上快速加了索引，我去，CPU一下降到了20%以内，意不意外；就算在使用高峰期，也没超过20%，通过zabbix工具监控看到CPU的效果：

问题算是解决了，总算松了一口气。

这里有个问题： CPU都爆了为什么没有报警提醒，这块DBA同事正在排查相关配置。这里发现CPU爆了，还是无意的远程到服务器，发现很卡，一看CPU才知道爆了。

系统虽小，问题不大，但其实暴露的问题还是挺多。

这次线上小事故暂时分享到这，因为项目不大，所以没有做那么多监控，但以下建议，小伙伴可以参考一下：

文章来自>

我觉得很有可能是虎牙的服务器出现了问题。

对于虎牙这样的直播企业来讲，现在虎牙和斗鱼基本上是全国两家最大的直播公司，这也就意味着虎牙在整个市场里面占有非常大的份额，当虎牙的服务器崩溃以后，虎牙的很多用户在网上发表了自己的观点。

虎牙的服务器崩溃了。

这一次应该算得上是一个意外事故，当网友在虎牙看直播视频的时候，突然发现画面特别卡顿，这个现象并不是个例，而是所有的用户都发生了这种情况。网友们特别诧异，因为虎牙的服务器一直以来非常稳定，很少出现这样的意外事故，目前官方还没有对这次的服务器卡顿作出正面解释。

这次事故是跟虎牙的服务器有关系。

我们要知道虎牙的服务器其实连接了很多端口，当主播把自己的画面内容传到端口以后，虎牙再通过端口输出到用户的手机上，这就形成了我们经常看到的直播网络。虎牙的画面之所以会出现卡顿的现象，很有可能是跟虎牙的服务器有关系。因为目前虎牙的规模特别大，所以用户的承载量就成了一个巨大的挑战，这对于虎牙来说既是一件好事，同时也是一项艰巨的任务。

希望虎牙的服务器可以尽快修复。

因为用户在观看直播视频的时候，会非常在乎直播的画面和流畅度，如果虎牙的服务器一直出问题，甚至出现画面连续卡顿的现象，这会影响到用户的直播体验。对于虎牙这样的大公司来讲，我觉得修复服务器的问题不是什么难事，希望虎牙可以在这一次的事故中尽快抢修，这样才能够保证用户的正常使用。互联网公司其实经常会出现服务器的问题，作为网友，我们也不需要对这样的事情大惊小怪。

这种情况一般是服务器崩溃导致的

一、导致服务器崩溃的原因有很多。

1访问量超出服务器承载范围，如果登陆一个游戏的人数过多，会导致服务器过载，超出了服务器所能容纳的量，就会让服务器崩溃。

2程序出错，现在很多开发工程师都喜欢用C或C++编写程序，其实如果C指针出现错误的话，是会导致 *** 作系统终止所有程序，间接造成服务器系统崩溃的。

3磁盘已满，服务器磁盘需要定期清理以确保安全和服务器正常使用，当磁盘超出负荷，没有运行空间，也会导致系统无法正常运行。

4服务器被攻击

服务器被攻击造成的崩溃宕机的损失是我们无法估量的。网络攻击我们无法预测，但做好防御措施是必须的。

二、遇到服务器崩溃的解决方法

1打电话询问服务器运营单位，是否是服务器本身的问题。

2查看官方公告，可能是对服务器进行例行维护，过段时间就好了。

3到官方论坛，寻求网友的帮助。

服务器崩溃的几种原因第一：高并发流量或请求超过服务器承受力

无论是企业和个人在租用服务器的时候都会受到峰值承受限制的，一旦超过服务器的承受能力，就会导致服务器瘫痪，应用程序暂停，网站无法访问。服务器都是有峰值限制的，不可能承受无上限的并发能力。而造成服务器瘫痪的原因就是在同一段时间内，访问人数多，造成高流量的突进。超出了服务器的承受范围。这种例子我们经常可以看到，比如双11期间，很多公司为了应对双11的高流量，开启的紧急避险措施和大规模的服务器负载能力。还有春运期间，12306网站由于受到高并发的问题，也会频繁的出现崩溃。

第二：磁盘空间不足

导致服务器无法正常运行的原因也有可能是磁盘空间溢出导致的。企业的网络管理员应该实时关注磁盘的使用情况，并且要在规定的时间把磁盘储存的数据备份到另外的存储设备里面，确保数据无遗失，推荐相关阅读：哪些网站应该使用服务器呢？

服务器的磁盘大部分的资源都是被日志文件占用了，包括web服务器，数据库等日志信息都包括其中，以及应用程序服务器日志文件均与内存泄漏是同等的危害。我们可以采取措施保护我们的数据和日志文件，日志文件对应用程序进行异地存储。日志文件系统空间如果满了，则web服务器将自动被挂起，但是机器本身瘫痪和宕机的几率就会大大降低。

第三：服务器超载

连接web服务器都是用一个线程链接的，web服务器会在线程用过之后自动挂起，不会再未已链接的线程提供任何服务。如果我们用了负载机制，那么如果该服务器没有响应，则该服务器的负载则会自动的转移到其他web服务器上，这个 *** 作会使服务器一个接一个的用光线程。这中 *** 作可能会导致整个服务器机组被挂起， *** 作系统同时还有可能在不断接收新的链接，而我们的web服务器无法未其提供服务，致使服务器崩溃。

第四：服务器遭到恶意攻击

网络科技的不断发展同时，黑客的技术和渗透也是很强的，服务器和系统遭受到攻击已经是普遍存在的了。所有服务器都会面临这个问题，这个是无法预测的危险，我们只能实时做好安全防护，将被攻击的风险降至最低。

---