文档介绍：uptime命令,有两大用处,一个是看您的机器的运行时间,另一个就是看看您的cpu 负载如何?
uptime
10:19:04 up 257 days, 18:56, 12 users, load average: , ,
1、10:19:04 //系统当前时间
2、up 257 days, 18:56 //主机已运行时间,时间越大,说明你的机器越稳定。
3、12 user //用户连接数,是总连接数而不是用户数
4、load average // 系统平均负载,统计最近1,5,15分钟的系统平均负载
前面三项很容易理解,对于第四项的解释,从网上找到一篇分析得非常易懂的文章
很多人会这样理解负载均值:三个数分别代表不同时间段的系统平均负载(一分钟、五分钟、以及十五分钟),它们的数字当然是越小越好。数字越高,说明服务器的负载越大,这也可能是服务器出现某种问题的信号。
而事实不完全如此,是什么因素构成了负载均值的大小,以及如何区分它们目前的状况是“好”还是“糟糕”?什么时候应该注意哪些不正常的数值?
回答这些问题之前,首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明, 一台只配备一块单核处理器的服务器。
一只单核的处理器可以形象得比喻成一条单车道。设想下,你现在需要收取这条道路的过桥费-- 如果您忙于处理那些将要过桥的车辆。你首先当然需要了解些信息,例如车辆的载重、以及还有多少车辆正在等待过桥。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。如果车辆众多,那么需要告知他们可能需要稍等一会。
因此,需要些特定的代号表示目前的车流情况,例如:
• 表示目前桥面上没有任何的车流。实际上这种情况与 和 之间是相同的,总而言之很通畅,过往的车辆可以丝毫不用等待的通过。
• 表示刚好是在这座桥的承受范围内。这种情况不算糟糕,只是车流会有些堵,不过这种情况可能会造成交通越来越慢。
•超过 ,那么说明这座桥已经超出负荷,交通严重的拥堵。那么情况有多糟糕? 例如 的情况说明车流已经超出了桥所能承受的一倍,那么将有多余过桥一倍的车辆正在焦急的等待。 的话情
况就更不妙了,说明这座桥基本上已经快承受不了,还有超出桥负载两倍多的车辆正在等待。
上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程在队列中等待的时间。
和收过桥费的管理员一样,你当然希望你的汽车(操作)不会被焦急的等待。所以,理想状态下,都希望负载平均值小于 。当然不排除部分峰值会超过 ,但长此以往保持这个状态,就说明会有问题,这时候你应该会很焦急。
“所以你说的理想负荷为 ?”
嗯,这种情况其实并不完全正确。负荷 说明系统已经没有剩余的资源了。在实际情况中,有经验的系统管理员都会将这条线划在 :
•“需要进行调查法则”: 如果长期你的系统负载在 上下,那么你需要在事情变得更糟糕之前,花些时间了解其原因。
•“现在就要修复法则”: 。如果你的服务器系统负载长期徘