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（查高频启动服务，识别异常循环）

不复杂但容易忽略