服务器负载、CPU性能判断

说在前面：

在linux操作系统中，我们一般查看系统的cpu负载情况常用的命令可以是uptime，top，还有vmstat等这些个都是可以有的。每个工具所提供的信息各不相同，

我这里要讨论的仅说cpu部分。使用uptime命令，可以得到操作系统在过去1分钟，5分钟和15分钟的cpu平均负载值，也就是传说中的 load average，这个和top命令右上角那个地方显示出来的东东是想通的，那么这个load average到底是个什么样的东西呢，其实它表示的就是在cpu里面运行的进程数量，不过这里的进程和使用命令来查看到的进程可不太一样。在一定时间内 cpu所能处理和承载的进程数量是有限的，这个数值与cpu的性能有直接关系，或者说这个数值标志着cpu的性能高低，反应到实际的计算机使用上来就是更高性能的cpu可以在同一时间处理更多进程内容，所以说，一般当你去电脑城买个人电脑的时候导购就会问你电脑的大致用途，其实他们这个时候是在帮你计算你所需要的电脑性能，其中就包括计算cpu的最大负载值，当然他们一般都不会这么去算，而是根据价格，因为价格高的cpu往往性能就更好，紧接着，他们会问你大概的预算，其实当了解到你买电脑的用途之后他们自己心里已经帮你预算好了，如果你的预算高于他们的预算，那么恭喜那位卖电脑的，他可以多赚点了。所以买电脑一定要根据实际需求，比如说cpu支持很高的负载，而你在实际使用中却根本达不到那么高的负载，那不就成了杀鸡用杀猪刀么。

说到底，cpu在单位时间内所能处理的进程数越高，那它的性能应该就越高。但是关于这个负载，网上资料有很多种说法，有的说是负载不应该超过cpu的核心数量，有的说不应该超过cpu核心数量的2倍，有的说不应该超过cpu核心数量的3倍，为什么会有这么多种说法呢，其实大家都是担心一个相同的问题----怕cpu扛不住，这里超不超过几倍不要紧，最主要的判断标准是你的cpu在达到一定程度负载的时候是不是系统和应用程序依然运行良好，也就是说判断标准还与实际的应用有关，如果cpu的负载都超了核心数好几倍但是软件运行还依然顺畅，那这个也是可以有的。这里就得说说cpu的运行队列了，有关运行队列的状态参数可以通过vmstat命令来查看，这里不多做解释，它有两项，一项是run，一项是blocked，也就是vmstat查看到的最前面的两排，run代表正在cpu里面执行的，blocked代表由于磁盘或其他方面的瓶颈导致他在cpu里面等待的，这两个数值其实和使用uptime 或者top命令查看到的系统负载值是很有关系的，基本上，系统在某个时间的负载值就等同于run的值加上blocked的值，但是这里直接这样用加法来表示也是不对的，系统负载值是一个平均值，可以是小数，而运行队列的数目是整数。在cpu处于空闲的情况下，run+blocked一般接近0，偶尔蹦出个 1啊2啊的，所以空闲状态下的负载均值一般都是0.几。

但是，当系统的负载逐渐升高，也就是说cpu里运行的东东逐渐变多，那么反应到负载均值上其数值也会跟着逐渐增大，而且可以是很大很大，完全超出 cpu核心数的好多倍，比如我前几天用一台8核机器做测试的时候用top命令查看到的负载值居然达到了将近600，这已经远远超出了cpu可承受的范围，那为什么已经超出了可接受范围这个负载均值还可以涨到那么高呢，这是因为在cpu里，同一时间可以运行的进程数量有限的，也就是说，vmstat查看到的 run值最大不能超过某个数，但是blocked却可以继续变大，因为进程已经blocked掉了，它几乎占用不了多少cpu资源，而正在run的就不一样了，一个cpu同一时间能run多少完全取决于它的物理性能，所以当你的机器负载不断升高，你用top命令查看到的负载值也会不断升高，而当负载达到一定高度时，cpu能处理的运行队列也达到上限，run的值不再增加，这时，blocked的值会继续增加，理论上，blocked可以一直增加到直到系统崩溃。

总结：在评估cpu的性能优劣时完全照搬网上说的几倍几倍是不准确的，还得你自己动手看看vmstat显示的run值和blocked值，当出现明显较多的blocked的时候，就说明cpu产生了瓶颈。而top命令和uptime命令显示的负载均值，只能作为判断系统过去某个时间段的状态的参照，与cpu的性能关系不大。

关于CPU，有3个重要的概念：上下文切换（context switchs），运行队列（Run queue）和使用率（utilization）。

上下文切换：

目前流行的CPU在同一时间内只能运行一个线程，超线程的处理器可以在同一时间运行多个线程（包括多核CPU），Linux内核会把多核的处理器当作多个单独的CPU来识别。
　一个标准的Linux内核可以支持运行50～50000个进程运行，对于普通的CPU，内核会调度和执行这些进程。每个进程都会分到CPU的时间片来运行，当一个进程用完时间片或者被更高优先级的进程抢占后，它会备份到CPU的运行队列中，同时其他进程在CPU上运行。这个进程切换的过程被称作上下文切换。过多的上下文切换会造成系统很大的开销。

[work106 ~]$ vmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 4  0 1874084 3341144 296868 16677400    0    0     0     9    0    0  7  1 91  0  0

cs表示上下文切换的数量

运行队列

每个CPU都会维持一个运行队列，理想情况下，调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载，就会出现调度器跟不上系统的要求，导致可运行的进程会填满队列。队列愈大，程序执行时间就愈长。

[work106 ~]$ uptime

 11:44:52 up 839 days, 19:55,  2 users,  load average: 11.11, 10.33, 9.94

"load average" 用来表示运行队列，用top 命令我们可以看到CPU一分钟，5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。

[work106 ~]$ vmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 4  0 1874084 3341144 296868 16677400    0    0     0     9    0    0  7  1 91  0  0

r表示运行队列的大小，r的参考值是：小于4，队列大于4时，表明系统的cpu或内存可能有问题，如果r经常大于4，且id经常少于40，表示cpu的负荷很重。当队列变长时，队列中进程在等待cpu调度执行时所花的时间会变长.

id参考值： 大于40，如果r经常大于4，且id经常小于40，表示cpu的负荷很重。

wa 参考值：小于25%，超过25%的wa的值可以表示磁盘子系统可能没有被正确平衡，也可能是磁盘密集工作负载的结果，系统的磁盘或其它I/o可能有问题，可以通过iostat/SAR –C命令进一步分解分析

关于时间片和动态优先级

时间片对于CPU来说是很关键的参数，如果时间片太长，就会使系统的交互性能变差，用户感觉不到并行。如果太短，又会造成系统频繁的上下文切换，使性能下降。对于IO Bound的系统来讲并不需要太长的时间片，因为系统主要是IO操作；而对于CPU Bound的系统来说需要长的时间片以保持cache的有效性。
　　每一个进程启动的时候系统都会给出一个默认的优先级，但在运行过程中，系统会根据进程的运行状况不断调整优先级，内核会升高或降低进程的优先级（每次增加或降低5），判断标准是根据进程处于sleep状态的时间。
　　IO Bound进程大部分时间在sleep状态，所以内核会调高它的优先级，CPU Bound进程会被内核惩罚降低优先级。因此，如果一个系统上即运行IO Bound进程，又运行CPU Bound进程，会发现，IO Bound进程的性能不会下降，而CPU Bound进程性能会不断下降。

经验总结：

top - 12:00:20 up 839 days, 20:11,  2 users,  load average: 10.54, 10.15, 9.87

Tasks: 228 total,   1 running, 227 sleeping,   0 stopped,   0 zombie

Cpu(s): 66.0%us,  7.9%sy,  0.0%ni, 25.5%id,  0.5%wa,  0.0%hi,  0.2%si,  0.0%st

对于每一个CPU来说运行队列不要超过3，例如，如果是双核CPU就不要超过6；
如果CPU在满负荷运行，应该符合下列分布，
a) User Time：65%～70%, us过大，说明有用户进程占用很多cpu时间，需要进一步的分析其它软硬件因素。
b) System Time：30%～35%，sy过大，说明系统管理方面花了很多时间，说明该系统中某个子系统产生了瓶颈，需要进一步分析其它软硬件因素。
c) User Time+System Time ,合理值范围是 60-85%，如果在一个多用户系统中us+sy时间超过85%，则进程可能要花时间在运行队列中等待，响应时间和业务吞吐量会受损害
d) Idle：0%～5%, CPU完全空闲的百分比
对于上下文切换要结合CPU使用率来看，如果CPU使用满足上述分布，大量的上下文切换也是可以接受的。
出现cpu计数器不在范围时，不一定是由于cpu资源不够，因为其他资源的也会引起，例如内存不够时，cpu会忙内存管理的事，表面上可能是cpu的利用为100%

转自：https://www.jianshu.com/p/a19202a926fb

https://www.cnblogs.com/hecy/p/4128605.html