<p>之前我讲了cpu使用率的问题，cpu使用率是我们监控中非常关注的指标。</p><p>但是工作中，我们经常遇到业务应用已经很慢了，但是cpu利用率显示很低。</p><p>这种时候，你会发现top中load很高。</p><p>在top中，load average后面有3个数字。分别代表1分钟，5分钟和15分钟的平均负载。</p><p>是对过去一段时间的负载情况的反应。</p><h2><span/><span>对load average的正确理解</span><span/><span> </span></h2><p>假设一台只有1个cpu的服务器，如果此时cpu在运行一个进程，并且没有其他等待运行的进程。那么现在的load就是1。</p><p>如果此时还有2个进程在等待运行，那么load就是3</p><p>也就是说<strong>load = 正在运行的进程数 + 等待运行的进程数</strong></p><p>对于一个24C的服务器，如果只有10个进程在运行，那么load就是10</p><p>不管cpu的使用率是多少。所以我们通常建议说最好的情况是load 大致等于cpu数。这样表示cpu都在工作，没有浪费。又不至于太忙导致任务等待。</p><p><strong>这是理想的情况。</strong></p><p>实际上，我们经常遇到cpu利用率几乎是0，但是load非常高的情况。</p><p>这是因为我们假设了服务器其他模块全部都非常给力，没有拖后腿。但是在实际的业务中，磁盘或者网络总是会出问题的。</p><p>比如同样的业务应用场景，服务器配置一样，将高速磁盘换成低速磁盘，会明显感受到应用性能的降低。</p><p>但是如果按照前面的公式，load是不会变大的。就是说load没有真实反应服务器的性能</p><p>然后linux的一位开发者给内核打了个补丁，增加了对 TASK_UNINTERRUPTIBLE 状态进程的计数。将 TASK_UNINTERRUPTIBLE 状态的进程也计算在了load中。</p><p>在前面的文章里，我提到过TASK_UNINTERRUPTIBLE 状态。</p><div class="image-package"><img src="https://upload-images.jianshu.io/upload_images/5149787-7c5e72c3bcabc5e6.jpeg" img-data="{"format":"jpeg","size":34014,"width":1080,"height":608,"space":"srgb","channels":3,"depth":"uchar","density":72,"chromaSubsampling":"4:2:0","isProgressive":false,"hasProfile":false,"hasAlpha":false}" class="uploaded-img" style="min-height:200px;min-width:200px;" width="auto" height="auto"/>
</div>7dbd023628f5f4165abc23c1d67aca99<p>还是看这张图，在进行磁盘io操作的时候，进程就会进入这个状态。</p><p>TASK_UNINTERRUPTIBLE 根据名字就能猜到这个状态是不能被打断的。这对于保证某些关键操作的原子性和完整性是必要的。</p><p>比如write()操作可不能执行一半被打断。</p><p>TASK_UNINTERRUPTIBLE状态的进程，在系统里显示位D状态。</p><p>进程状态 "D" 代表 "Uninterruptible Sleep" 或 "Disk Sleep"。这通常意味着进程正在等待 I/O 操作，如从磁盘读取数据，而这个操作目前无法完成，可能是因为物理设备（如硬盘）正在忙碌，或者数据尚未准备好。</p><p>可以查询一下系统里是否有D进程</p>ps -eo pid,stat | grep -w 'D'
<p>有D进程不是啥好事，如果D进程太多，一定要分析出根因。因为D进程会显著拖慢整个系统，使load上升。</p><p>可以 cat /proc/<pid>/stack, 看到进程停在内核中的哪个函数上，结合内核的代码，猜一下到底是卡在哪里。</p><p>总结，</p><p><strong>load = 可运行的进程数 + D状态的进程数</strong></p><p>对于load可以做一个比方，每个cpu是一条道路，进程就是路上的车。单位时间通过的车辆数就是load值。</p><p>可以想象load值不会等于车的数量，因为有红绿灯的存在。绿灯就是进程在等待的资源。</p><p>
</p>