这篇文章主要为大家分析了sys工具箱的示例分析的相关知识点,内容详细易懂,操作细节合理,具有一定参考价值。如果感兴趣的话,不妨跟着跟随小编一起来看看,下面跟着小编一起深入学习“sys工具箱的示例分析”的知识吧。
线上运行环境有时候会遇到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 那么多进程做什么用
上面的结论看着很模糊,但是提供了比较全面的现场总结,坚定了问题的排查方向,果然,项目组重新梳理代码后,发现一处高并发场景,修改参数后,问题得以解决
这篇文章主要为大家分析了sys工具箱的示例分析的相关知识点,内容详细易懂,操作细节合理,具有一定参考价值。如果感兴趣的话,不妨跟着跟随小编一起来看看,下面跟着小编一起深入学习“sys工具箱的示例分析”的知识吧。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。