服务器突然打不开，SSH连不上，网站也没反应，这种情况在阿里云ECS上并不少见。遇到时先别急着重启。重启能让服务暂时恢复，但原因还在，过段时间多半会再卡一次。先弄清楚是哪类资源出了问题，再决定下一步。下面列出常见诱因、两个实际案例和一套排查顺序。
常见原因
实例“死机”时，外部表现大多相似，底层原因却可能完全不同。常见的有以下几类：
- CPU资源耗尽：进程失控或计算任务过重，CPU长期占满，系统连新请求都处理不了。可用top查看占用最高的进程。
- 内存耗尽：内存泄漏或并发过高，会触发系统OOM（Out of Memory）机制，关键进程被内核杀掉，严重时整机卡住。dmesg里能看到相关记录。
- 磁盘写满：日志无限增长、临时文件堆积，数据库和Web服务无法写入，表现为服务异常，严重时系统变为只读。用df -h检查使用率。
- 突发性能实例积分耗尽：突发性能型实例的CPU基线较低，长时间高负载后积分用完，CPU会被限制在基线水平，看上去就像卡住了。在控制台查看CPU积分余额即可确认。
- 网络带宽打满：流量冲击或被刷流量，带宽被占满，SSH和业务请求都会超时。在监控里看带宽曲线是否突然顶到上限。
- 内核或宿主机问题：内核异常、驱动故障或底层物理机出问题。这类情况比较少，通常需要提交工单，由平台侧确认。
案例一：定时任务导致CPU持续100%
某电商团队的一台4核8G实例，每天凌晨开始变慢，两小时后网站无法访问。通过控制台的远程连接（VNC）登录后发现，一个数据清洗脚本被配成每分钟执行一次，而且每次都会启动新进程，不等上一次结束。半小时内进程数从几十个涨到数千个，CPU被占满。
处理时先用top找到异常进程并停止，再把定时任务改为加锁执行，避免重叠。之后在云监控里给CPU设置告警，使用率超过80%并持续5分钟就通知负责人。这类问题之后没有再出现。
案例二：内存不足触发OOM
一位开发者的测试服务器上跑着Java应用和MySQL。压测后，SSH能连上，但响应很慢，应用无法访问。查看dmesg，发现大量OOM Killer记录，MySQL进程被系统强制终止。
原因是JVM堆内存设得过大，加上数据库缓冲池的占用，总量超过了物理内存。把JVM参数调小、降低innodb_buffer_pool_size之后，问题消失。配置合理的swap能缓一缓，但它不能代替容量规划。
案例三：日志写满磁盘
一台运行Nginx的服务器没有配置日志轮转，半年后单个访问日志超过80GB，系统盘使用率到了100%。服务无法写入临时文件，部分进程启动失败。用df -h定位到分区，再用du -sh逐层找大文件，清理后配置logrotate，之后再没有出现过这种情况。
排查步骤
- 先在ECS控制台看实例状态和监控曲线，记下CPU、内存、带宽、磁盘开始异常的时间点。时间点能很快缩小范围。
- 实例仍在运行时，通过控制台的远程连接登录，看系统是否还有响应。完全无响应时，再考虑其他手段。
- 查看/var/log/messages或journalctl，以及dmesg输出，搜索OOM、I/O错误和内核报错。
- 用top、df -h、free -m检查资源占用，确认是哪类资源出了问题。
- 如果是突发性能实例，查看CPU积分余额。积分为零时，CPU被限速，这很可能就是“卡住”的原因。
- 确认无法恢复后，再考虑强制停止或重启。强制操作可能导致数据丢失，重启前先做快照。
- 仍找不到原因时，提交工单，附上监控截图和相关日志，方便平台侧排查底层问题。
预防措施
- 给CPU、内存、磁盘和带宽都配置云监控告警。阈值设得太高，告警就来不及用。
- 定期做快照或备份，出问题时能快速回滚，不必在损坏的系统上硬修。
- 日志配置轮转并设定保留周期，避免无限增长。
- 上线前按业务峰值做容量评估。长期高负载的业务不要放在突发性能实例上。
- 给定时任务和后台进程加上超时和互斥机制，防止进程越积越多。
- 对可用性要求高的业务，用负载均衡加多可用区部署，单台机器故障时不至于整站不可用。
大多数阿里云实例死机都能找到原因。把监控曲线、系统日志和资源指标放在一起看，通常能较快定位问题。重启之前先看这些数据，能保留现场，也更容易找到真正的原因。
