# Linux命令：uptime

# 环境

• CentOS Linux release 7.3.1611 (Core)

# 功能

查系统运行了多长时间，当前登录用户数，以及当前系统平均负载。

uptime [options]

# 输出结果

$ uptime 
 21:33:09 up 3 days, 12:09,  2 users,  load average: 0.00, 0.01, 0.05

# load average

当CPU完全空闲的时候，平均负荷为0；当CPU工作量饱和的时候，平均负荷为1。那么很显然，"load average"的值越低，就说明电脑的工作量越小，系统负荷比较轻。

那么什么情况下系统的负荷较重呢？等于1的时候，还是等于0.5或等于2的时候。判断系统负荷是否过重，必须理解load average的真正含义。

# 举例

假设电脑只有一个CPU,所有运算都需要通过这个CPU来完成，那么我把这个CPU想象成一座大桥，桥上只有一个车道，所有车辆都必须从这个车道通过。

系统负荷为0，也就是说桥上一辆车都没有

系统负荷为0.5，意味着大桥一半的路段有车

系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。

系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。

CPU的系统负荷，基本上等同于大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。

如果CPU每分钟最多处理100个进程

• 系统负荷0.2，意味着CPU在这1分钟里只处理20个进程
• 系统负荷1.0，意味着CPU在这1分钟里正好处理100个进程
• 系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理

和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态下，都希望负载平均值小于1.0，当然不排除部分峰值会超过1.0，但长此以往保持这个状态，就说明会有问题，这时候你应该会很焦急。

# 系统最佳负载

所以说的理想负荷为1.0？

嗯，这种情况其实并不完全正确。负荷1.0说明系统已经没有剩余的资源了。在实际情况中，有经验的系统管理员都会将这条线划在0.7。

• 需要进行调查法则：如果长期你的系统负载在你需要在事情变得更糟糕之前，花些时间了解其原因
• 现在就要修复法则：如果你的服务器系统负载长期徘徊1.0，那么就应该马上解决这个问题

# 多CPU

上面我们只假定电脑只有一个CUP，如果电脑有两个CPU，意味着电脑处理能力翻倍了，也是就说大桥变双车道了。

所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。以此类推，n个CPU的电脑，可接受的系统负荷最大为n.0。

# 多核处理器

在系统负荷方面，多核CPU与多CPU效果类似，所以考虑系统负荷的时候，必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后，把系统负荷除以总的核心数，只要每个核心的负荷不超过1.0，就表明电脑正常运行

# 最佳观察时长

• 如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。
• 如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。所以，你应该主要观察"15分钟系统负荷"，将它作为电脑正常运行的指标。

# 参考

• 理解Linux系统负荷
• Understanding Linux CPU Load