尽管服务器的绝大部分问题都与网络有关，但是还有一类问题仅与本地服务器相关。让这个问题变得棘手的是：本地服务器问题和网络问题经常表现出相同地征兆。事实上，服务器本地的问题会导致网络问题，而将影响网络的问题留到第五章介绍。
几乎DevOps团队中的所有成员都遇到过性能不好或响应缓慢的主机，不论是试图查出问什么最近一次提交比之前慢很多的开发者，在代码部署到生产环境之前努力执行负载测试的QA工程师，还是需要确定是否应该购买更多RAM、CPU或运行速度更快的磁盘的系统管理员。这些技术甚至可以帮你排除Linux桌面系统中的负载问题。
关于主机最常见的一个问题可能是性能太差,甚至都无法响应。通常，网络故障会引发这个问题,但本章将会介绍一些本地排除故障的工具，借助这些工具可以分辨出网络过载和机器过载之间的区别。
机器运行缓慢通常是由于消耗了太多系统特定的资源。系统的主要资源包括CPU、RAM、磁盘I/O以及网络（将在第五章介绍）。过度使用这些资源的任何一种就都会让系统陷入困境，此时唯一的解决方法就是——重启。不过如果能登录到系统之中，则可以借助大量工具确定问题的起因。
2.1 系统负载
解决引起系统运行缓慢的问题时，平均系统负载可能时最先用到的基本度量标准。在排除系统运行缓慢的问题时，通常我执行的第一条命令时uptime：
$ uptime
13:35:03 up 103 days, 8min, 5 users, load average: 2.03, 20.17, 15.09
load average 后面的三个数子 2.03、20.17和15.09分别代表了1分钟、5分钟和15分钟内机器的平均负载。一个系统的平均负载等于处于运行或者不可打扰状态进程的平均数。可运行的进程要么正在使用CPU，要么正在等待使用CPU；不可打扰状态的进程都在等待I/O响应。
平均负载为1的单CPU系统以为这个CPU处于恒定负载。如果单CPU系统的平均负载是4，那么这个系统平均处于它可承受负载能力的4倍，所以3/4的进程都在等待资源。一个系统的平均负载不会因为你所拥有的CPU数量而更改，所以，如果具备两个CPU的系统平均负载是1，那么其中一个CPU一直处于满负荷状态，也就是说系统处于50%的负载状态。所以，负载状态为1的单CPU系统与负载状态为1的单CPU系统与负载状态为4的四CPU系统使用资源的量一样。
1分钟、5分钟、15分钟、的平均负载描述了相对时间内的平均负载会让你对系统当前所处的状态有一个清晰的认识，所以在前面这个例子中，你能看到服务器在过去的1分钟内负载为2，但是在国储的5分钟内平均负载却飙升到了20。前15分钟内处于高负载的状态，而且5分钟前系统负载又开始增长，但是现在已经减弱。让我们将它与一个完全不同的平均负载做个对比。
$ uptime
05:11:52 up 20 days, 5min, 2 users, load average: 17.29, 0.12, 0.01
在这个例子中，5分钟内和15分钟内的平均负载都很低，但是1分钟内的平均负载却很高，所以我知道负载的飙升相对而言发生在最近。在这种情况下，通常我会连续多次运行uptime命令（或者使用top命令，马上我就会讲到这个工具）来观察负载是持续上升还是正在下降。
什么是高平均负载
一个值得研究的问题是：平均负载多少算高？简单的回答是“这取决于产生高负载的原因”。因为负载描述了正在使用资源的活动进程的平均数量，所以负载的飙升透露了很多信息。明确负载是CPU密集型（等待CPU资源的进程）、RAM密集型（争夺磁盘或网络I/O资源的进程）非常重要。
例如，如果运行的一个应用程序在不同的时间点产生大量的同步线程，这些线程会同时启动，你可能会看到负载飙升到20、40或者更高，他们在竞争系统资源。随着这些进程逐渐完成，负载就会降下来。通常CPU密集型的系统会比I/O密集型的系统响应度更高。我见过数以百计CPU密集型的系统，我仍然可以在这些系统上运行故障排除工具而且具有良好的响应时间。我也见过I/O负载相对较低的I/O密集型系统，只是登录这些系统就需要花费一段时间，因为它们的磁盘I/O完全饱和了。用尽RAM资源的系统通常与I/O密集型的系统表现相同，因为一旦系统开始使用磁盘上的交换存储，它就会消耗磁盘资源，导致进程逐渐变慢直至停止。
2.2 使用top命令解决负载问题
当需要解决高负载问题的时候，我第一个想到的工具是top命令。在命令行输入Top命令并按下Enter键后，马上就能看到大量的系统信息如图