linux / proc / loadavg

76

从Linux发出此命令时：

# cat /proc/loadavg
0.75 0.35 0.25 1/25 1747

最后两个数字是多少？

最后一个以每秒2的速度递增，我担心吗？

linux

— 乌拉尔
source

84

/ proc / loadavg

该文件的前三个字段是平均负载数字，给出了运行队列（状态R）或等待磁盘I / O（状态D）在1、5和15分钟内平均的作业数。它们与uptime（1）和其他程序给出的平均负载数相同。

第四个字段由用斜杠（/）分隔的两个数字组成。其中第一个是当前正在执行的内核调度实体（进程，线程）的数量；这将小于或等于CPU的数量。斜杠后的值是系统上当前存在的内核调度实体的数量。

第五个字段是系统上最近创建的过程的PID。

— 奥瑟伦
source

1

make使用--load-average=N.N参数运行GNU时，用户应考虑这些值。如果make导致平均负载在数值上高于CPU内核数，make则应--load-average减少重启。这样，编译不会使系统过载。

2

如果系统在5分钟之前启动，那么他们将如何计算15分钟的平均负载？他们会只使用5分钟的数据吗？

— shafeeq

3

至少当前的手册页中没有包含“小于或等于CPU数量”的字样，并且当您有更多可运行的进程时，该数量大于cpus的数量。

— 朋友

1

第五个字段不像答案中所述：实际上，这是最后分配的PID。

— Mike Aski

19

我想评论一下已接受的答案。

第四个字段由两个数字组成，两个数字之间用斜杠（/）分隔。其中第一个是当前正在执行的内核调度实体（进程，线程）的数量；这将小于或等于CPU的数量。

我做了一个测试程序，该程序从输入中读取整数N，然后创建N个线程并使其永远运行。在RHEL 6.5计算机上，我有8个处理器，每个处理器都有超线程。无论如何，如果我运行测试并创建128个线程，则在第四字段中看到的值大于128，例如135。显然，该值大于CPU的数量。这篇文章支持我的观察：http : //juliano.info/en/Blog : Memory_Leak/Understanding_the_Linux_load_average

值得注意的是，proc（5）手册页中的当前解释（自2009年3月的手册页版本3.21起）是错误的。它报告第四字段的第一个数字作为当前正在执行的调度实体的数量，因此预测它不能大于CPU的数量。这与实际实现不匹配，在实际实现中，此值报告当前可运行线程的数量。

— 用户名
source

5

可以确认：kernel / sched / core.c nr_running（）将自身描述为收集可运行对象，而不是运行任务。

— fche

14

前三列测量最后一分钟，五分钟和十五分钟的CPU和I / O利用率。第四列显示当前正在运行的进程数和进程总数。最后一列显示最后使用的进程ID。

https://docs.fedoraproject.org/zh-CN/Fedora/17/html/System_Administrators_Guide/s2-proc-loadavg.html

— 皮斯克沃离开大楼
source

6

我强烈反对这个定义。前三个数字不会测量CPU和I / O利用率直接，他们是在运行队列中作业的平均数或等待I / O，从@auselen状态答案。

— 扬

1

下一页详细解释了这些：

http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

我将解释从上一页获得的这些数字，如下所示：

如果平均值为0.0，则您的系统处于空闲状态。
如果1分钟的平均值高于5分钟或15分钟的平均值，则负载正在增加。
如果1分钟的平均值低于5或15分钟的平均值，则负载正在减少。如果它们高于您的CPU数量，那么您可能会遇到性能问题（取决于情况）。

— Validus Oculus
source