导言

线上运行环境有时候会遇到cpu 飙升的场景，一般来讲对于多核的虚机，一个常见猝发场景就是高并发导致，核多并发高时，syscall会在锁这块 sys 消耗高,当然只有猜测不行，下面就列出了几个常见捉鬼工具 。

工具箱

1、nmon promes  分析

尤其是promes ,比较推荐用起来，提供比较立体的系统级别监控

2、perf 分析

perf top -a -G
perf top -a -e cs -G
perf record -g -p 14778 -e cycles sleep 10
TIPS:
perf 采样界面中按
shift + e 可展开堆栈 
shift + c 可折叠
展开 折叠状态分别截图
右方向键可以下钻函数查看其上下文（例如属于哪个lib），左方向键返回
最好排在前面的几个函数都去下钻截图

3、系统调用统计

{ top -H -p PID  -b -n 1|grep execname|awk '{print $1}'| sed 's/\([0-9]*\)/-p \1/g'|xargs strace -c  2> /tmp/stat & }; sleep 5;pkill strace

4、调用细节

{ top -H -p PID -b -n 1|grep execname|awk '{print $1}'| sed 's/\([0-9]*\)/-p \1/g'|xargs strace -i -v -T  2> /tmp/detail & }; sleep 5;pkill strace

5、sar -wq 1 10

6、vmstat 1 10

7、mpstat -I ALL 1

8、rpm -qa > /tmp/rpms

9、堆栈dump

echo 1 >   /proc/sys/kernel/sysrq
echo t > /proc/sysrq-trigger

一个案例

某数据库系统导数据时，syscpu 会很高

可以看到每到任务运行时间，sys 就会高企，，初步分析，目标机器有16c，根据经验怀疑是时间耗在并发锁处理上，但是具体哪部分需要使用perf 线上抓取堆栈

，可以看见sys time 耗在了spinlock 处，是MM 系统的内存压实整理例程中，结合该数据库开启了hugepage 因此初步可以断定是因为内存过于碎片化，无法满足巨页分配，也就是整体看内存高阶页不足

当然伴随的现象不止这一个，也注意到问题时刻系统的进程创建非常多，高达每秒数百，如下图

这个与项目组认为的10并发是对不上的，因此的出的综合结论是

sys高时间主要耗在了内存碎片整理， 主因是内存不足，伴随现象之一是线程创建多 fork 300-800/s  内存回收多，很多cache 问题时间段回收，得扩内存，动态模型也似乎有问题，不知道fork 那么多进程做什么用

上面的结论看着很模糊，但是提供了比较全面的现场总结，坚定了问题的排查方向，果然，项目组重新梳理代码后，发现一处高并发场景，修改参数后，问题得以解决