原始笔记是几条手记式的步骤+一段命令拼接,结构略乱。这里按”现象 / 排查命令 / 案例与脚本”三块整理,命令本身基本保持不动。
当前保留内容
1. 现象与初步定位
- CPU 飙升 100%:先用
perf抓热点函数,确认 CPU 时间消耗在哪段代码上。 - 内存飙升 100%:先看 log 里出现频率最高的关键行,按行频反推到函数位置。
- 一次实际案例:通过 log 行频定位到代码逻辑后,发现 Redis 上存在一个 20M 的大 key。
2. 常用排查命令
| 命令 | 作用 |
|---|---|
top |
进程视图,看是哪个进程吃满 CPU / 内存 |
top -Hp <pid> |
进入线程视图,看是哪一根线程吃 CPU |
strace -p <pid> |
观察该进程的内核函数调用情况 |
pstack <pid> |
打印线程当前调用栈 |
cat /proc/<pid>/limits |
查看进程的 fd 数量及上限(示例:cat /proc/267/limits) |
3. 计算各进程拉起以来的平均 CPU 使用率
参考:https://panzhongxian.cn/cn/2020/09/cpu-strike-to-100-analysis/
uptime=`awk '{print $1}' /proc/uptime` # why is it too slow indocker?
hertz=`zcat /proc/config.gz | grep CONFIG_HZ= |awk -F"=" '{print $2}'`
awk -v uptime=$uptime -v hertz=$hertz -- '{printf("%d\t%s\t%11.3f\n", $1, $2, (100 *($14 + $15) / (hertz * uptime - $22)));}' /proc/*/stat 2> /dev/null | sort -gr -k +3 | head -n 20
在 Docker 里读
/proc/uptime偶尔会比较慢,原因待补。
后续可补的方向
- 配套各命令的典型输出截图与判读要点
perf火焰图的生成脚本与常用筛选条件- 内存类问题的排查命令补全(
pmap、/proc/<pid>/status、smem等) - 与监控告警(Prometheus / 自研监控)联动的排查 SOP
FEATURED TAGS
Git
Cheat Sheet
Markdown
Tools
C++
Linker
Thread
Linux
TCP
Network
GDB
Debug
leetcode
链表
WSL
Ubuntu
Windows
Linux Kernel
GCC
Android
adb
Troubleshooting
Profiling
Sanitizer
glibc
MySQL
Database
Python
curl
Build
ELF
clang-format
CMake
Graphviz
Performance
vcpkg
Protobuf
排查
速查
内存
STL
调试
性能分析
性能
读书笔记
方法论
架构
网络
Timer
mbedTLS
TLS
安全
负载均衡
脚本
工具
LRU
二叉树
BST
中序遍历
回溯
二分查找
优先队列
排序
旋转数组
jenkins
部署