在使用云桌面的过程中，有时候同事们反应有点慢。往往我们每次去定位变慢原因，都会先查看网络或者系统负载情况，初步定位变慢的原因。 网络可以通过ping之类，系统负载往往是通过htop或者watch -d uptime动态查看。

uptime输出结果 ：

上述的输出中，最后的三个数字，分别代表了过去1，5，15分钟的平均负载（平均负载是什么呢？ 就是指单位时间内，操作系统中处理可运行（R）和不可中断（D，等待I/0响应）状态的进程数）统计。

       上述的三个数字到底是处理什么范围才是一个合理的呢？

       下面简短的描述下个人总结。要知道是否合理，首先确认系统的cpu个数，可通过 htop 命令或者grep -a "model name" /proc/cpuinfo | wc -l 可确认。可以把cpu想象成马路上的车道，进程是运行的汽车，一个进程运行在一个cpu上，就不会出现另外的进程抢不到cpu时间片，而需要等待的情况。 业界经验总结通常 load average = cpu个数 * 70%以下，认为是理想运行状态，而长期大于cpu个数，认为是系统出现了过载。

       那是不是load average处理70%以上，都是问题呢？ 不是的，我们要结合三个数值来分析：

1、如果1分钟的数值大于cpu个数，而5，15分钟小于cpu个数，说明过载情况可能是突发性抖动，也可能持续，要继续观察；

2、如果1、5分钟的数值大于cpu个数，而15分钟小于cpu个数，说明负载情况正在发生；

3、如果1、5、15分钟的数值都大于cpu个数，说明负载情况持续一段时间；

4、如果5、15分钟的数值都大于cpu个数，而1分钟数值小于cpu个数，说明负载情况出现减缓现象；

其中2、3的场景，结合iostat，vmstat命令去具体定位是cpu，还是I/O等待，定位相对会容易些。场景1，可能引起突发的进程已经减缓，需要持续长时间观察。