嗨,我是Linux程序员
我有一个监控进程CPU使用的命令,所以我使用/proc/[pid]/stat号14和15上的数据。这个值叫做utime和stime。
示例[/proc/[pid]/stat]
30182 (TTTTest) R 30124 30182 30124 34845 30182 4218880 142 0 0 0 5274 0 0 0 20 0 1 0 55611251 17408000 386 18446744073709551615 4194304 4260634 140733397159392 140733397158504 4203154 0 0 0 0 0 0 0 17 2 0 0 0 0 0 6360520 6361584 33239040 140733397167447 140733397167457 140733397167457 140733397168110 0
5秒后状态
30182 (TTTTest) R 30124 30182 30124 34845 30182 4218880 142 0 0 0 5440 0 0 0 20 0 1 0 55611251 17408000 386 18446744073709551615 4194304 4260634 140733397159392 140733397158504 4203154 0 0 0 0 0 0 0 17 2 0 0 0 0 0 6360520 6361584 33239040 140733397167447 140733397167457 140733397167457 140733397168110 0
在测试环境中,这个文件刷新了1~2秒,所以我假设这个文件经常被系统更新至少1秒。
所以我用这个计算
process_cpu_usage = ((utime - old_utime) + (stime - old_stime))/ period
如果出现上述值
33.2 = ((5440 - 5274) + (0 - 0)) / 5
但是,在商业服务器环境中,进程在高负载(cpu和文件IO)下运行,/proc/[pid]/stat文件更新周期甚至会增加20~60秒!!
因此top/htop实用程序无法测量正确的进程使用值。
为什么会出现这种现象??
我们的系统是[CentOS Linux 7.1.1503(Core)]
最佳答案
/proc
文件系统中的大多数(如果不是全部)文件都是特殊文件,它们在任何给定时刻的内容都反映了当时的实际操作系统/内核数据,它们不是定期更新内容的文件。见the /proc filesystem doc。
尤其是,每当相应的进程状态改变时(例如在每次调度事件之后),对于大多数处于休眠状态的进程,文件的内容都会发生变化,而对于活动/正在运行的进程,在轻载系统上,文件的“更新”速度会变慢。例如,检查不执行任何操作的shell进程和播放某些视频流的浏览器进程的相应文件。
在具有许多处于就绪状态的进程(例如this Q&A中提到的进程)的重载系统上,可能存在调度延迟,使得文件内容“更新”出现的频率较低,尽管进程处于就绪/活动状态。这种情况在商业/企业环境中似乎更常见(我同意,这是有争议的)。
关于linux -/proc/[pid]/stat刷新周期,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/31219317/