当服务器负载高时，应当遵循从上到下，从整体到局部的排查思路，才能快速定位问题的根源。
第一步:确认负载情况
使用uptime或者top命令，查看系统负载情况，重点关注1分钟，5分钟，15分钟三个值
1.如果1分钟的负载远高于15分钟的负载，说明负载是近期突然飙升的，有可能是突发任务或者是攻击。
2.如果是15分钟的负载也很高，则说明系统已经高负载运行了一段时间了。
通过读取到的系统负载与cpu的核心数做对比，如果系统负载持续的超过了cpu的核心数，说明系统存在严重的性能瓶颈，大量的进程在等待cpu资源
第二步：等位问题类型
1.继续使用top命令进行分析：
重点关注一下几个值
us (user space)：用户态 CPU 占用高，说明是应用程序本身消耗了大量 CPU，比如死循环、大量计算。
sy (system space)：内核态 CPU 占用高，说明是系统调用频繁，通常与 I/O 操作或内核模块有关。
wa (I/O wait)：I/O 等待占用高，这是最明确的信号，说明磁盘 I/O 或网络 I/O 存在严重瓶颈，CPU 在等待 I/O 操作完成。
si (softirq)：软中断占用高，通常与网络收发包量巨大有关。
第三步：深入分析定位问题根源
如果是 CPU 密集型问题：
我会继续使用 top，按 P 键按 CPU 使用率排序，找到占用 CPU 最高的那个进程。
如果这个进程是 Java、PHP 等应用，我会联系开发人员，并可能使用 jstack (Java) 或 strace 等工具进一步分析该进程在做什么，看它是不是陷入了死循环或在进行大量计算。
我也会用 perf top 来实时分析内核和用户空间的函数调用热点，精确定位是哪个函数消耗了 CPU。
如果是 I/O 密集型问题：
我会使用 iotop 或 pidstat -d 1 来直接找出哪个进程在进行大量的读写操作。
我会检查这个进程相关的业务逻辑，比如是不是在进行大量的数据读写、日志写入或者备份操作。
我还会用 iostat -x 1 来查看具体是哪块磁盘的 %util (利用率) 接近 100%，确认物理设备的瓶颈。
如果是内存密集型问题：
top 按 M 键按内存排序，找到占用内存最多的进程。
我会检查 dmesg -T | grep -i oom，看看系统最近是否发生过 OOM (Out of Memory) Killer，这能直接告诉我哪个进程因为内存耗尽被内核杀死了。
我会分析这个进程是否存在内存泄漏，并通知开发进行排查。”
