系统排障基础

复习定位

系统出了故障——不要盲目重启——而是按步骤收集信息、隔离原因、解决问题。CPU高不一定只有换代——可能是死循环；内存不足不一定是物理内存不够——可能是内存泄漏。掌握一套系统化的排障方法论比背参数有用。

系统排障的第一步——看整体

uptime——系统运行时间、当前登录用户、三个负载平均值(1/5/15分钟)。CPU密集任务、I/O密集任务和大量进程排队都会导致负载升高。

dmesg | tail -20——查看内核环形缓冲区的最近日志——内存耗尽(OOM Killer杀了哪个进程)、硬盘I/O错误、文件系统错误都记录在这里——排查硬件相关故障的第一站。

journalctl -xe——以增强格式显示systemd日志的最后条目——系统服务的崩溃和错误信息——加-u nginx.service只查看特定服务的日志。

CPU问题

top看%us(用户态)/%sy(内核态)/%wa(I/O等待)/%id(空闲)。%us高一般是应用层有进程在死循环——按P可以排序出CPU最高的进程。%sy高说明进程在内核态消耗大量CPU——通常由系统调用频繁——strace -c -p PID查看是什么系统调用最耗时。%wa高说明CPU大量等待磁盘I/O完成——瓶颈在磁盘或存储控制器。

perf top——实时显示内核和用户中CPU消耗最多的函数——定位热点代码在哪个函数内部。

内存问题

free -h——available是实际可用的自由选项。如果available接近0而且used持续增长——可能内存泄漏。top按R看(或htop按F6选PERCENT_MEM)按内存占用排序——观察进程所占RSS是否随时间增长。

vmstat 1——si(swap in)和so(swap out)列大于0——说明物理内存不足——系统频繁换出和换入内存页到交换区磁盘——性能急剧下降——需要立即关闭部分非关键进程扩容内存。

磁盘问题

df -h——查看文件系统使用率——当Use%达到100%——日志程序立即写不了新文件而崩掉。du -sh /path/to/directory——递归统计目录大小——再用du -ah / | sort -rh | head -10找到系统中最大的10个文件或目录——确认是否可能删除旧日志、清理临时文件。

lsof | grep deleted——文件已被删除——但仍有进程持有打开的文件句柄→磁盘空间未真正释放。找到该进程PID→重启进程即可回收空间。

iostat -x 1——%util接近100%说明磁盘处于负荷上限——如果响应时间(await)超过设备I/O能力——可考虑升级硬件(SSD、RAID卡或增加磁盘数量分摊负载)。

网络问题

ss -tuln——查看监听端口和对应服务进程。ss -tan state time-wait | wc -l——统计TIME_WAIT连接数——大量TIME_WAIT可能导致端口资源耗尽。

ping/traceroute/mtr——测试连通性和网络延迟。

复习检查

1. 系统load average值超过了CPU核心数两倍——但CPU的%us并不高(小于20%)——最可能是什么原因——是不是大部分进程在等待I/O(磁盘/网络)——iowait指标在top里应该显示什么值？

2. free -h输出的available列和free列有什么区别——available包括可回收的缓存(buffer/cache)——free是完全未分配的内存——当free接近0但available还有不少时——是内存不足吗？

3. OOM Killer杀进程时——从dmesg中如何看到它——输出信息包含哪些内容(被杀进程的PID、oom_score、占用内存等)——能否设置程序不轻易被杀死(oom_adj)？

4. strace -c -p PID——查看系统调用频率——发现read系统调用次数极多但返回很快——可能是程序在不停地循环读取小数据——这种场景如何优化为一次大块读取以减少用户态/内核态切换？

5. df -h显示磁盘有大量剩余空间——但新文件创建时却报"No space left on device"——可能的原因是什么(inode耗尽——df -i检查inode使用情况)？