導致系統運行遲緩的原因

有許多不同的潛在的原因會導致系統運行遲緩，但通常可以將它們分為以下幾個方面：

進程太多。您的系統可能僅僅只是同時運行了太多的應用程序，或者正在運行少量 CPU 密集型的操作。要么是服務器超負荷運行，要么是失控進程耗盡了系統資源。 活動內存太多。如果進程使用了大量的內存，那么系統可能會從磁盤換入大量的頁面并將大量的頁面換出到磁盤，這意味著您的系統花費在內存交換上的時間比真正使用內存的時間更多。 硬件故障。有時候，您會碰到導致系統運行遲緩的硬件故障。不能正常工作的網卡、硬盤或內存，都可能導致系統花費很長的時間等待信息。

要對該問題進行診斷，您需要使用大量可用的工具來檢查您的 Unix 系統。

選擇連接方法

如果您的計算機運行得特別慢，那么第一個問題是如何連接到該計算機以便啟動監視進程。運行遲緩的計算機可能無法接受 Telnet 或通過遠程 Shell 協議（如 ssh）的連接。

如果您尚未登錄到系統，那么可能根本無法進行訪問。相反，可以考慮直接或通過獨立的硬件解決方案（如網絡或基于串口的控制臺監視器）來使用控制臺。

這種控制臺更有可能允許您登錄到系統，因為已經有一個登錄進程（您的 Shell 將會代替它）正在運行。如果在登錄到系統后，您無法通過 Shell 運行任何進程，則表示系統已經耗盡了進程空間，那么重新啟動可能是使系統恢復正常的唯一辦法。

要重新啟動系統，請使用 init 或 telinit 來調整運行級別，運行級別 6 通常表示重新啟動。使用 init/telinit 更有可能重新啟動系統，因為在進行重新啟動時僅涉及到了一個進程。

在系統啟動并運行后，您需要使用本文中介紹的一些技巧來監視該系統的運行狀態并記錄其輸出結果。如果再次出現系統運行遲緩的情況，您可以執行事后檢查調試并分析系統運行遲緩的原因。

使用 uptime

如果您懷疑計算機運行得很慢，那么您應該運行的第一個命令是

uptime

。

Uptime

報告當前時間、計算機啟動和運行時間（換句話說，是從計算機啟動以來的時間）以及當前的用戶數。然后它會提供三幅圖表，以顯示最近 1 分鐘、5 分鐘和 15 分鐘的平均負載。例如：

$ uptime18: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. 一個小型網絡的輸出

$ ruptimebear　up 10+09:13, 2 users,　load 0.66, 0.68, 0.50ultra3up　6+01:16, 1 user,　 load 0.00, 0.00, 0.00atuin　 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 COMMAND0.2　0.000 fsflush0.1　0.2 1464 8288 /usr/lib/ssh/sshd0.1　0.1 1032 1320 ps0.0　1.0 9536 47608 /usr/openwin/bin/Xsun0.0　0.7 6312 10720 dtgreet0.0　0.6 6136 9352 /usr/sfw/sbin/snmpd0.0　0.4 3208 5720 /usr/lib/fm/fmd/fmd0.0　0.3 2808 8512 /usr/lib/ssh/sshd0.0　0.3 2800 8504 /usr/lib/ssh/sshd0.0　0.3 2768 8512 /usr/lib/ssh/sshd0.0　0.3 2368 4056 /usr/sbin/nscd0.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 %MEMRSS　VSZ COMMAND　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.015227236 nfsd-server　0.0　0.016427236 nfsd-master　0.0　0.022427240 /usr/sbin/update　0.0　0.3　 436429196 /usr/sbin/securityd　0.0　0.2　 276029288 jabberd -c /etc/jabber/jabber.xml -H/private/var/jabber/ -U jabber　0.0　0.018429300 nfsiod -n 40.0　0.2　 354429712 /usr/sbin/configd　0.0　0.050030628 /usr/sbin/sshd -i　0.0　0.026030648 /usr/sbin/smbd -D　0.0　0.073630648 /usr/sbin/smbd -D　0.0　0.1　 121630700 /usr/sbin/sshd -i...　0.0　0.1　 218050664 imapd: narcissus.mcslp.pri [192.168.0.110]mc user.mc　　0.0　0.1　 218450664 imapd: sulaco.mcslp.pri [192.168.0.101]mc user.mc　0.0　0.1　 220450720 imapd: narcissus.mcslp.pri [192.168.0.110]buy user.buy　0.0　0.1　 226450720 imapd: sulaco.mcslp.pri [192.168.0.101] buyuser.buy　　0.0　0.1　 227250984 imapd: kernel.mcslp.pri [192.168.0.106] slpuser.slp　　0.0　1.2　1834854368 servermgrd -x　0.0　0.2　 320085920 /usr/sbin/named -f　0.0　1.1　16820　 122240 /usr/libexec/mysqld --basedir=/usr--datadir=/var/mysql --user=mysql --pid-file=/var/mysq　0.0　0.5　 8572　 158164 /usr/libexec/slapd -d 0 -h ldap:///ldapi://%2Fvar%2Frun%2Fldapi　0.0　0.0204　 289396 rpc.statd

在上面兩個例子中，進程列表中顯示了 CPU 和內存使用率，以便您能夠清楚地了解系統中的負載情況。‘s’和‘stat’列（分別對應于 SVR4 和 BSD）顯示了進程的當前狀態。對于大量的運行的進程，狀態‘R’表示該進程當前正在運行。

通過使用狀態、CPU 和內存百分比的組合，您應該可以確定是否存在失控的 和大量消耗系統資源的進程。

使用 iostat

iostat 工具提供了關于終端、磁盤活動和 CPU 利用率的信息。您可以指定單個數值參數來設置報告的時間間隔，并指定另一個數值參數來設置報告的數量。例如，清單 4 顯示了如何每 5 秒鐘報告相應的統計信息。

清單 4. 每隔 5 秒報告統計信息

$ iostat 5　 ttydad1　sd1　 nfs1　 cputin tout kps tps serv　kps tps serv　kps tps serv　 us sy wt id　 07 440　39　 140　 030　 005 18　0 77　 0　 39　 2　 000　 000　 000　0　0 100　 0　 13　 4　 300　 000　 000　0　0 100　 0　 13　 0　 000　 000　 000　0　0 100

對于不同的系統，缺省情況下顯示的確切的信息也有所不同，清單 4 來自于一個 Solaris 系統。清單 5 中的示例來自于一個 BSD 環境。

清單 5. 一個 BSD 系統中的 iostat

disk1　 disk0　 cpu　KB/t tps　MB/s　 KB/t tps　MB/s　us sy id167.67　 0　0.02　20.70　 5　0.09　 6　3 90　0.00　 0　0.00　 0.00　 0　0.00　15　3 82　0.00　 0　0.00　 0.00　 0　0.00　16　2 82　0.00　 0　0.00　14.33　24　0.33　18　4 79　0.00　 0　0.00　 2.83　 1　0.00　23　4 73

先來看看 CPU 統計信息，這些列分別顯示了用戶 (us)、系統 (sy) 和空閑 (id) 百分比。用戶時間顯示了用于該用戶進程的時間。系統時間則顯示了系統進程耗費的時間（在沒有顯示等待時間時，包括系統等待 I/O 的時間）。空閑時間顯示了 CPU 處于空閑狀態的時間的百分比。

磁盤的輸出顯示了各個物理磁盤（在合適的情況下包括 NFS 加載）的工作情況，通常以每秒處理事務數和每秒傳輸的 MB 或 KB 作為單位。其中的較大數值，尤其是同時具有較高的等待/系統時間，可能表示對于該系統而言，磁盤的速度太慢。您可以嘗試展開您的應用程序，以便它使用不同的磁盤，這樣可能可以改善它的性能。

如果該磁盤同時用作虛擬內存，那么可能是因為缺少內存和過多的交換的問題。

使用 vmstat

您可以使用 vmstat 工具來監視虛擬內存統計信息。與 iostat 一樣，它接受一個數值時間間隔（請參見清單 6）。

清單 6. 使用 vmstat 監視內存統計信息

$ vmstat 5kthr　memorypagedisk faults　cpur b w　 swap　free　re　mf pi po fr de sr dd s1 -- in　 sy　cs us sy id0 0 0 2820888 809552 94 525 121 69 50 0 26 16 0　0 297 1342　272　9　4 870 0 0 2824752 778872 2　 7　0　0　0　0　0　0　0　0 229　 34　109　0　1 990 0 0 2824752 778872 0　 0　0　0　0　0　0　2　0　0 233　 28　116　0　0 1000 0 0 2824752 778872 0　 0　0　0　0　0　0　0　0　0 228　 26　110　0　0 1000 0 0 2824752 778872 0　 0　0　0　0　0　0　0　0　0 229　 28　111　0　0 100

vmstat 工具輸出線程/進程信息、內存/交換區使用率、換進/換出頁面、磁盤 I/O、頁面錯誤和 CPU 統計信息。

CPU/線程塊顯示了運行隊列 (r) 中的進程/線程、等待 I/O 資源的阻塞進程 (b) 和那些被交換的進程。阻塞進程列中較高的值表示磁盤的速度較慢。交換列中較高的數值表示存在許多進程使用了太多的內存，需要對它們進行換入和換出。交換是一項開銷非常高的處理，并且將明顯地降低系統的性能。

內存列顯示了當前可用的交換區大小和空閑列表的大小（如果對 RAM 提出請求，可以被交換的頁面的數目）。較低的交換值表示即將耗盡交換空間，這并不一定表示存在問題，只要您擁有足夠的 RAM 來運行相應的應用程序。較低的空閑列表值可能表示使用了大量的活動 RAM，如果您向該系統中添加更多的進程，那么可能引起交換空間的使用。

頁面列顯示了從磁盤交換進來的和交換到磁盤的內存頁面。鍵值列是 pi/po（換進/換出的頁面），這表示了對多少頁面進行了交換。較高的分頁表示缺少 RAM，較高的掃描速率（sr 列）顯示了潛在的內存瓶頸。

使用 top

top 工具可以提供一種有效的方法來監視活動中的系統和活動的進程、負載以及內存統計信息。有許多不同類型的 top，在缺省情況下，某些系統中安裝了其中的一部分，而這些 top 是最新的開放源碼版本的工具。它所提供的相關信息更像是 uptime、交換空間和 ps 工具的組合。例如，下面的輸出來自于 Solaris 系統中運行的 V3.5.1 版本的 top 工具（請參見清單 7）。

清單 7. 使用 top

last pid:　9385;　load averages:　7.14,　2.98,　1.2161 processes:　55 sleeping, 4 running, 1 zombIE, 1 on cpuCPU states:　0.0% idle, 93.8% user,　6.2% kernel,　0.0% iowait,　0.0% swapMemory: 1024M real, 712M free, 125M swap in use, 2705M swap free　 PID USERNAME LWP PRI NICE　SIZE　 RES STATETIMECPU COMMAND　9313 root　 1　220　 35M　 34M run　0:03　8.87% cc1　9349 root　 1　220　 21M　 20M run　0:01　5.47% cc1　9385 root　 1　390 4320K 3904K run　0:00　0.38% as　9384 root　 1　290 3888K 3424K run　0:00　0.30% as　9145 root　 1　590 3736K 2144K cpu　0:00　0.11% top　9180 root　 1　590 1808K 1472K sleep0:00　0.10% make　 486 root　 1　590　 46M 9536K sleep0:00　0.03% Xsun　 548 root　 1　590　 10M 6360K sleep0:00　0.03% dtgreet　 553 mc 1　490 8288K 1472K sleep0:01　0.02% sshd　9345 root　 1　490 1328K　928K sleep0:00　0.01% gcc　9348 root　 1　590 1328K　928K sleep0:00　0.01% gcc　9325 root　 1　490 1328K　928K sleep0:00　0.01% gcc　 599 mc 1　590 8288K 1488K sleep0:00　0.00% sshd　9312 root　 1　590 1328K　928K sleep0:00　0.00% gcc 9 root　16　590 9464K 2016K sleep0:06　0.00%svc.configd

top 工具顯示了各個進程的 CPU 使用情況，例如，在前面的示例中，可以看到正在編譯大量的文件以及它們使用 CPU 的比例。

您還應該注意進程的狀態：較高的運行進程的數目可能表示系統過于繁忙（將運行進程與 CPU 狀態和系統的平均負載進行比較）。Top 本身可能耗費大量的 CPU，所以最好是以較大的更新時間間隔來運行它，以避免監視工作對系統性能帶來損害。您可以使用

-s

或

-d

命令行選項（根據您使用的平臺來決定）以秒為單位來指定更新的時間間隔。

使用 SAR

有些時候，您需要在系統出現問題后對其狀態進行監視，但是卻又無法實時監視服務器的狀態，在這種情況下，您可以使用 SAR（系統活動報告程序）工具。它以指定的時間間隔將相關信息記錄到一個全局文件中，然后可以在事后對該文件進行處理以顯示計算機的相關信息，該工具正是以這種方式為您提供幫助。

因為記錄信息的進程持續運行于后臺，所以它可以用來詳細地描述系統在一段時間內的性能，并且可以幫助您確定問題的原因。通常以天、月或您指定的時間間隔為單位來記錄相應的信息。日志保存到 /var/log/sa/saDD 或 /usr/adm/sa/saDD，其中 DD 表示一個月中的第幾天。啟用 SAR 工具與具體的系統有關，并且通常您需要建立一個 cron 任務來自動地運行數據收集腳本 (sa1)。另一個腳本 sa2 可以創建每天的報告，以便您對其進行研究。例如，下面的 crontab 顯示了 Solaris 系統中缺省記錄的系統性能統計信息：

0 * * * 0-6 /usr/lib/sa/sa120,40 8-17 * * 1-5 /usr/lib/sa/sa15 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

在收集到了這些信息之后，可以使用

sar

命令來提取相應的數據。系統所記錄下來的信息量可能非常大，并且可以從該數據中選擇和提取的詳細信息也非常大。然而，通過使用 SAR 的

-A

命令行參數，您可以了解到數據的數量和質量，該選項報告了當前記錄的所有信息。

清單 8. 使用帶 -A 參數的 sar 命令生成的輸出

11:49:38%usr%sys%wio　 %idle13:20:00　 1　 1　 0　9913:40:01　19　 5　 0　7614:00:00　 0　 0　 0 10014:20:00　 0　 0　 0 10014:40:01　 0　 0　 0 10015:00:00　 0　 0　 0 10015:20:00　 0　 0　 0 100Average3　 1　 0　9611:49:38　 device%busy　 avque　 r+w/s　blks/s　avwait　avserv...Averagedad1　1 0.3　 5 36547.3 4.5　 dad1,a0 0.0　 0　 415.4 8.6　 dad1,b0 0.0　 0　 0 0.013.8　 dad1,c0 0.0　 0　 0 0.0 0.0　 dad1,d1 0.2　 3 14353.0 3.9　 dad1,e0 0.0　 0　39　 117.3 5.9　 dad1,h0 0.0　 1 17829.0 4.6　 nfs1　0 0.0　 0　 0 0.0 0.0　 nfs2　0 0.0　 0　31 0.514.5　 sd1　 0 0.0　 0　 0 0.0 3.311:49:38 runq-sz %runocc swpq-sz %swpocc13:20:00 2.0　 2 0.0　 013:40:01 5.3　15 0.0　 014:00:00 0.0　 0 0.0　 014:20:00 0.0　 0 0.0　 014:40:01 1.5　 0 0.0　 015:00:00 0.0　 0 0.0　 015:20:00 0.0　 0 0.0　 0Average　5.0　 2 0.0　 011:49:38 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s13:20:00　 0　11　97　 0　 1　89　 0　 013:40:01　 0 803 100　 4 381　99　 0　 014:00:00　 0　 0 100　 0　 0　39　 0　 014:20:00　 0　 0 100　 0　 0　56　 0　 014:40:01　 0　 0 100　 0　 0　61　 0　 015:00:00　 0　 0 100　 0　 0　48　 0　 015:20:00　 0　 0 100　 0　 0　32　 0　 0Average0 120 100　 1　56　99　 0　 011:49:38 swpin/s bswin/s swpot/s bswot/s pswch/s13:20:000.00 0.00.00 0.0 30513:40:010.00 0.00.00 0.0 22314:00:000.00 0.00.00 0.0 11114:20:000.00 0.00.00 0.0 11214:40:010.00 0.00.00 0.0 11215:00:000.00 0.00.00 0.0 11415:20:000.00 0.00.00 0.0 114Average 0.00 0.00.00 0.0 15211:49:38 scall/s sread/s swrit/s　fork/s　exec/s rchar/s wchar/s13:20:00 526　39　260.640.59　 38118　 2577913:40:012288 803 3209.316.53　773352 155893414:00:00　22　 2　 20.010.01 342 18614:20:00　20　 2　 20.000.00 150 12814:40:01　20　 2　 20.010.00 153 12815:00:00　26　 3　 30.010.02 326 16715:20:00　29　 3　 30.020.03 641 272Average　416 125　521.461.04　118615　23279111:49:38　iget/s namei/s dirbk/s13:20:00　 2　31　 313:40:01　29 385　2514:00:00　 0　 1　 014:20:00　 0　 0　 014:40:01　 0　 0　 015:00:00　 0　 1　 015:20:00　 0　 2　 0Average5　61　 411:49:38 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s13:20:00　 0　 0　39　 0　 0　 013:40:01　 1　 0 397　 0　 0　 014:00:00　 0　 0　 9　 0　 0　 014:20:00　 0　 0　 0　 0　 0　 014:40:01　 0　 0　 0　 0　 0　 015:00:00　 0　 0　16　 0　 0　 015:20:00　 0　 0　38　 0　 0　 0Average0　 0　72　 0　 0　 011:49:38　proc-szov　inod-szov　file-szov　 lock-sz13:20:00　 53/161540 1732/696610　358/358 00/0　13:40:01　 54/161540 15118/696610　358/358 00/0　14:00:00　 57/161540 15120/696610　359/359 00/0　14:20:00　 57/161540 15120/696610　359/359 00/0　14:40:01　 57/161540 15120/696610　359/359 00/0　15:00:00　 57/161540 15121/696610　359/359 00/0　15:20:00　 57/161540 15127/696610　359/359 00/0　11:49:38　 msg/s　sema/s13:20:000.000.0013:40:010.000.0014:00:000.000.0014:20:000.000.0014:40:010.000.0015:00:000.000.0015:20:000.000.00Average 0.000.0011:49:38　atch/s　pgin/s ppgin/s　pflt/s　vflt/s slock/s13:20:00　 13.393.675.05　 41.14　 77.090.0013:40:01　188.449.91　 25.61　373.73 1086.420.0014:00:000.300.050.060.611.590.0014:20:000.160.000.000.340.760.0014:40:010.200.000.000.481.010.0015:00:000.720.010.010.982.370.0015:20:000.890.020.021.433.470.00Average29.661.904.38　 60.43　170.400.0011:49:38　pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf13:20:00 0.03 0.06 0.06 0.00 0.0013:40:01 6.4119.1813.84 0.00 0.0014:00:00 0.00 0.00 0.00 0.00 0.0014:20:00 0.00 0.00 0.00 0.00 0.0014:40:01 0.00 0.00 0.00 0.00 0.0015:00:00 0.00 0.00 0.00 0.00 0.0015:20:00 0.00 0.00 0.00 0.00 0.00Average　0.95 2.83 2.05 0.00 0.0011:49:38 freemem freeswap13:20:00　109186　573661513:40:01　 95816　561482214:00:00　 97408　564984914:20:00　 97311　564740914:40:01　 97418　565371115:00:00　 97338　564898215:20:00　 97333　5648993Average98516　565478411:49:38 sml_mem　 alloc　fail　lg_mem　 alloc　fail　ovsz_alloc　fail13:20:00 4178176 3572465 0 38477824 32137880 014663680 013:40:01 16572672 10204085 0 99106816 80782488 015310848014:00:00 16589056 10261693 0 99106816 80797968 015343616　　014:20:00 16589056 10259613 0 99106816 80736600 015343616014:40:01 16589056 10260061 0 99106816 80820088 015343616015:00:00 16589056 10267477 0 99106816 80902432 015343616015:20:00 16589056 10274757 0 99106816 80864920 015343616　　 0Average　14813733 9300022 0 90445528 73863192 015241801　　0

在可能的情況下，對上面的輸出進行了剪裁，以限制所顯示的數據量（比如，并沒有顯示所有磁盤的統計信息）。有關 SAR 的更詳細的信息，請查看參考資料部分和您的系統中的 manual 頁面。

結束語

盡管在運行遲緩的 Unix 系統和您能夠提取的統計信息之間可能并不存在直接的關聯，但在發現系統運行遲緩的時候，第一件事就應該是收集盡可能多的信息。究竟是應該主動地（通過 ps、uptime 和其他工具）還是被動地（通過 SAR 或 top）來完成這項工作，這取決于實際情況。有了這些信息，您應該可以判斷 UNIX 系統之所以運行遲緩，到底是因為負載過重（CPU 超負荷使用）、物理內存太少（大量的交換工作），還是存在失控進程（單個進程占用大量的 CPU 時間）的問題。