答案：排查Linux高负载需从系统资源入手，先通过uptime、top观察负载与资源使用，再用iostat、vmstat、netstat等工具定位CPU、内存、I/O或网络瓶颈，最后结合strace、lsof、jstack等分析具体进程行为，找出根源。
Linux服务高负载问题，说白了，就是你的系统或某个应用跑不动了，响应变慢甚至卡死。要排查它，核心思路就是从宏观到微观，先看整体系统哪块资源出了问题——是CPU、内存、磁盘I/O还是网络，然后层层深入，找出具体哪个进程或应用是罪魁祸首，最后分析其行为模式。这就像医生看病，先量体温、血压，再根据症状开检查单，最后对症下药。
解决方案
每当我遇到Linux服务高负载，心里其实都会咯噔一下，但经验告诉我，慌是没用的，得按部就班来。我通常会从几个维度入手，一步步缩小范围。
首先，我不会直接跳到某个特定工具，而是先用
uptime和
top（或者我更喜欢的
htop）快速扫一眼全局。
uptime能告诉我系统的平均负载（load average），这三个数字（1分钟、5分钟、15分钟）非常关键，它们代表了等待CPU运行的进程数量。如果这个数字持续高于CPU核心数，那系统肯定是不舒服的。
top或
htop则能实时看到CPU和内存的整体使用情况，以及哪些进程消耗了最多的资源。我特别关注CPU使用率最高的进程、内存占用大的进程，以及
D状态（不可中断睡眠）的进程——这往往意味着它们在等待I/O，是个重要的信号。
如果
top显示CPU使用率很高，我会进一步分析是用户态（us）高还是内核态（sy）高。用户态高通常是应用本身计算密集，内核态高则可能涉及大量系统调用、I/O或驱动问题。这时候，我可能会用
pidstat -u 1来跟踪特定进程的CPU使用情况，或者用
perf top来查看哪些函数在消耗CPU。
如果CPU看起来还好，但系统依然很慢，我就会转向内存。
free -h能快速查看内存和Swap的使用情况。如果Swap大量被使用，那系统很可能在频繁地进行内存交换，性能自然会急剧下降。
top里的
RES（常驻内存）和
VIRT（虚拟内存）也很重要，我会留意是否有进程的
RES异常高，或者是否存在内存泄露的迹象。
vmstat 1可以告诉我内存的
swpd（交换）、
free（空闲）、
buff（缓冲区）、
cache（缓存）以及
si（交换入）、
so（交换出）等详细信息。
再来是磁盘I/O。很多时候，服务慢不是CPU或内存的问题，而是磁盘读写跟不上。
iostat -x 1是我常用的工具，它能显示每个磁盘设备的I/O统计，特别是
%util（设备利用率）、
await（平均I/O等待时间）和
svctm（平均服务时间）。如果
%util接近100%且
await很高，那磁盘就是瓶颈。
iotop可以像
top一样，按进程显示磁盘I/O使用情况，这能帮我迅速定位是哪个进程在疯狂读写。
最后是网络。如果服务是面向网络的，比如Web服务或数据库，网络问题也可能导致高负载。
netstat -tulnpa或
ss -s可以查看当前的网络连接状态，包括监听端口、已建立连接、等待连接等。如果看到大量的
TIME_WAIT或
CLOSE_WAIT状态，或者连接数异常高，那可能就是网络配置或应用处理连接有问题。
sar -n DEV 1或
iftop能监控网络接口的流量，看是否有带宽饱和的情况。
定位到具体资源瓶颈后，我就会根据情况深入到应用层面，比如查看应用日志、使用
strace跟踪进程的系统调用、
lsof查看进程打开的文件和网络连接，甚至是针对Java应用使用
jstack生成线程dump来分析死锁或长时间运行的线程。这个过程往往需要结合对应用业务逻辑的理解，才能真正找到问题的根源。
识别高负载的初期迹象有哪些？
高负载的初期迹象其实很明显，就像人生病前的征兆。最直观的感受就是系统响应变慢，无论是SSH登录、执行命令，还是Web服务访问，都感觉迟钝。我个人最常关注的是
uptime命令输出的load average，也就是平均负载。如果这三个数字（1分钟、5分钟、15分钟的平均负载）持续高于你的CPU核心数，比如一台4核机器，负载达到8、9甚至更高，那肯定有问题了。这意味着有大量的进程在排队等待CPU资源。
除了这个，CPU使用率飙升也是一个强烈的信号，尤其是在空闲时间，如果
top或
htop显示CPU利用率很高，但你并没有运行什么大型任务，那就要警惕了。内存占用异常，特别是频繁的Swap交换，会直接导致系统性能断崖式下跌，因为磁盘I/O远慢于内存访问。你还会观察到磁盘I/O等待时间（I/O wait）增加，这在
top或
vmstat里都能看到，表示CPU花大量时间等待磁盘操作完成。最后，如果服务是网络型的，网络延迟增加或连接数异常高，也可能是高负载的体现。这些迹象往往不是孤立出现的，它们会相互影响，共同构成一个“系统不适”的画面。
CPU、内存、I/O或网络，如何快速定位瓶颈所在？
快速定位瓶颈，我通常会用一套“组合拳”，而不是单一工具。
CPU瓶颈： 我最先看
top或
htop，关注
%us（用户态CPU）和
%sy（内核态CPU）。如果
%us高，说明某个应用进程在忙于计算；如果
%sy高，则可能是系统调用、I/O或内核任务繁重。我会按CPU使用率排序，找出占用最高的进程PID。然后，我可能会用
pidstat -u 1 -p来更细致地观察这个进程的CPU行为，甚至用
perf top -p来分析这个进程具体是哪些函数在消耗CPU。有时候，
dstat也是个好帮手，它能在一个屏幕上同时显示CPU、内存、磁盘和网络的使用情况，便于我快速概览。
内存瓶颈：
free -h是我的第一选择，它简洁明了地告诉我内存和Swap的使用情况。如果Swap被大量使用，或者可用内存非常少，那内存肯定有问题。接着，我会在
top里按
RES（常驻内存）排序，找出内存占用最大的进程。如果发现某个进程的
VIRT（虚拟内存）非常大，但
RES不大，那可能只是申请了大量内存但没实际使用。如果
RES和
VIRT都很大，且持续增长，那很可能存在内存泄露。
vmstat 1可以观察
si和
so（交换入/交换出）的数值，如果这两个值很高，系统正在频繁地进行内存交换，性能会非常差。
I/O瓶颈： 对于I/O，我通常会用
iostat -x 1。这个命令能提供每个磁盘设备的详细统计，我主要关注
%util（设备利用率），如果接近100%，说明磁盘已经饱和了。同时，
await（平均I/O等待时间）也很关键，如果这个值很高，表示I/O请求等待时间长。为了找出是哪个进程在疯狂读写，
iotop是我的首选，它能像
top一样显示进程的读写速度。如果
vmstat的
wa（I/O等待）很高，也指向I/O问题。
网络瓶颈： 当服务响应慢，且CPU、内存、I/O看起来都正常时，我会考虑网络。
netstat -tulnpa或
ss -s可以快速查看当前系统的网络连接状态，比如监听端口、已建立连接数、各种TCP状态（
TIME_WAIT、
CLOSE_WAIT等）。如果连接数异常高，或者有大量处于不健康状态的连接，那可能是问题所在。
sar -n DEV 1能监控网络接口的流量和错误包，
iftop则能实时显示哪些IP和端口在消耗带宽。我还会检查防火墙规则（
iptables -L -n -v）或安全组设置，确保没有不必要的阻塞。
这些工具结合使用，能帮助我迅速缩小问题范围，从系统层面定位到具体的资源瓶颈。
针对特定应用或进程，有哪些深入排查的技巧？
当我已经通过上述方法定位到具体的进程或应用是高负载的元凶后，接下来的工作就是深入其内部，找出它到底在干什么。这需要一些更细致的技巧。
首先，我会检查应用自身的日志。这是最直接的线索，很多时候，应用日志会记录错误、慢查询、异常堆栈等信息，直接指向问题根源。我会留意日志中是否有大量ERROR或WARN级别的输出，或者是否有重复的、耗时长的操作记录。
如果日志没有明显问题，或者问题无法通过日志定位，我会使用
ps aux | grep <进程名或PID>来获取进程的完整命令行和状态。了解进程的启动参数和运行用户，有时能提供额外的信息。
对于一个正在运行的进程，
strace -p是一个非常强大的工具。它可以跟踪进程执行的系统调用和接收的信号。通过观察
strace的输出，我能看到进程在频繁地进行哪些系统调用（比如读写文件、网络通信、内存分配等），以及这些调用是否耗时过长。这对于发现死循环、不必要的I/O操作或系统调用阻塞非常有效。不过，
strace会显著影响进程性能，所以通常只用于短时间分析。
lsof -p则能列出进程打开的所有文件和网络连接。这对于排查文件句柄泄露、网络连接异常或不必要的资源占用很有帮助。例如，如果一个Web服务打开了成千上万个文件句柄，那很可能存在问题。
如果进程是一个C/C++程序，且出现了死锁或卡顿，我可能会尝试用
gdb（GNU Debugger）附加到运行中的进程上（
gdb -p），然后使用
bt（backtrace）命令查看其调用栈。这能让我知道进程当前正在执行哪个函数，以及是如何到达那里的。这对于定位代码层面的逻辑错误或阻塞非常有用。
对于Java应用，
jstack是我的救星。它能生成Java进程的线程dump，显示所有线程的当前状态和调用栈。通过分析线程dump，我可以轻松发现死锁、长时间等待I/O的线程、或者CPU密集型线程正在执行什么代码。我通常会连续生成几个线程dump，对比它们的变化，以发现模式。
有时候，问题可能不是持续的高负载，而是周期性的性能下降。这时，我会考虑使用性能分析工具，如
perf record配合
perf report，来收集CPU性能事件数据，生成火焰图（Flame Graph）。火焰图能直观地展示CPU时间都消耗在了哪些函数上，帮助我找出热点函数。
这些深入的排查技巧，往往需要结合对应用代码和业务逻辑的理解。它们就像放大镜和手术刀，能帮助我从宏观的系统表象，一步步切入到微观的代码执行细节，最终找到问题的症结。
