journalctl 不直接生成性能数据，但可通过错误日志定位性能瓶颈，如 oom、连接溢出、i/o 阻塞等，并支持按服务、时间、优先级交叉排查及结构化分析。
直接看性能瓶颈，journalctl 本身不生成性能数据（比如 CPU 占用率、内存泄漏），但它能帮你快速定位引发性能问题的日志线索——比如服务卡顿、OOM 杀进程、内核资源警告、服务反复重启等。关键不是“查性能数字”，而是查异常行为背后的时间点、错误模式和服务关联性。
查最近一次启动中高优先级告警日志
性能问题常伴随 err/warning 级别日志，尤其是系统资源不足时：
-
journalctl -b -p err—— 查本次启动所有 error 及更严重（crit/alert/emerg）日志 -
journalctl -b -p warning --no-pager | head -n 50—— 查 warning 级别前 50 行，避免刷屏
常见线索包括：
•Out of memory: Kill process（OOM killer 触发）
•kernel: TCP: time wait bucket table overflow（连接数超限）
•systemd-journald: Received request to flush runtime journal（日志写入阻塞，可能磁盘或 I/O 问题）
按服务 + 时间范围交叉排查响应延迟
比如 Web 接口变慢，先锁定时间窗口，再查相关服务：
- 先确认大致时间：
journalctl -b --since "2 hours ago" | grep -i "timeout\|slow\|refused" - 再聚焦服务：
journalctl -u nginx.service --since "2026-06-10 14:00:00" --until "2026-06-10 14:15:00" -p warning - 同时查后端：
journalctl -u nodejs-app.service -n 100 --since "2026-06-10 14:00:00"
注意：加-n 100避免拉取过多历史，--no-pager配合grep更方便筛选
结合内核日志看底层资源压力
dmesg 和 journalctl -k 能暴露硬件或驱动层瓶颈：
-
journalctl -k -S "1 hour ago" | grep -E "(throttle|blocked|hung_task|memory:)"
典型信号：
•INFO: task XXX blocked for more than 120 seconds（I/O 或锁等待过长）
•Memory cgroup out of memory（容器内存限制触发）
•CPU#X: online或acpi PNP0C02:00: failed to evaluate _OSC（CPU/电源管理异常）
导出结构化日志辅助分析
纯文本难统计频次，转 JSON 后可用脚本处理：
-
journalctl -b -p err -o json | jq '. | select(.MESSAGE | contains("timeout") or .PRIORITY == "3")' - 或导出为文本后统计：
journalctl -b -u docker.service --since "yesterday" | grep -c "failed"
journalctl -b | awk '/Started|Starting/ {print $1,$2,$3,$4,$5}' | sort | uniq -c | sort -nr | head -10（查高频启动服务，识别异常循环）
不复杂但容易忽略
