多人同时登陆某服务器会不会使对方服务器崩溃？

多到一定的程度就会导致服务器死机，就好象我们普通的电脑执行很多程序也会出现死机现象是一个道理，服务器被登陆是消耗内存的，一般服务器的流量应该在一定的允许范围内，这也是为什么有的网站浏览速度快，有的慢，慢的不一定是你自己的电脑带宽不够，可能是服务器不行。所以有的黑客就用一些软件模拟大量的用户登陆某个网站或游戏，导致该网站或游戏的服务器迟钝，直至死机停止工作，也就是你说的崩溃。

centos7服务器突然挂死，接键盘不能输入，网络不通的处理办法如下：
1、检查硬件问题：如果服务器硬件出现故障，例如硬盘故障、内存故障等，可能导致服务器崩溃。您可以检查服务器的硬件状态，例如打开服务器机箱查看硬件状态或者连接远程管理卡查看硬件状态。
2、检查系统日志：您可以查看系统日志，找到服务器崩溃时发生了什么情况，例如有没有出现错误信息或者警告信息。您可以使用命令`journalctl-xe`来查看最近的系统日志。
3、尝试重启服务器：如果服务器没有响应，您可以尝试通过电源按钮或者电源插头来重新启动服务器。
4、进入单用户模式：如果服务器无法正常启动，您可以尝试进入单用户模式，以便进行故障诊断和修复。您可以在启动时选择GRUB菜单，在内核参数后添加“single”或者“init=/bin/bash”参数，以进入单用户模式。

当爬虫爬取网站时，如果请求过于频繁或者请求数据量过大，就有可能会导致网站崩溃。这种情况通常称为“DDoS攻击”，即分布式拒绝服务攻击。在这种攻击中，攻击者利用大量的机器或者网络资源，向目标网站发送大量的请求，使得目标网站无法正常响应合法用户的请求。
在爬虫爬取网站时，类似于DDoS攻击的情况也有可能发生。爬虫的请求量过大或者频率过快，可能会给网站带来较大的压力，从而导致网站崩溃。当网站遭到这种攻击后，服务器可能会因为资源不足而停止响应请求，甚至直接宕机。这样一来，用户就无法正常访问该网站，导致严重的经济和声誉损失。
为了避免爬虫把网站爬崩溃，爬虫需要遵循一定的道德规范和技术规范。例如，爬虫需要限制请求频率，避免在短时间内发送大量请求；同时也需要限制请求数据量，尽量减小对网站的压力。此外，爬虫还应该检查网站的robotstxt文件，遵守网站管理者的《网站协议》。通过这些方法，就可以保证爬虫与网站之间的良好合作关系，使得爬虫在不破坏网站正常运行的前提下，能够顺利地获取所需的数据信息。

一个项目上线了两个月，除了一些反馈的优化和小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才知道爆了。

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

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

文章来自>