今天在飞机上一直在想要不要把今天的一篇补上，最后还是想今天就把CPU诊断了结。CPU诊断已经写了三篇了，今天是第四篇。因为信息系统是十分复杂的，所以CPU资源诊断实际上也相当复杂。仅仅靠几篇科普性的文章还是说不全的。老白介绍的也只是一些皮毛。今天我们回到第一篇提到的interrupt和content switch,在VMSTAT显示的信息里我们可以看到这两个指标的情况：
上面的这个案例CPU的USER使用率比较高，USR占了80%左右，SYS也占了超过10%，我们看in和cs的指标，in在11000-12000左右，cs比in略低，大约是7-8000。中断多于上下文切换一般来说是进程有大量的外部中断请求，比如IO，从前面的b也可以看出，存在一定量的阻塞进程。如果cs经常很高，远高于in的值，那么有两种可能性，一种是你的应用进程经常在用户态和核心态之间切换（当用户进程调用OS的核心调用时，因为调用的代码段是不同的，因此CPU需要做上下文切换，将现有寄存器保存压栈（如果还记得大学的汇编语言的同学可以马上联想到ASM里面的push操作），然后进行切换。这种情况往往CPU的使用率并不高，但是load很高，同时sys的CPU比例也偏高（和USR相比，而不一定总数偏高）。如果遇到这种情况，会出现系统CPU使用率不高，好像也没啥负载，不过应用就是慢。遇到这种情况的场景包括LINUX下数据库的共享内存很大（超过32G甚至128G）没有使用大页内存，导致管理内存页表的操作产生了过多的cs；大量的SOCKET连接；文件系统的目录深度太大，单一目录下的文件数量太多，同时文件系统的并发访问量太大等等。还有一种上下文切换很频繁的情况是，有大量的长时间占用CPU的会话在并发执行，这种情况往往会伴随USR的使用率较高。另外一种情况是cs和in都很高，这种时候往往CPU使用率都很低，不超过40%，但是无论我们怎么加压，CPU使用率都上不去。实际上这是因为大量的中断导致了大量的上下文切换。解决这种问题的方法是将某些进程或者某些中断绑定到特定的CPU或者CPU组上，从而减少cs。以前我们在一台超过共80核的八路服务器上做压测的时候，经常遇到这个问题，无论怎么压CPU使用率都上不去，一台8路服务器的TPCC似乎比不上一台4路服务器。这时候做CPU绑定是可以立竿见影的。关于CPU诊断的内容就写这么多吧，实际上这四篇还无法涵盖CPU诊断的所有方面。现在运维自动化的趋势是走极简运维深度运维两个方向。互联网企业一般应用运维一体化做的很好，大部分问题通过优化应用来解决，同时运维的IT设备、系统的数量相当庞大，所以极简运维的效率较高；而对于传统行业，应用优化的成本较高，周期较长，因此深度运维仍然是刚需。做深度运维，就不是分析点皮毛就能解决问题的，需要我们对一些重要的问题具备深入分析的能力。当然互联网公司，特别是云服务商，在某些关键资源的深入优化能力方面也是相当强大，榨干硬件和系统的每一分钱，是这些公司盈利的很重要的手段之一。
最后修改时间：2020-05-22 09:17:46
文章转载自
白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
