Linux服务器负载告警需综合load average、CPU核数、进程状态、I/O等待和内存压力判断“忙”与“病”：一看load是否超阈值（>核数×1.2需关注，>×2大概率过载）；二查线程级CPU/内存异常及堆栈；三验I/O饱和与内存换页；四扫inode、deleted文件及fd耗尽等隐性瓶颈。
Linux服务器负载告警不是单纯看CPU使用率高不高，而是要结合load average、CPU核心数、进程状态、I/O等待和内存压力综合判断。真正关键的是区分“忙”和“病”——系统在高效处理任务（如批量计算）是正常的“忙”，而因资源争抢、阻塞或OOM频繁触发调度才是需要干预的“病”。
一看负载数值是否真超标用uptime或top查看三段 load average（1/5/15分钟）：对比nproc输出的逻辑CPU核数：若 1分钟值持续 > 核数 × 1.2，需关注；> 核数 × 2，大概率已过载注意单位一致性：4核机器 load 3.8 是健康，load 6.5 就存在排队压力不要只盯百分比：top里显示 CPU 70% 但 load 是 0.3，说明任务少且轻；反过来 load 8.2 但 us+sy 只有 40%，大概率是 I/O 等待（wa 高）或大量 D 状态进程二查进程与线程级线索用htop（推荐）或top -H
进入线程视图：
Docker Desktop（linux）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载按P排序看 CPU 占比，找长期 >90% 的线程；按M看内存，找 RSS 持续增长的进程记下可疑 PID，用pwdx PID查工作目录，ps -p PID -o comm=看命令名，cat /proc/PID/cmdline | tr '\0' ' '看完整启动参数对 Java/Python 类服务，加-p PID后用jstack或py-spy record抓堆栈，定位热点方法或死循环三验I/O与内存是否拖累调度高 load 常由磁盘或内存瓶颈引发，而非CPU本身：运行iostat -x 1 3：重点关注%util >95%（设备饱和）、await >10ms（单次IO慢）、r/s + w/s是否突增执行iotop -o找出实际刷盘的进程；
lsof +D /var/log看是否有日志文件被反复重写用free -h和vmstat 1 5观察：若si/so（swap in/out）持续非零，或buff/cache占比极低、available内存逼近 0，说明内存不足触发频繁换页四扫隐性资源耗尽项有些负载升高不体现在 top，却让新进程无法创建或请求卡住：检查 inode：用df -i，若某分区 usage >95%，即使df -h显示空间充足，也无法新建文件或进程查已删未释放文件：运行sudo lsof +L1，输出中带(deleted)的条目说明进程还在写一个已被 rm 的文件，占用磁盘却不显示在 du 中
确认文件描述符：
cat /proc/sys/fs/file-nr查已分配 fd 总数，再用ls /proc/PID/fd | wc -l看单个进程是否接近 ulimit -n 限制