高频排障命令实战

• Magic SysRq 机制
• 各操作（sync/reboot/dump）
• 适用边界

Magic SysRq 是内核提供的一组紧急操作，通过 /proc/sysrq-trigger（写入字母）或 Alt+SysRq+key 触发，即使系统卡死也能执行（内核处理）。常用操作：echo s > /proc/sysrq-trigger（sync 同步缓冲到磁盘）、echo b >（紧急 reboot）、echo u >（重新挂载只读）、echo t >（dump 当前进程任务）、echo m >（dump 内存信息）、echo w >（dump 阻塞进程 D 状态）。应急处置：系统完全卡死（无法 SSH/键盘）时，先 s（sync）保证数据落盘，再 b（reboot）或 u（只读挂载）；用 t/w 看进程状态辅助诊断。适用边界：需内核启用 sysrq（sysctl kernel.sysrq）；仅用于紧急恢复（卡死、无响应），正常重启不用；操作有风险（b 直接重启可能丢未同步数据，先 s）。边界：sysrq 是"最后手段"，sync 后 reboot 保数据；dump 用于诊断但可能刷屏。运维：卡死时按需用 s→u→b。

核心是"内核紧急操作"。sysrq 的 s 同步、b 重启、u 只读、t/w 进程 dump，卡死时先 sync 再 reboot，需内核启用。

• sar 系统级流量
• iftop 连接级
• nethogs 进程级

sar -n DEV 1 3 统计系统级网络流量（每个网卡的 rx/tx 速率、包数、错误），反映系统整体流量，适合长期采样/容量评估；iftop 显示实时连接级流量（按连接对/主机显示带宽），适合定位"谁在传输"（连接级）；nethogs 按进程显示流量（每个进程的收发速率），适合定位"哪个进程在占带宽"（进程级）。差异：层级不同——sar 系统级（网卡总量）、iftop 连接级（连接/主机）、nethogs 进程级（进程）。工程价值：sar 看整体趋势/长期，iftop 看连接详情，nethogs 定位进程。排查带宽占用：先用 sar 或 nload 看整体，再用 iftop 看连接，最后 nethogs 定位进程。三者配合实现"系统→连接→进程"的流量定位。sar 需安装 sysstat 并采集。

核心是"三层流量定位"。sar 系统级、iftop 连接级、nethogs 进程级，配合定位带宽占用。

• strace 系统调用跟踪
• ptrace/ltrace 边界
• 工程应用

strace 用 ptrace 机制跟踪进程的系统调用（strace -f 跟踪子进程，-p 附加到运行进程），strace -f -p <pid> 附加到进程看它正做哪些 syscall（open/read/write/connect 等），用于定位进程卡在哪、文件/网络访问、错误（-e trace=... 过滤）。ptrace 是底层机制（strace 基于它），也用于 gdb 调试；ltrace 跟踪库调用（动态库函数，如 glibc 的 malloc/free），比 syscall 更高层。工程边界：strace 查系统调用（与内核交互），ltrace 查库函数调用（用户态），两者互补；strace 附加进程有性能开销（每个 syscall 暂停），生产环境慎用（高并发下显著拖慢）；用 -f 跟子进程、-e 过滤、-p 附加。定位：进程卡死/慢用 strace 看卡在哪个 syscall；ltrace 看库调用。边界：strace 只能看 syscall，不能看应用逻辑；对高 IO/网络进程开销大。

核心是"系统调用 vs 库调用 + 开销"。strace 看 syscall（基于 ptrace）、ltrace 看库调用，附加有开销，生产慎用。

• tcpdump 现场过滤
• 抓包与保存
• 事后分析

tcpdump 现场抓包：tcpdump -i any -w capture.pcap host X and port Y 在任意接口抓主机 X 且端口 Y 的包，-w 保存到 pcap 文件（原始二进制，便于事后分析）。现场过滤：BPF 表达式（host/port/src/dst/and/or/not）在抓包时过滤，减少数据量。事后分析流：一是用 tcpdump -r capture.pcap 重放读取；二是用 tshark（Wireshark 命令行）深度分析（-Y 过滤、-T json 导出、统计）；三是用 Wireshark GUI 可视化；四是分析 TCP 握手/重传/丢包（tcptrace、capinfos）。真实现场：先明确过滤（主机/端口/协议）减少抓包，抓取时间长段用 -w 保存，事后用 tshark/Wireshark 分析。注意：-i any 抓所有接口；抓包权限需 root；抓包有性能影响；filter 语法要准确。分析重点：握手、重传、延迟、协议错误。

核心是"现场过滤 + 事后分析"。tcpdump -w 保存、BPF 过滤，事后用 tcpdump -r/tshark/Wireshark 分析。

• load average 含义
• CPU/IO/D 状态区分
• 排查方法

load average 是运行队列（R）+ 不可中断（D）进程数的平均，负载高可能三类根因：一是 CPU 密集（大量 R 状态进程占 CPU），用 top/vmstat 看 %us/%sy 高、R 进程多；二是 IO wait（D 状态进程多，等待磁盘），用 vmstat 看 wa 高、iostat 看磁盘 busy、D 状态多；三是不可中断进程（D 状态，内核等待 IO/锁），大量 D 且 IO 正常可能是有进程卡在 IO 或文件系统。区分方法：top 看 R/D 状态数与 CPU 空闲；vmstat 1 看 r（运行队列）、b（阻塞/IO）、wa（IO 等待）；iostat -x 看磁盘 %util/await；ps -eo stat 统计 D/R 状态；uptime 看 load 趋势。三类：CPU 密集（R 多、%us 高）、IO 密集（D 多、wa 高、disk busy）、不可中断（D 多但 IO 正常，查进程/文件系统）。定位后对症：CPU 优化/扩容，IO 优化磁盘/缓存，D 卡死查进程与 IO。

核心是"R/D 状态与 CPU/IO 指标"。vmstat 的 r/b/wa、top 的 R/D 区分 CPU 密集、IO wait、不可中断三类根因。

• df 与 du 不一致
• 已删但被占用文件
• 处理

df 显示文件系统空间使用，du 统计目录实际占用。不一致的原因：已删除但被进程占用的文件（unlink 后 inode 仍被进程持有，空间未释放），df 仍算空间（inode 未释放），du 找不到（文件已从目录移除）。处理：一是用 lsof +L1 | grep deleted 定位持有已删文件的进程；二是对日志文件，确认后 > /proc/<pid>/fd/<n> 清空该 fd 指向文件释放空间，或重启进程；三是确认该文件确实不再需要（否则误清）。快速定位：先 df -h 确认哪个分区满，再 du -x --max-depth 找大目录，若 du 总和远小于 df 使用，则查已删占用。预防：日志用 logrotate 的 copytruncate/正常 rotate，避免长期持句柄。处理要点：lsof 定位、清空 fd 或重启进程、确认无数据丢失。

核心是"已删未释放句柄"。df 与 du 不一致多因已删被占用文件，用 lsof +L1 | grep deleted 定位进程并清空 fd 或重启。

• bpftrace 动态跟踪
• bpftool 管理
• 无 debug 内核边界

bpftrace 是基于 eBPF 的动态跟踪工具，用脚本挂载 kprobe/uprobe/tracepoint 等实时查看内核/用户态行为（如 bpftrace -e 'kprobe:do_sys_open { print(arg1) }'）；bpftool 管理 eBPF 程序（加载、查看 prog/map、pinned）。无 debug 内核（debuginfo 缺失）下的边界：一是 bpftrace 的 kprobe 需要内核符号（kallsyms），无 debuginfo 也能用 kprobe（符号名在 /proc/kallsyms），但无法反汇编/查看变量细节（需 debuginfo）；二是 uprobe 跟踪用户态需二进制符号（无 debug 则符号有限）；三是 tracepoint 不需要 debuginfo（内核自带 tracepoint），可用；四是 kprobe 对函数签名/参数需符号，缺失时参数读取受限。工程边界：无 debug 内核下，bpftrace 仍可用 tracepoint/kprobe 做事件级跟踪，但无法做变量级/源码级（需 debuginfo）；需 root 与内核支持 eBPF（4.x+）。诊断：用 tracepoint 统计事件、kprobe 计时，定位系统调用/阻塞热点。

核心是"无 debug 的边界"。无 debuginfo 下 tracepoint/kprobe 可用，但变量级/源码级诊断受限，需 root 与 eBPF 支持。

• iostat -x 磁盘指标
• iotop 进程 IO
• mpstat CPU 热核

iostat -x 显示磁盘详细指标：%util（磁盘利用率，接近 100% 说明硬件忙）、svctm（平均服务时间）、await（平均 I/O 等待时间，含队列等待）。区分：await 高而 svctm 相对低 → 大量 I/O 在队列等待（软件/并发队列延迟，非硬件瓶颈）；%util 高 → 磁盘硬件瓶颈；await 高且 svctm 也高 → 硬件慢。iotop 显示进程级 IO（每个进程的读写速率），定位哪个进程在疯狂 IO。mpstat -P ALL 显示每个 CPU 核的使用率，定位 CPU 热核（某核 100% 而其他空闲，可能单线程/中断绑定）。配合：iostat -x 看磁盘整体瓶颈，iotop 定位进程，mpstat -P ALL 看 CPU 分布（热核/负载均衡）。三者组合定位"磁盘 or CPU or 进程"瓶颈。

核心是"磁盘指标 + 进程 IO + CPU 分布"。iostat 的 %util/await 区分硬件/队列瓶颈，iotop 定位进程，mpstat 定位 CPU 热核。

• perf record 采样
• -F 99 频率
• 火焰图生成

perf 采样工作流：一是 perf record -F 99 -g -p <pid> -- sleep 30 以 99Hz 采样指定进程 30 秒（-F 99 采样频率避免过高频开销，-g 记录调用栈）；二是 perf report 查看，或生成火焰图：perf script 导出调用栈，用 FlameGraph 工具（stackcollapse-perf.pl + flamegraph.pl）生成 SVG 火焰图；三是分析火焰图找热点（最宽的部分是 CPU 热点）。生产环境 30 秒采样：-F 99 采样 30 秒约 2970 个样本，开销小（99Hz 相对低），适合生产短时采样；-g 记录栈（需符号）。边界：采样是统计（非精确），99Hz 足够定位热点；需 perf 权限（perf_event_paranoid）与符号；生产采样 30 秒即可，避免长时间拖慢。工作流：record → script → 火焰图 → 分析热点，优化代码/配置。

核心是"采样 + 火焰图分析"。perf record -F 99 -g 采样 30 秒，perf script + FlameGraph 生成火焰图，-F 99 低开销适用生产。

• fd 耗尽定位
• ulimit 层级
• systemd 限制

文件描述符耗尽（Too many open files）定位：先 ulimit -n 看进程限制，lsof -p <pid> | wc -l 或 ls /proc/<pid>/fd | wc -l 数进程 fd，sysctl fs.file-max 看系统总量，确认是进程级还是系统级耗尽。限制层级：进程级有 soft/hard（ulimit -n），hard 是上限，soft 是当前生效；系统级 file-max（总 fd 上限）；nr_open 是单进程绝对上限。systemd 限制：systemd 服务通过 LimitNOFILE= 设置 fd 限制（默认可能更低），用 ulimit -n 在服务内查看；systemd 的 LimitNOFILE 覆盖 ulimit 默认。处理：如果是进程级，调高 ulimit -n（shell 临时 or systemd LimitNOFILE 或 /etc/security/limits.conf）；如果是系统级，调 fs.file-max/nr_open。排查：先看哪个层级耗尽（进程 fd 数 vs 限制 vs 系统总量），再对症调整。注意 fd 泄漏（进程数不降）需找应用 bug。

核心是"进程/系统两级 + systemd 覆盖"。定位看进程 fd 数 vs ulimit vs file-max，systemd 用 LimitNOFILE 设置，fd 泄漏需查应用。

• 各工具作用
• 组合场景
• 排查流程

网络排查工具链：ss 查看本机 socket 状态（LISTEN/ESTABLISHED、端口、连接数），快速判断服务是否监听/连接是否建立；tcpdump 抓包看实际数据流（握手、重传、丢包）；traceroute 看路径跳数与中间节点延迟；mtr 是 traceroute+ping 融合，持续显示每跳延迟与丢包，定位网络路径问题；nc 用于测试端口连通性（nc -zv host port）与简单收发。组合场景：先 ss -tulpn 看服务是否监听、本地连接；再 nc -zv host port 测端口通不通；若不通，用 traceroute/mtr host 看路径哪跳丢包/延迟；用 tcpdump 抓包确认握手/数据。排查流程：从服务端（ss）→ 连通性（nc）→ 路径（traceroute/mtr）→ 抓包（tcpdump）。组合使用实现"由近及远、由服务到路径"的定位。

核心是"工具链组合"。ss 看本机、nc 测端口、traceroute/mtr 看路径、tcpdump 抓包，由近及远定位。

• ps/top 进程状态
• lsof 文件/端口
• ss 连接

进程排障工具组合：ps 查看进程状态（ps -ef 全进程、ps -eo stat,pid,... 状态、ps aux 资源），快速了解进程与状态；top 实时监控进程 CPU/内存排序、负载、状态；lsof 定位进程打开的文件/端口（lsof -p 看进程文件、lsof -i :port 看端口、lsof | grep deleted 看已删占用）；ss 看进程的网络连接（ss -tpn 显示进程、ss -tulpn 看监听）。组合用法：先 ps/top 定位异常进程（CPU/内存高、状态异常），再用 lsof -p 看进程打开的文件/端口（是否存在泄漏、持锁），用 ss -tpn 看进程网络连接（连接数、状态）。排障流程：top 找耗 CPU/内存进程 → ps 看状态 → lsof 查文件/端口 → ss 查连接。组合实现"进程状态→资源→文件→网络"的全面排查。

核心是"进程状态/资源/文件/网络"。ps/top 看进程与资源，lsof 看文件/端口，ss 看连接，组合定位问题。

• 三个压测工具
• 使用与特点
• 选型

ab（Apache Bench）简单压测工具：ab -n 1000 -c 100 http://host/ 指定请求数与并发，输出吞吐/延迟/失败率，适合快速简单测试，但单线程、功能有限（无复杂场景、连接复用一般）。wrk 高性能压测工具：wrk -t4 -c100 -d10s http://host/ 用多线程+事件循环，支持自定义 Lua 脚本（复杂请求/场景），吞吐高、适合高频压测，但需编译。vegeta 是 Go 压测工具：echo "GET http://host/" | vegeta attack -rate=100 -duration=10s 支持持续固定速率（rate）、报告、直方图、多个目标，适合持续负载测试与报告生成。选型：简单快速用 ab，高频/复杂场景用 wrk，持续固定速率/报告/自动化用 vegeta。真实使用：先明确目标（并发/吞吐/延迟），用合适工具设定参数，采集结果（吞吐、延迟分位、失败率），分析瓶颈。注意压测需控制（不压垮生产）、关注延迟分位（p99）。

核心是"三种工具选型"。ab 简单、wrk 高性能多线程、vegeta 固定速率+报告，按场景选型。

• curl -w 时间分解
• dig +trace
• DNS/HTTP 排障

curl -w 输出时间分解：curl -w "dns: %{time_namelookup}\nconnect: %{time_connect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n"：time_namelookup（DNS 解析）、time_connect（TCP 连接）、time_starttransfer（TTFB，首字节，含处理+响应）、time_total（总耗时）。判读：DNS 耗时长→DNS 问题；connect 耗时长→网络/连接问题；ttfb 耗时长→服务端处理慢；total 长→带宽/下载慢。dig +trace 排障：dig +trace example.com 从根服务器逐级解析（根→顶级→权威），显示每级 DNS 服务器与响应，定位解析在哪级失败/慢、是否被污染/缓存。判读：dig 结果看 ANSWER 记录与解析路径；+trace 看每级响应时间与服务器；结合 curl 的 time_namelookup 判断 DNS 是否瓶颈。HTTP 排障：curl 时间分解定位请求慢的环节，dig +trace 定位 DNS 解析问题，二者结合覆盖"DNS→连接→响应"。

核心是"时间分解 + DNS 追踪"。curl -w 分解 DNS/连接/TTFB/总耗时定位 HTTP 慢环节，dig +trace 追踪 DNS 解析路径。

• dmesg 日志级别
• oops 字段
• 硬件/驱动判断

dmesg 显示内核环形缓冲日志，日志级别：err（错误，3）、warn（警告，4）、info（信息，6）、debug（调试，7）等，dmesg -l err 过滤错误级别。内核 oops（/panic）信息关键字段：BUG/Oops 头、RIP（出错指令地址）、Error Code、RAX/RBX 等寄存器、Call Trace（调用栈）、Modules（涉及模块）、还可能包含 "kernel panic" 或硬件错误（Machine Check、EDAC）。解读：结合 Call Trace 看出错函数/驱动；Modules 看涉及的模块；Error Code 看错误类型。快速判断硬件 vs 驱动：一是硬件错误（Machine Check Exception、EDAC、SATA error、Smart 错误）指示硬件问题；二是驱动相关（oops 中 RIP 指向驱动函数、Call Trace 含驱动、Modules 是驱动）指示驱动问题；三是反复 oops 与具体驱动相关多为驱动/驱动与硬件不兼容；四是看 dmesg 是否有 I/O error、Timeout 等。判断：先看日志级别（err 高优先级），再分析 oops 的 RIP/调用栈/模块，结合硬件报错判断。

核心是"日志级别 + oops 字段"。dmesg 级别过滤 err，oops 看 RIP/Call Trace/Modules，硬件报错 vs 驱动调用栈区分。

• journalctl -o verbose
• dmesg 内核日志
• 边界

journalctl -o verbose 以详细格式显示 journal 日志（含结构化字段：_PID、_SYSTEMD_UNIT、_COMM、_UID、时间戳等元数据），适合查看服务日志与关联信息；dmesg 显示内核环形缓冲（内核日志，含设备/驱动/内核消息）。systemd 主导下：journald 收集内核日志（dmesg 内容也进 journal，可通过 journalctl -k 查看内核日志），dmesg 仍可读内核环形缓冲（直接读 /dev/kmsg 或 /proc/kmsg）。边界：journalctl -k 或 dmesg 都看内核日志，但 journalctl -o verbose 看结构化服务/系统日志（含内核），dmesg 只读内核当前环形缓冲（重启后丢失，除非 journal 持久化）；journal 有结构化元数据、可过滤、可持久化，dmesg 是原始内核缓冲。作用：systemd 环境下优先用 journalctl（结构化、持久化），dmesg 用于快速看内核缓冲（或 journalctl -k）。边界：dmesg 是内核缓冲子集，journal 是完整日志（含内核+服务）。

核心是"journal 结构化 vs 内核缓冲"。journalctl 含结构化元数据与内核日志（-k）可持久化，dmesg 只读内核环形缓冲，systemd 下优先 journalctl。

• 各存储工具
• 组合
• 排障

存储排障工具组合：df 看文件系统空间与挂载（df -h 空间、df -i inode），判断空间/挂载是否正常；du 看目录实际占用（du -sh、du -xh --max-depth），定位大目录/文件；iostat 看磁盘 IO（-x 的 %util/await/r/s/w/s），判断磁盘性能/瓶颈；blkid 看磁盘/分区 UUID/文件系统类型（blkid 查看块设备属性），用于挂载/识别设备。组合：先 df 看空间/挂载（空间满、挂载失败），用 du 定位大占用；若磁盘慢/IO 高，用 iostat 看磁盘性能；用 blkid 确认设备 UUID/类型（挂载、fstab 排障）。排障流程：空间问题（df→du）、性能问题（iostat）、设备识别（blkid）。组合实现"空间→占用→性能→设备"的存储排障。注意 df/du 不一致查已删占用（lsof）。

核心是"空间/占用/性能/设备"。df 空间、du 占用、iostat 性能、blkid 设备识别，组合排障。

• journalctl 过滤
• grep 检索
• tail 跟踪

日志排障技巧：journalctl 过滤（-u 服务、-f 跟随、-k 内核、--since/--until 时间、-p 级别、-o verbose、-b 本次启动），快速定位服务/时间/级别日志；grep 检索（grep -E 正则、-i 忽略大小写、-c 计数、-A/-B 上下文、-F 固定串），在大日志中找关键词；tail 跟踪（tail -f/-F 实时跟踪、-n 查看尾部），监控最新日志。组合技巧：先 journalctl -u app -f 实时跟踪服务日志；用 journalctl --since "10 min ago" -u app 查近段时间；grep 过滤关键词（grep -E 'error|fatal'）、上下文（-A5 -B5）；tail -F 跟踪文件日志（rotate 不中断）。排障流程：journalctl 定位服务/时间 → grep 过滤关键词/上下文 → tail 实时跟踪确认。技巧：结合时间、级别、服务、关键词过滤，避免大海捞针；tail -F 优于 -f（rotate）。

核心是"过滤+检索+跟踪"。journalctl 按服务/时间/级别过滤，grep 关键词与上下文，tail -F 实时跟踪。

• 各网络工具
• 组合
• 排障流程

网络排障工具组合：ping 测试连通性（ICMP 延迟/丢包），判断目标是否可达；traceroute 看路径跳数/延迟（哪跳慢），定位网络路径问题；curl 测试 HTTP 服务（状态码、时间分解、响应头），判断应用层是否正常；tcpdump 抓包（看实际数据流、握手、重传、丢包），深入分析。组合流程：先 ping 测连通性（通不通、延迟）；连通性问题用 traceroute 定位路径；HTTP 问题用 curl 测试（状态码/时间）；需要深入用 tcpdump 抓包分析。排障：ping 不通→网络/防火墙；traceroute 定位断点；curl 看 HTTP 层（服务/代理/证书）；tcpdump 看数据包（握手/重传/丢包）。组合实现"连通性→路径→应用层→数据包"的逐层定位。注意：生产环境慎用高频 ping/tcpdump（有开销）。

核心是"逐层定位"。ping 连通性、traceroute 路径、curl 应用层、tcpdump 数据包，由近及远逐层排障。