如何诊断OS中的CPU资源（3）

白鳝的洞穴 2020-05-18

1148

今天是这个系列中的第三篇，一个CPU分析都能写好几天，大家是不是觉得有些意外。事实上，任何一个知识点拿出来，想要比较全面的讨论，都能写上好几天。可能大多数人不关心这些技术细节，但是偶尔会有人用得上这些知识点。往往是我们翻箱倒柜的在百度，谷歌上想要找到我们所需要的知识的时候，我们才会发现大多数对一些技术细节的描述都轻轻带过了。实际上让任何一个运维人员熟练掌握这些知识点都是不太现实的，有些场景可能我们很难遇到。把这些知识点积累下来，做成可自动化诊断的工具可能是一个比较好的方法。这些年老白在D-SMART中积累和沉淀相关的知识点。这个工作不太好做，刚刚开始做的时候觉得有太多的知识可以倒出来，做成工具，为我们的问题诊断服务，实际上做起来才发现不是那么回事。我们在遇到具体场景的时候，觉得需要更广更深的知识，而把这些知识点抽象出来，离开场景，似乎就变得十分单薄了。运维知识自动化系统的建设就是这样，光靠个人能力单打独斗是很难做的。

回到今天的主题，对于CPU分析，实际上我们还经常看CPU用到哪了。OS中CPU的使用率可以分为usr/sys/idl/wio/steal等。usr就是用户进程或者在OS的用户态使用的CPU，大多数是我们的应用或者一些后台任务使用的CPU资源，sys是核心态的调用占用的CPU资源，一般来说是一些系统调用小号的CPU资源。大家可能不一定记得老白写过的一篇《PODER案例的另一种思考》，2012年Poder中国之行介绍了一个案例。当时故障现象是这样的：

从这个图上，可以看出18:11分到18:16左右出现了一个CPU的突发高峰，而这个高峰中，SYS CPU居然超过了90%。几乎100%的CPU使用率，高达90+%的SYS CPU使用率，就很好解释为什么系统会很慢，甚至OS 登录和操作系统命令都很慢了。这种情况是什么导致的呢？sys CPU往往是SYS CALL调用产生的，什么情况下会产生大量的SYS CALL呢？

操作系统换页
大内存下未使用大页，导致内存管理消耗了更多的SYS CALL
Oracle数据库的闩锁争用十分严重，SPIN 消耗了大量的SYS CALL
大量的文件打开、删除等操作
大量的进程创建和关闭操作
SOCKET连接
BUG导致的异常LOOP
......

Poder这个案例的最终定位是由于数据库登录风暴，大量的SOCKET连接，进程创建，以及由于AUDIT_TRAIL的设置导致大量的aud文件产生，这些叠加效应导致了SYS CPU的问题。

除了SYS以外，还有一个我们常见的问题是WIO，WIO是运行任务在等待IO操作，一个正常的系统中，wio的比例不会超过10%，不过偶尔出现30%以下的wio是可以接受的，如果wio的比例长时间超过30%，甚至40%，那么我们就要十分留意了。这种情况下，十有八九是IO子系统的性能出现了问题，或者我们的系统产生了非同寻常的IO操作。wio比较高的时候，我们往往会发现b队列的大小也很大，b队列是操作系统中被资源等待阻塞的任务数量，如果b比较高，同时wio比较高，那么被阻塞的任务在等待IO，否则就需要去查查在等待什么其他的资源了。还有一点要注意的是，在AIX系统中b的含义有所不同，AIX把等待文件系统IO的任务放到b队列，把等待块设备IO的任务放到p队列。在AIX系统中，如果我们的数据库系统使用了裸设备，我们会发现b永远很小。这时候我们只有使用vmstat -I参数，才能看到p队列的情况了。

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

如何诊断OS中的CPU资源（3）

评论