从步骤 1 开始，首先查看 CPU 使用情况，按照诊断 CPU、内存或磁盘瓶颈的指导进行操作。对于下面的每个步骤，查找一端时间内的趋势，从中收集系统运行性能较差时的数据。另外，只有将这些数据与系统正常运行时收集的数据进行比较时才能进行准确的诊断。
步骤 1
# sar -u [interval] [iterations]
(示例: sar -u 5 30)
%idle 是否很低? 这是 CPU 未在运行任何进程的时间百分比。在一端时间内 %idle 为零可能是 CPU 瓶颈的第一个指示。
不是 -> 系统未发生 CPU 瓶颈。转至步骤 3。
是 -> 系统可能发生了 CPU、内存或 I/O 瓶颈。转至步骤 2。
步骤 2
%usr 是否较高? 很多系统正常情况下花费 80% 的 CPU 时间用于用户， 20% 用于系统。其他系统通常会使用 80% 左右的用户时间。
不是 -> 系统可能遇到 CPU、内存或 I/O 瓶颈。转至步骤 3。
是 -> 系统可能由于用户进程遇到 CPU 瓶颈。转至部分 3，部分 A，调整系统的 CPU 瓶颈。
步骤 3
%wio 的值是否大于 15?
是 -> 以后记住这个值。它可能表示磁盘或磁带瓶颈。转至步骤 4。
不是 -> 转至步骤 4。
步骤 4
# sar -d [interval] [iterations]
用于任何磁盘的 %busy 是否都大于 50? (请记住，50% 指示一个大概的 指南，它可能远远高于您系统的正常值。在某些系统上，甚至 %busy 值为 20 可能就表示发生了磁盘瓶颈，而其他系统正常情况下可能就为 50% busy。)对于同一个磁盘上，avwait 是否大于 avserv?
不是 -> 很可能不是磁盘瓶颈，转至步骤 6。
是 -> 此设备上好像发生了 IO 瓶颈。
转至步骤 5。
步骤 5
系统上存在磁盘瓶颈，发生瓶颈的磁盘上有哪些内容?
原始分区，
文件系统 -> 转至部分 3，部分 B，调整发生磁盘 IO 瓶颈的系统。
Swap -> 可能是由于内存瓶颈导致的。
转至步骤 6。
步骤 6
# vmstat [interval] [iterations]
在很长的一端时间内，po 是否总是大于 0?
对于一个 s800 系统 (free * 4k) 是否小于 2 MB，
(对于 s700 系统 free * 4k 是否小于 1 MB)?
(值 2 MB 和 1 MB 指示大概的指南，真正的 LOTSFREE 值，即系统开始发生 paging 的值是在系统引导时计算的，它是基于系统内存的大小的。)
不是 -> 如果步骤 1 中的 %idle 较低，系统则很可能发生了 CPU 瓶颈。
转至部分 3，部分 A，调整发生了 CPU 瓶颈的系统。
如果 %idle 不是很低，则可能不是 CPU、磁盘 IO或者内存瓶颈。
请转至部分 4，其他瓶颈。
是 -> 系统上存在内存瓶颈，转至部分 3 部分 C，调整发生内存瓶颈的系统。
