Linux系统管理员工具包 监视运行缓慢的系统.docx

1、Linux系统管理员工具包 监视运行缓慢的系统系统管理员工具包: 监视运行缓慢的系统本书网络下载内容丰富，分享给大家学习。当您的 UNIX 系统运行迟缓的时候，及时发现问题是至关重要的，这样就可以使得系统恢复到正常的运行模式。有许多原因都会导致系统运行迟缓，但有效地确定问题可能相当困难。在本文中，通过一些学习示例介绍了如何确定和诊断导致您的 UNIX 系统运行迟缓的原因，以便使计算机重新恢复到正常运行状态。关于本系列通常，UNIX 管理员都拥有一套他/她经常使用的用来辅助进程管理任务的实用程序、技巧和系统。有一些重要的实用程序、命令行以及脚本可用来简化各种处理过程。这些工具中有一部分来自于操作

2、系统，而大部分的技巧则来源于长期的经验和简化系统管理员工作的要求。本系列文章主要专注于最大限度地利用各种 UNIX 环境中可用的工具，包括简化异类环境中管理任务的方法。导致系统运行迟缓的原因有许多不同的潜在的原因会导致系统运行迟缓，但通常可以将它们分为以下几个方面： * 进程太多。您的系统可能仅仅只是同时运行了太多的应用程序，或者正在运行少量 CPU 密集型的操作。要么是服务器超负荷运行，要么是失控进程耗尽了系统资源。 * 活动内存太多。如果进程使用了大量的内存，那么系统可能会从磁盘换入大量的页面并将大量的页面换出到磁盘，这意味着您的系统花费在内存交换上的时间比真正使用内存的时间更多。 * 硬

3、件故障。有时候，您会碰到导致系统运行迟缓的硬件故障。不能正常工作的网卡、硬盘或内存，都可能导致系统花费很长的时间等待信息。要对该问题进行诊断，您需要使用大量可用的工具来检查您的 UNIX 系统。选择连接方法如果您的计算机运行得特别慢，那么第一个问题是如何连接到该计算机以便启动监视进程。运行迟缓的计算机可能无法接受 Telnet 或通过远程 Shell 协议（如 ssh）的连接。如果您尚未登录到系统，那么可能根本无法进行访问。相反，可以考虑直接或通过独立的硬件解决方案（如网络或基于串口的控制台监视器）来使用控制台。这种控制台更有可能允许您登录到系统，因为已经有一个登录进程（您的 Shell 将会

4、代替它）正在运行。如果在登录到系统后，您无法通过 Shell 运行任何进程，则表示系统已经耗尽了进程空间，那么重新启动可能是使系统恢复正常的唯一办法。要重新启动系统，请使用 init 或 telinit 来调整运行级别，运行级别 6 通常表示重新启动。使用 init/telinit 更有可能重新启动系统，因为在进行重新启动时仅涉及到了一个进程。在系统启动并运行后，您需要使用本文中介绍的一些技巧来监视该系统的运行状态并记录其输出结果。如果再次出现系统运行迟缓的情况，您可以执行事后检查调试并分析系统运行迟缓的原因。使用 uptime如果您怀疑计算机运行得很慢，那么您应该运行的第一个命令是 upti

5、me。Uptime 报告当前时间、计算机启动和运行时间（换句话说，是从计算机启动以来的时间）以及当前的用户数。然后它会提供三幅图表，以显示最近 1 分钟、5 分钟和 15 分钟的平均负载。例如：1. $ uptime2. 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。然后对

6、这些图表进行计算并根据时间平均。在单 CPU 的系统中，平均负载大于 1 则表示该 CPU 难以承受您所分配的负载类型。但是因为 UNIX 的多进程的本质，在您关注到该问题前，平均负载在长时间内（换句话说，对应于 15 分钟的图表）达到 2 通常是可以接受的。在多 CPU（或多核）系统中，需要将平均负载除以 CPU 的个数。要确定计算机是否超负荷运行，请使用上述原则。查看这些图表的另一种可选的方法是将它们看作百分比，换句话说，如果上面的图表来自于一个单 CPU 系统，那么如果该计算机的速度比目前快百分之 224，那么它就能够处理当前的负载。在多 CPU 系统中，您应该使用 CPU 数目加 1

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

8、集网络上所有计算机广播的数据，并将其集中到一个本地文件中，以便对所有计算机的当前状态进行检查。例如，清单 1 显示了一个小型网络的输出结果：清单 1. 一个小型网络的输出1. $ ruptime2. bear up 10+09:13, 2 users,load 0.66, 0.68, 0.503. ultra3 up6+01:16, 1 user, load 0.00, 0.00, 0.004. atuin down4+00:52复制代码最后一台计算机 11 分钟内没有报告任何数据，所以将其列为停机。要生成这些信息，需要在本地网络中的每台计算机上运行 rwhod 守护进程（有时候是 in.rw

9、hod）。这个守护进程为本地计算机广播信息，并收集来自所有其他计算机的广播数据。因为 rwho/ruptime 系统的工作方式的原因，所以可能存在一些性能问题，尤其是在大型的网络中，它们生成的大量的系统报告和网络流量可能是有害的。在非常繁忙的系统中，对这些数据进行广播的需求可能也就意味着永远无法报告这些信息，这些数据可能过期，或者在系统繁忙时将其报告为停机。跟踪大型进程如果您怀疑是一个大型的或过度繁忙的进程导致了该问题，那么您应该检查 ps 工具的输出，查找进程大小、内存百分比和 CPU 利用率。在 SVR4 系统（Solaris 和 AIX®）中，您可以使用下列命令来获得进程的列表（

10、请参见清单 2）。清单 2. 获得进程列表的命令1. $ ps -A -o pcpu,pmem,rss,vsz,comm2. %CPU %MEMRSSVSZ COMMAND3. 0.20.0 0 0 fsflush4. 0.10.2 1464 8288 /usr/lib/ssh/sshd5. 0.10.1 1032 1320 ps6. 0.01.0 9536 47608 /usr/openwin/bin/Xsun7. 0.00.7 6312 10720 dtgreet8. 0.00.6 6136 9352 /usr/sfw/sbin/snmpd9. 0.00.4 3208 5720 /usr/

11、lib/fm/fmd/fmd10. 0.00.3 2808 8512 /usr/lib/ssh/sshd11. 0.00.3 2800 8504 /usr/lib/ssh/sshd12. 0.00.3 2768 8512 /usr/lib/ssh/sshd13. 0.00.3 2368 4056 /usr/sbin/nscd14. 0.00.2 2096 9176 /usr/dt/bin/dtlogin15. .复制代码清单 3 显示了在 BSD 派生系统中的 ps 工具的输出。清单 3. 一个 BSD 系统中获得的进程列表1. $ ps -A -o pcpu,pmem,rss,vsz,com

12、mand|sort -n +32. %CPU %MEM RSS VSZ COMMAND3. 0.00.0 152 27236 nfsd-server 4. 0.00.0 152 27236 nfsd-server 5. 0.00.0 152 27236 nfsd-server 6. 0.00.0 152 27236 nfsd-server 7. 0.00.0 152 27236 nfsd-server 8. 0.00.0 152 27236 nfsd-server 9. 0.00.0 152 27236 nfsd-server 10. 0.00.0 152 27236 nfsd-server

13、11. 0.00.0 164 27236 nfsd-master 12. 0.00.0 224 27240 /usr/sbin/update13. 0.00.3 4364 29196 /usr/sbin/securityd14. 0.00.2 2760 29288 jabberd -c /etc/jabber/jabber.xml -H15. /private/var/jabber/ -U jabber16. 0.00.0 184 29300 nfsiod -n 417. 0.00.2 3544 29712 /usr/sbin/configd18. 0.00.0 500 30628 /usr/

14、sbin/sshd -i19. 0.00.0 260 30648 /usr/sbin/smbd -D20. 0.00.0 736 30648 /usr/sbin/smbd -D21. 0.00.1 1216 30700 /usr/sbin/sshd -i22. .23. 0.00.1 2180 50664 imapd: narcissus.mcslp.pri 192.168.0.11024. mc user.mc 25. 0.00.1 2184 50664 imapd: sulaco.mcslp.pri 192.168.0.10126. mc user.mc 27. 0.00.1 2204 5

15、0720 imapd: narcissus.mcslp.pri 192.168.0.11028. buy user.buy 29. 0.00.1 2264 50720 imapd: sulaco.mcslp.pri 192.168.0.101 buy30. user.buy 31. 0.00.1 2272 50984 imapd: kernel.mcslp.pri 192.168.0.106 slp32. user.slp 33. 0.01.218348 54368 servermgrd -x34. 0.00.2 3200 85920 /usr/sbin/named -f35. 0.01.11

16、6820 122240 /usr/libexec/mysqld -basedir=/usr36. -datadir=/var/mysql -user=mysql -pid-file=/var/mysq37. 0.00.5 8572 158164 /usr/libexec/slapd -d 0 -h ldap:/38. ldapi:/%2Fvar%2Frun%2Fldapi39. 0.00.0 204 289396 rpc.statd复制代码在上面两个例子中，进程列表中显示了 CPU 和内存使用率，以便您能够清楚地了解系统中的负载情况。s和stat列（分别对应于 SVR4 和 BSD）显示了进程

17、的当前状态。对于大量的运行的进程，状态R表示该进程当前正在运行。通过使用状态、CPU 和内存百分比的组合，您应该可以确定是否存在失控的 和大量消耗系统资源的进程。使用 iostatiostat 工具提供了关于终端、磁盘活动和 CPU 利用率的信息。您可以指定单个数值参数来设置报告的时间间隔，并指定另一个数值参数来设置报告的数量。例如，清单 4 显示了如何每 5 秒钟报告相应的统计信息。清单 4. 每隔 5 秒报告统计信息1. $ iostat 52. tty dad1 sd1 nfs1 cpu3. tin tout kps tps servkps tps servkps tps serv us

18、 sy wt id4. 0 7 44039 14 0 0 3 0 0 0 5 180 775. 0 39 2 0 0 0 0 0 0 0 0 000 1006. 0 13 4 3 0 0 0 0 0 0 0 000 1007. 0 13 0 0 0 0 0 0 0 0 0 000 100复制代码对于不同的系统，缺省情况下显示的确切的信息也有所不同，清单 4 来自于一个 Solaris 系统。清单 5 中的示例来自于一个 BSD 环境。清单 5. 一个 BSD 系统中的 iostat1. disk1 disk0 cpu2. KB/t tpsMB/s KB/t tpsMB/sus sy id3.

19、167.67 00.0220.70 50.09 63 904. 0.00 00.00 0.00 00.00153 825. 0.00 00.00 0.00 00.00162 826. 0.00 00.0014.33240.33184 797. 0.00 00.00 2.83 10.00234 73复制代码先来看看 CPU 统计信息，这些列分别显示了用户 (us)、系统 (sy) 和空闲 (id) 百分比。用户时间显示了用于该用户进程的时间。系统时间则显示了系统进程耗费的时间（在没有显示等待时间时，包括系统等待 I/O 的时间）。空闲时间显示了 CPU 处于空闲状态的时间的百分比。磁盘的输出显示

20、了各个物理磁盘（在合适的情况下包括 NFS 加载）的工作情况，通常以每秒处理事务数和每秒传输的 MB 或 KB 作为单位。其中的较大数值，尤其是同时具有较高的等待/系统时间，可能表示对于该系统而言，磁盘的速度太慢。您可以尝试展开您的应用程序，以便它使用不同的磁盘，这样可能可以改善它的性能。如果该磁盘同时用作虚拟内存，那么可能是因为缺少内存和过多的交换的问题。使用 vmstat您可以使用 vmstat 工具来监视虚拟内存统计信息。与 iostat 一样，它接受一个数值时间间隔（请参见清单 6）。清单 6. 使用 vmstat 监视内存统计信息1. $ vmstat 52. kthr memory

21、 page disk faults cpu3. r b w swapfreeremf pi po fr de sr dd s1 - in sy 4. cs us sy id5. 0 0 0 2820888 809552 94 525 121 69 50 0 26 16 00 297 13426. 27294 877. 0 0 0 2824752 778872 2 700000000 229 348. 10901 999. 0 0 0 2824752 778872 0 000000200 233 2810. 11600 10011. 0 0 0 2824752 778872 0 00000000

22、0 228 2612. 11000 10013. 0 0 0 2824752 778872 0 000000000 229 2814. 11100 100复制代码vmstat 工具输出线程/进程信息、内存/交换区使用率、换进/换出页面、磁盘 I/O、页面错误和 CPU 统计信息。CPU/线程块显示了运行队列 (r) 中的进程/线程、等待 I/O 资源的阻塞进程 (b) 和那些被交换的进程。阻塞进程列中较高的值表示磁盘的速度较慢。交换列中较高的数值表示存在许多进程使用了太多的内存，需要对它们进行换入和换出。交换是一项开销非常高的处理，并且将明显地降低系统的性能。内存列显示了当前可用的交换区大小和

23、空闲列表的大小（如果对 RAM 提出请求，可以被交换的页面的数目）。较低的交换值表示即将耗尽交换空间，这并不一定表示存在问题，只要您拥有足够的 RAM 来运行相应的应用程序。较低的空闲列表值可能表示使用了大量的活动 RAM，如果您向该系统中添加更多的进程，那么可能引起交换空间的使用。页面列显示了从磁盘交换进来的和交换到磁盘的内存页面。键值列是 pi/po（换进/换出的页面），这表示了对多少页面进行了交换。较高的分页表示缺少 RAM，较高的扫描速率（sr 列）显示了潜在的内存瓶颈。使用 toptop 工具可以提供一种有效的方法来监视活动中的系统和活动的进程、负载以及内存统计信息。有许多不同类型的

24、 top，在缺省情况下，某些系统中安装了其中的一部分，而这些 top 是最新的开放源码版本的工具。它所提供的相关信息更像是 uptime、交换空间和 ps 工具的组合。例如，下面的输出来自于 Solaris 系统中运行的 V3.5.1 版本的 top 工具（请参见清单 7）。清单 7. 使用 toplast pid:9385;load averages:7.14,2.98,1.21 61 processes:55 sleeping, 4 running, 1 zombie, 1 on cpuCPU states:0.0% idle, 93.8% user,6.2% kernel,0.0% io

25、wait,0.0% swapMemory: 1024M real, 712M free, 125M swap in use, 2705M swap free PID USERNAME LWP PRI NICESIZE RES STATE TIME CPU COMMAND9313 root 122 0 35M 34M run 0:038.87% cc19349 root 122 0 21M 20M run 0:015.47% cc19385 root 139 0 4320K 3904K run 0:000.38% as9384 root 129 0 3888K 3424K run 0:000.3

26、0% as9145 root 159 0 3736K 2144K cpu 0:000.11% top9180 root 159 0 1808K 1472K sleep 0:000.10% make 486 root 159 0 46M 9536K sleep 0:000.03% Xsun 548 root 159 0 10M 6360K sleep 0:000.03% dtgreet 553 mc 149 0 8288K 1472K sleep 0:010.02% sshd9345 root 149 0 1328K928K sleep 0:000.01% gcc9348 root 159 0

27、1328K928K sleep 0:000.01% gcc9325 root 149 0 1328K928K sleep 0:000.01% gcc 599 mc 159 0 8288K 1488K sleep 0:000.00% sshd9312 root 159 0 1328K928K sleep 0:000.00% gcc 9 root 1659 0 9464K 2016K sleep 0:060.00%svc.configdtop 工具显示了各个进程的 CPU 使用情况，例如，在前面的示例中，可以看到正在编译大量的文件以及它们使用 CPU 的比例。您还应该注意进程的状态：较高的运行进程的数目可能表示系统过于繁忙（将运行进程与 CPU 状态和系统的平均负载进行比较）。Top 本身可能耗费大量的 CPU，所以最好是以较大的更新时间间隔来运行它，以避免监视工作对系统性能带来损害。您可以使用 -s 或 -d 命令行选项（根据您使用的平台来决定）以秒为单位来指定更新的时间间隔。使用 SAR有些时候，您需要在系统出现问题后对其状态进行监视，但是却又无法实时监视服务器