系统管理员工具包-监视运行缓慢的系统 - 图文

系统管理员工具包: 监视运行缓慢的系统

简介： 当您的 UNIX? 系统运行迟缓的时候，及时发现问题是至关重要的，这样就可以使得系统恢复到正常的运行模式。有许多原因都会导致系统运行迟缓，但有效地确定问题可能相当困难。在本文中，通过一些学习示例介绍了如何确定和诊断导致您的 UNIX 系统运行迟缓的原因，以便使计算机重新恢复到正常运行状态。 关于本系列 通常，UNIX? 管理员都拥有一套他/她经常使用的用来辅助进程管理任务的实用程序、技巧和系统。有一些重要的实用程序、命令行以及脚本可用来简化各种处理过程。这些工具中有一部分来自于操作系统，而大部分的技巧则来源于长期的经验和简化系统管理员工作的要求。本系列文章主要专注于最大限度地利用各种 UNIX 环境中可用的工具，包括简化异类环境中管理任务的方法。 导致系统运行迟缓的原因 有许多不同的潜在的原因会导致系统运行迟缓，但通常可以将它们分为以下几个方面： 进程太多。您的系统可能仅仅只是同时运行了太多的应用程序，或者正在运行少量 CPU 密集型的操作。要么是服务器超负荷运行，要么是失控进程耗尽了系统资源。 ? 活动内存太多。如果进程使用了大量的内存，那么系统可能会从磁盘换入大量的页面并将大量的页面换出到磁盘，这意味着您的系统花费在内存交换上的时间比真正使用内存的时间更多。

? 硬件故障。有时候，您会碰到导致系统运行迟缓的硬件故障。不能正常工作的网卡、硬盘或内存，都可能导致系统花费很长的时间等待信息。

?

要对该问题进行诊断，您需要使用大量可用的工具来检查您的 UNIX 系统。 选择连接方法 如果您的计算机运行得特别慢，那么第一个问题是如何连接到该计算机以便启动监视进程。运行迟缓的计算机可能无法接受 Telnet 或通过远程 Shell 协议（如 ssh）的连接。 如果您尚未登录到系统，那么可能根本无法进行访问。相反，可以考虑直接或通过独立的硬件解决方案（如网络或基于串口的控制台监视器）来使用控制台。 这种控制台更有可能允许您登录到系统，因为已经有一个登录进程（您的 Shell 将会代替它）正在运行。如果在登录到系统后，您无法通过 Shell 运行任何进程，则表示系统已经耗尽了进程空间，那么重新启动可能是使系统恢复正常的唯一办法。 要重新启动系统，请使用 init 或 telinit 来调整运行级别，运行级别 6 通常表示重新启动。使用 init/telinit 更有可能重新启动系统，因为在进行重新启动时仅涉及到了一个进程。 在系统启动并运行后，您需要使用本文中介绍的一些技巧来监视该系统的运行状态并记录其输出结果。如果再次出现系统运行迟缓的情况，您可以执行事后检查调试并分析系统运行迟缓的原因。 使用 uptime 如果您怀疑计算机运行得很慢，那么您应该运行的第一个命令是 uptime。Uptime 报告当前时间、计算机启动和运行时间（换句话说，是从计算机启动以来的时间）以及当前的用户数。然后它会提供三幅图表，以显示最近 1 分钟、5 分钟和 15 分钟的平均负载。例如： $ uptime

18:28:54 up 10 days, 8:38, 2 users, load average: 2.24, 5.34, 3.42

在这个示例中，该计算机在最近 1 分钟、5 分钟和 15 分钟内的平均负载分别超过了 2、5 和 3。

平均负载的定义比较复杂，并且受到正在执行的进程的状态影响。通常，正在运行、等待 CPU 或等待 I/O 的每个进程都会使平均负载加 1。然后对这些图表进行计算并根据时间平均。

在单 CPU 的系统中，平均负载大于 1 则表示该 CPU 难以承受您所分配的负载类型。但是因为 UNIX 的多进程的本质，在您关注到该问题前，平均负载在长时间内（换句话说，对应于 15 分钟的图表）达到 2 通常是可以接受的。 在多 CPU（或多核）系统中，需要将平均负载除以 CPU 的个数。要确定计算机是否超负荷运行，请使用上述原则。

查看这些图表的另一种可选的方法是将它们看作百分比，换句话说，如果上面的图表来自于一个单 CPU 系统，那么如果该计算机的速度比目前快百分之 224，那么它就能够处理当前的负载。

在多 CPU 系统中，您应该使用 CPU 数目加 1 来确定最大负载。例如，一个 4 CPU 的系统可以承受的最大平均负载为 5。 通常在短时间内，计算机的平均负载可能比其最大平均负载高的多。例如，当构建或编译一个应用程序、或执行一项磁盘密集型任务时，平均负载可能会激增。这正是输出结果中包含 1、5 和 15 分钟平均值的原因，因为这样可以帮助消除任何瞬态负载极大值。 任何长时间的或未预料到的较高的值都可能表示存在问题，并且需要进行进一步的研究。如果这些数值较低，但系统却运行迟缓，那么可能表示存在交换空间的问题。 使用 ruptime 如果您管理着由许多系统组成的大型网络，那么有一种简单的方法来监视负载和网络中所有计算机的使用情况。ruptime 工具收集网络上所有计算机广播的数据，并将其集中到一个本地文件中，以便对所有计算机的当前状态进行检查。 例如，清单 1 显示了一个小型网络的输出结果： 清单 1. 一个小型网络的输出 $ ruptime

bear up 10+09:13, 2 users, load 0.66, 0.68, 0.50 ultra3 up 6+01:16, 1 user, load 0.00, 0.00, 0.00 atuin down 4+00:52 最后一台计算机 11 分钟内没有报告任何数据，所以将其列为停机。 要生成这些信息，需要在本地网络中的每台计算机上运行 rwhod 守护进程（有时候是 in.rwhod）。这个守护进程为本地计算机广播信息，并收集来自所有其他计算机的广播数据。 因为 rwho/ruptime 系统的工作方式的原因，所以可能存在一些性能问题，尤其是在大型的网络中，它们生成的大量的系统报告和网络流量可能是有害的。在非常繁忙的系统中，对这些数据进行广播的需求可能也就意味着永远无法报告这些信息，这些数据可能过期，或者在系统繁忙时将其报告为停机。 跟踪大型进程 如果您怀疑是一个大型的或过度繁忙的进程导致了该问题，那么您应该检查 ps 工具的输出，查找进程大小、内存百分比和 CPU 利用率。在 SVR4 系统（Solaris 和 AIX?）中，您可以使用下列命令来获得进程的列表（请参见清单 2）。 清单 2. 获得进程列表的命令 $ ps -A -o pcpu,pmem,rss,vsz,comm %CPU %MEM RSS VSZ COMMAND 0.2 0.0 0 0 fsflush 0.1 0.2 1464 8288 /usr/lib/ssh/sshd 0.1 0.1 1032 1320 ps 0.0 1.0 9536 47608 /usr/openwin/bin/Xsun 0.0 0.7 6312 10720 dtgreet 0.0 0.6 6136 9352 /usr/sfw/sbin/snmpd 0.0 0.4 3208 5720 /usr/lib/fm/fmd/fmd 0.0 0.3 2808 8512 /usr/lib/ssh/sshd 0.0 0.3 2800 8504 /usr/lib/ssh/sshd 0.0 0.3 2768 8512 /usr/lib/ssh/sshd 0.0 0.3 2368 4056 /usr/sbin/nscd 0.0 0.2 2096 9176 /usr/dt/bin/dtlogin ... 清单 3 显示了在 BSD 派生系统中的 ps 工具的输出。 清单 3. 一个 BSD 系统中获得的进程列表 $ ps -A -o pcpu,pmem,rss,vsz,command|sort -n +3 %CPU %MEM RSS VSZ COMMAND 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 152 27236 nfsd-server 0.0 0.0 164 27236 nfsd-master 0.0 0.0 224 27240 /usr/sbin/update 0.0 0.3 4364 29196 /usr/sbin/securityd 0.0 0.2 2760 29288 jabberd -c /etc/jabber/jabber.xml -H