当遇到一个系统性能问题时，如何利用登录的前60秒对系统的性能情况做一个快速浏览和分析，主要包括如下10个工具，这是一个非常有用且有效的命工具列表。本文将详细介绍这些命令及其扩展选项的意义，及其在实践中的作用。并利用一个实际出现问题的例子，来验证这些套路是不是可行，下面工具的屏幕输出结果都来自这个出现题的系统。

# 系统负载概览uptime

# 系统日志dmesg | tail

# CPUvmstat 1mpstat -P ALL 1pidstat 1

# Diskiostat -xz 1

# 内存free -m

# 网络sar -n DEV 1sar -n TCP,ETCP 1

# 系统概览top

上面的工具都基于内核提供给用户态的统计，并以计数器形式展示，是快速排查时的利器。对于应用和系统的进一步跟踪(tracing)，则需要利用strace和systemtap，不在本文的范畴。

注意：

• 如上的分类只是基于工具默认选项的分类，比如pidstat，默认展示进程的CPU统计，但是利用-d参数可以展示进程的I/O统计。又比如vmstat，虽然名称是查看虚拟内存的工具，但默认展示了负载，内存，I/O，系统，CPU等多方面的信息。
• 部分工具需要安装sysstat包。

1. uptime# uptime 15:38:10 up 43 days, 3:54, 1 user, load average: 1.13, 0.41, 0.18

uptime是快速查看load average的方法，在Linux中load average包括处于runnable和uninterruptable状态的进程总数，runnable状态的进程包括在CPU上运行的进程和已经ready to run在等待CPU时间的进程；uninterruptable状态的进程是在等待一些I/O访问，比如等待disk的返回。Load average没有根据系统的CPU数量做格式化，所以load average 1表示单CPU系统在对应时间段内(1分钟, 5分钟, 15分钟)一直负载饱和，而在4 CPU的系统中，load average 1表示有75%的时间在idle。

Load average体现了一个high level的负载概览，但是可能需要和别的工具一起来使用以了解更多信息，比如处于runable和uninterruptable的实时进程数量分别是多少，可以用下面将介绍到的vmstat来查看。1分钟，5分钟，15分钟的负载平均值同时能体现系统负载的变化情况。例如，如果你要检查一个问题服务器，当你看到1分钟的平均负载值已经远小于15分钟的平均负载值，则意味这也许你登录晚了点，错过了现场。用top或者w命令，也可以看到load average信息。

上面示例中最近1分钟内的负载比15分钟内的负载高了不少 (因为是个测试的例子，1.13可以看作明显大于0.18，但是在生产系统上这不能说明什么)。

2. dmesg | tail

# dmesg | tail device eth0 left promiscuous mode device eth0 entered promiscuous mode device eth0 left promiscuous mode device eth0 entered promiscuous mode device eth0 left promiscuous mode device eth0 entered promiscuous mode device eth0 left promiscuous mode bash (8290): drop_caches: 1 bash (8290): drop_caches: 2 bash (8290): drop_caches: 1

dmesg用于查看内核缓冲区存放的系统信息。另外查看/var/log/messages也可能查看出服务器系统方面的某些问题。

上面示例中的dmesg没有特别的值得注意的错误。

3. vmstat 1

vmstat简介：

• vmstat是virtual memory stat的简写，能够打印processes, memory, paging, block IO, traps, disks and cpu的相关信息。
• vmstat的格式：vmstat ]。在输入中的1是延迟。第一行打印的是机器启动到现在的平均值，后面打印的则是根据deley间隔的取样结果，也就是实时的结果。

结果中列的含义：

Procs(进程)

r: The number of runnable processes (running or waiting for run time).b: The number of processes in uninterruptible sleep.

注释：r表示在CPU上运行的进程和ready等待运行的进程总数，相比load average, 这个值更能判断CPU是否饱和(saturation)，因为它没有包括I/O。如果r的值大于CPU数目，即达到饱和。

Memory

swpd: the amount of virtual memory used.free: the amount of idle memory.buff: the amount of memory used as buffers.cache: the amount of memory used as cache.

Swap

si: Amount of memory swapped in from disk (/s).so: Amount of memory swapped to disk (/s).

注释：swap-in和swap-out的内存。如果是非零，说明主存中的内存耗尽。

IO

bi: Blocks received from a block device (blocks/s).bo: Blocks sent to a block device (blocks/s).

System (中断和进程上下文切换)

in: The number of interrupts per second, including the clock.cs: The number of context switches per second.

CPU

These are percentages of total CPU time.us: Time spent running non-kernel code. (user time, including nice time)sy: Time spent running kernel code. (system time)id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

根据user+system时间，可以判断CPUs是否繁忙。如果wait I/O一直维持一定程度，说明disk有瓶颈，这时CPUs是”idle”的，因为任务都被block在等待disk I/O中。wait I/O可以被视为另一种形式的CPU idle，并且说明idle的原因就是在等待disk I/O的完成。

处理I/O需要花费system time，在将I/O提交到disk driver之前可能要经过remap, split和merge等操作，并被I/O scheduler调度到request queue。如果处理I/O时平均system time比较高，超过20%，则要进一步分析下，是不是内核处理I/O时的效率有问题。

如果用户空间的CPU使用率接近100%，不一定就代表有问题，可以结合r列的进程总数量看下CPU的饱和程度。

上面示例可以看到在CPU方面有一个明显的问题。user+system的CPU一直维持在50%左右，并且system消耗了大部分的CPU。

4. mpstat -P ALL 1

mpstat可以打印按照CPU的分解，可以用来检查不不均衡的情况。

上面示例结果可以印证vmstat中观察到的结论，并且可以看到服务器有2个CPU，其中CPU 1的使用率一直维持在100%，而CPU 0并没有什么负载。CPU 1的消耗主要在内核空间，而非用户空间。

5. pidstat 1

默认pidstat类似于top按照进程的打印方式，不过是以滚动打印的方式，和top的清屏方式不同。利用-p可以打出指定进程的信息，-p ALL可以打出所有进程的信息。如果没有指定任何进程默认相当于-p ALL，但是只打印活动进程的信息(统计非0的数据)。

pidstat不只可以打印进程的CPU信息，还可以打印内存，I/O等方面的信息，如下是比较有用的信息：

• pidstat -d 1：看哪些进程有读写。
• pidstat -r 1：看进程的page fault和内存使用。没有发生page fault的进程默认不会被打印出来，可以指定-p和进程号来打印查看内存。
• pidstat -t： 利用-t查看线程信息，可以快速查看线程和期相关线程的关系。
• pidstat -w：利用-w查看进程的context switch情况。输出：
  • cswch/s: 每秒发生的voluntary context switch数目 (voluntary cs：当进程被block在获取不到的资源时，主动发生的context switch)
  • nvcswch/s: 每秒发生的non voluntary context switch数目 (non vloluntary cs：进程执行一段时间用完了CPU分配的time slice，被强制从CPU上调度下来，这时发生的context switch)

上面示例中可以明确得看到是nc这个进程在消耗CPU 1 100%的CPU。因为测试系统里消耗CPU的进程比较少，所以一目了然，在生产系统中pidstat应该能输出更多正在消耗CPU的进程情况。

6. iostat -zx 1

了解块设备(block device, 这里是disk)负载和性能的工具。主要看如下指标：

• r/s, w/s, rkB/s, wkB/s：每秒完成的读请求次数(read requests, after merges)，每秒完成的写请求次数(write requests completed, after merges)，每秒读取的千字节数，每秒写入的千字节数。这些指标可以看出disk的负载情况。一个性能问题可能仅仅是因为disk的负载过大。
• await：每个I/O平均所需的时间，单位为毫秒。await不仅包括硬盘设备处理I/O的时间，还包括了在kernel队列中等待的时间。要精确地知道块设备service一个I/O请求地时间，可供iostat读取地内核统计并没有体现，需要用如blktrace这样地跟踪工具来跟踪。对于blktrace来说，D2C的时间间隔代表硬件块设备地service time，Q2C代表整个I/O请求所消耗的时间，即iostat的await。
• avgqu-sz：队列里的平均I/O请求数量 (更恰当的理解应该是平均未完成的I/O请求数量）。如果该值大于1，则有饱和的趋势 (当然设备可以并发地处理请求，特别是一个front对多个backend disk的虚拟设备)。
• %util：设备在处理I/O的时间占总时间的百分比。表示该设备有I/O（即非空闲）的时间比率，不考虑I/O有多少，只考虑有没有。通常该指标达到60%即可能引起性能问题 (可以根据await指标进一步求证)。如果指标接近100%，通常就说明出现了饱和。

如果存储设备是一个对应多个后端磁盘的逻辑磁盘，那么100%使用率可能仅仅表示一些I/O在处理时间占比达到100%，其他后端磁盘不一定也到达了饱和。请注意磁盘I/O的性能问题并不一定会造成应用的问题，很多技术都是使用异步I/O操作，所以应用不一定会被block或者直接受到延迟的影响。

7. free -m# free -m total used free shared buff/cache available Mem: 7822 129 214 0 7478 7371 Swap: 0 0 0

查看内存使用情况。倒数第二列：

• buffers: buffer cache，用于block device I/O。
• cached: page cache, 用于文件系统。

Linux用free memory来做cache, 当应用需要时，这些cache可以被回收。比如kswapd内核进程做页面回收时可能回收cache；另外手动写/proc/sys/vm/drop_caches也会导致cache回收。

上面示例中free的内存只有129M，大部分memory被cache占用。但是系统并没有问题。

8. sar -n DEV 1

输出指标的含义如下：

• rxpck/s: Total number of packets received per second.
• txpck/s: Total number of packets transmitted per second.
• rxkB/s: Total number of kilobytes received per second.
• txkB/s: Total number of kilobytes transmitted per second.
• rxcmp/s: Number of compressed packets received per second (for cslip etc.).
• txcmp/s: Number of compressed packets transmitted per second.
• rxmcst/s: Number of multicast packets received per second.
• %ifutil: Utilization percentage of the network interface. For half-duplex interfaces, utilization is calculated using the sum of rxkB/s and txkB/s as a percentage of the interface speed.
• For full-duplex, this is the greater of rxkB/S or txkB/s.

这个工具可以查看网络接口的吞吐量，特别是上面蓝色高亮的rxkB/s和txkB/s，这是网络负载，也可以看是否达到了limit。

9. sar -n TCP,ETCP 1

输出指标的含义如下：

• active/s: The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state per second .
• passive/s: The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state per second .
• iseg/s: The total number of segments received per second, including those received in error . This count includes segments received on currently established connections.
• oseg/s: The total number of segments sent per second, including those on current connections but excluding those containing only retransmitted octets .
• atmptf/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times per second TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state .
• estres/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state .
• retrans/s: The total number of segments retransmitted per second – that is, the number of TCP segments transmitted containing one or more previously transmitted octets .
• isegerr/s: The total number of segments received in error (e.g., bad TCP checksums) per second .
• orsts/s: The number of TCP segments sent per second containing the RST flag .

上述蓝色高亮的3个指标：active/s, passive/s和retrans/s是比较有代表性的指标。

• active/s和passive/s分别是本地发起的每秒新建TCP连接数和远程发起的TCP新建连接数。这两个指标可以粗略地判断服务器的负载。可以用active衡量出站发向，用passive衡量入站方向，但也不是完全准确(比如，考虑localhost到localhost的连接)。
• retrans是网络或者服务器发生问题的象征。有可能问题是网络不稳定，比如Internet网络问题，或者服务器过载丢包。

10. top

# top Tasks: 79 total, 2 running, 77 sleeping, 0 stopped, 0 zombie %Cpu(s): 6.0 us, 44.1 sy, 0.0 ni, 49.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 8010456 total, 7326348 free, 132296 used, 551812 buff/cache KiB Swap: 0 total, 0 free, 0 used. 7625940 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4617 root 20 0 44064 2076 1544 R 100.0 0.0 16:27.23 nc 13634 nginx 20 0 121192 3864 1208 S 0.3 0.0 17:59.85 nginx 1 root 20 0 125372 3740 2428 S 0.0 0.0 6:11.53 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.60 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:17.92 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 7 root rt 0 0 0 0 S 0.0 0.0 0:03.21 migration/0 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root 20 0 0 0 0 S 0.0 0.0 31:47.62 rcu_sched 10 root rt 0 0 0 0 S 0.0 0.0 0:10.00 watchdog/0

top是一个常用的命令，包括了多方面的指标。缺点是没有滚动输出(rolling output)，不可复现问题发生时不容易保留信息。对于信息保留，用vmstat或者pidstat等能够提供滚动输出的工具会更好。

示例的问题？

在上面利用工具排查的过程中，我们可以在非常短的时间内快速得到如下结论：

• 2个CPU，nc这个进程消耗了CPU 1 100%的时间，并且时间消耗在system内核态。其他进程基本没有在消耗CPU。
• 内存free比较少，大部分在cache中 (并不是问题)。
• Disk I/O非常低，平均读写请求小于1个。
• 收到报文在个位数KB/s级别，每秒有15个被动建立的TCP连接，没有明显异常。

整个排查过程把系统的问题定位到了进程级别，并且能排除一些可能性 (Disk I/O和内存)。接下来就是进一步到进程级别的排查，不属于本文的覆盖范围，有时间再进一步演示。

1 cpu性能评估

Cpu是影响Linux性能的主要因素之一，下面先介绍几个查看CPU性能的命令。

1.1 vmstat命令

该命令可以显示关于系统各种资源之间相关性能的简要信息，这里我们主要用它来看CPU的一个负载情况。

下面是vmstat命令在某个系统的输出结果：

# vmstat 2 3

procs ———–memory———- —swap– —–io—- –system– —–cpu——

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 0 0 162240 8304 67032 0 0 13 21 1007 23 0 1 98 0 0

0 0 0 162240 8304 67032 0 0 1 0 1010 20 0 1 100 0 0

0 0 0 162240 8304 67032 0 0 1 1 1009 18 0 1 99 0 0

对上面每项的输出解释如下：

l procs

Ø r列表示运行和等待cpu时间片的进程数，这个值如果长期大于系统CPU的个数，说明CPU不足，需要增加CPU。

Ø b列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。

l memory

Ø swpd列表示切换到内存交换区的内存数量（以k为单位）。如果swpd的值不为0，或者比较大，只要si、so的值长期为0，这种情况下一般不用担心，不会影响系统性能。

Ø free列表示当前空闲的物理内存数量（以k为单位）

Ø buff列表示buffers cache的内存数量，一般对块设备的读写才需要缓冲。

Ø cache列表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。

l swap

Ø si列表示由磁盘调入内存，也就是内存进入内存交换区的数量。

Ø so列表示由内存调入磁盘，也就是内存交换区进入内存的数量。

一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足。需要增加系统内存。

l IO项显示磁盘读写状况

Ø Bi列表示从块设备读入数据的总量（即读磁盘）（每秒kb）。

Ø Bo列表示写入到块设备的数据总量（即写磁盘）（每秒kb）

这里我们设置的bi+bo参考值为1000，如果超过1000，而且wa值较大，则表示系统磁盘IO有问题，应该考虑提高磁盘的读写性能。

l system 显示采集间隔内发生的中断数

Ø in列表示在某一时间间隔中观测到的每秒设备中断数。

Ø cs列表示每秒产生的上下文切换次数。

上面这2个值越大，会看到由内核消耗的CPU时间会越多。

l CPU项显示了CPU的使用状态，此列是我们关注的重点。

Ø us列显示了用户进程消耗的CPU 时间百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，就需要考虑优化程序或算法。

Ø sy列显示了内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源很多。

根据经验，us+sy的参考值为80%，如果us+sy大于 80%说明可能存在CPU资源不足。

Ø id 列显示了CPU处在空闲状态的时间百分比。

Ø wa列显示了IO等待所占用的CPU时间百分比。wa值越高，说明IO等待越严重，根据经验，wa的参考值为20%，如果wa超过20%，说明IO等待严重，引起IO等待的原因可能是磁盘大量随机读写造成的，也可能是磁盘或者磁盘控制器的带宽瓶颈造成的（主要是块操作）。

综上所述，在对CPU的评估中，需要重点注意的是procs项r列的值和CPU项中us、sy和id列的值。

1.2 sar命令

检查CPU性能的第二个工具是sar，sar功能很强大，可以对系统的每个方面进行单独的统计，但是使用sar命令会增加系统开销，不过这些开销是可以评估的，对系统的统计结果不会有很大影响。

下面是sar命令对某个系统的CPU统计输出：

# sar -u 3 5

Linux 2.6.9-42.ELsmp (webserver) 11/28/2008 _i686_ (8 CPU)

11:41:24 AM CPU %user %nice %system %iowait %steal %idle

11:41:27 AM all 0.88 0.00 0.29 0.00 0.00 98.83

11:41:30 AM all 0.13 0.00 0.17 0.21 0.00 99.50

11:41:33 AM all 0.04 0.00 0.04 0.00 0.00 99. 45

对上面每项的输出解释如下：

l %user列显示了用户进程消耗的CPU 时间百分比。

l %nice列显示了运行正常进程所消耗的CPU 时间百分比。

l %system列显示了系统进程消耗的CPU时间百分比。

l %iowait列显示了IO等待所占用的CPU时间百分比

l %steal列显示了在内存相对紧张的环境下pagein强制对不同的页面进行的steal操作 。

l %idle列显示了CPU处在空闲状态的时间百分比。

1.3 iostat命令

iostat指令主要用于统计磁盘IO状态，但是也能查看CPU的使用信息，它的局限性是只能显示系统所有CPU的平均信息，看下面的一个输出：

# iostat -c

Linux 2.6.9-42.ELsmp (webserver) 11/29/2008 _i686_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

2.52 0.00 0.30 0.24 0.00 96.96

在这里，我们使用了“-c”参数，只显示系统CPU的统计信息，输出中每项代表的含义与sar命令的输出项完全相同，不再详述。

1.4 uptime命令

uptime是监控系统性能最常用的一个命令，主要用来统计系统当前的运行状况，输出的信息依次为：系统现在的时间、系统从上次开机到现在运行了多长时间、系统目前有多少登陆用户、系统在一分钟内、五分钟内、十五分钟内的平均负载。看下面的一个输出：

# uptime

18:52:11 up 27 days, 19:44, 2 users, load average: 0.12, 0.08, 0.08

这里需要注意的是load average这个输出值，这三个值的大小一般不能大于系统CPU的个数，例如，本输出中系统有8个CPU,如果load average的三个值长期大于8时，说明CPU很繁忙，负载很高，可能会影响系统性能，但是偶尔大于8时，倒不用担心，一般不会影响系统性能。相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲的时间片，比如本例中的输出，CPU是非常空闲的。

1.5 本节小结

上面介绍了检查CPU使用状况的四个命令，通过这些命令需要了解的是：系统CPU是否出现性能瓶颈，也就是说，以上这些命令只能查看CPU是否繁忙，负载是否过大，但是无法知道CPU为何负载过大，因而，判断系统CPU出现问题后，要结合top、ps等命令进一步检查是由那些进程导致CPU负载过大的。引起CPU资源紧缺的原因可能是应用程序不合理造成的，也可能是硬件资源匮乏引起的，所以，要具体问题具体分析，或者优化应用程序，或者增加系统CPU资源。

2 内存性能评估

内存的管理和优化是系统性能优化的一个重要部分，内存资源的充足与否直接影响应用系统的使用性能，在进行内存优化之前，一定要熟悉linux的内存管理机制，这一点我们在前面的章节已经有深入讲述，本节的重点是如何通过系统命令监控linux系统的内存使用状况。

2.1 free 命令

free是监控linux内存使用状况最常用的指令，看下面的一个输出：

# free -m

total used free shared buffers cached

Mem: 8111 7185 925 0 243 6299

-/+ buffers/cache: 643 7468

Swap: 8189 0 8189

“free –m”表示以M为单位查看内存使用情况，在这个输出中，我们重点关注的应该是free列与cached列的输出值，由输出可知，此系统共8G内存，系统空闲内存还有925M，其中，Buffer Cache占用了243M，Page Cache占用了6299M，由此可知系统缓存了很多的文件和目录，而对于应用程序来说，可以使用的内存还有7468M，当然这个7468M包含了Buffer Cache和Page Cache的值。在swap项可以看出，交换分区还未使用。所以从应用的角度来说，此系统内存资源还非常充足。

一般有这样一个经验公式：应用程序可用内存/系统物理内存>70%时，表示系统内存资源非常充足，不影响系统性能，应用程序可用内存/系统物理内存<20%时，表示系统内存资源紧缺，需要增加系统内存，20%< 应用程序可用内存/系统物理内存<70%时，表示系统内存资源基本能满足应用需求，暂时不影响系统性能。

2.2 通过watch与free相结合动态监控内存状况

watch是一个非常有用的命令，几乎每个linux发行版都带有这个工具，通过watch，可以动态的监控命令的运行结果，省去手动执行的麻烦。

可以在watch后面跟上需要运行的命令，watch就会自动重复去运行这个命令，默认是2秒钟执行一次，并把执行的结果更新在屏幕上。例如：

# watch -n 3 -d free

Every 3.0s: free Sun Nov 30 16:23:20 2008

total used free shared buffers cached

Mem: 8306544 7349548 956996 0 203296 6500024

-/+ buffers/cache: 646228 7660316

Swap: 8385888 160 8385728

其中，“-n”指定重复执行的时间，“-d”表示高亮显示变动。

2.3 vmstat命令监控内存

vmstat命令在监控系统内存方面功能强大，请看下面的一个输出：

procs ———–memory———- —swap– —–io—- –system– —-cpu—-

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 906440 22796 155616 1325496 340 180 2 4 1 4 80 0 10 10

0 0 906440 42796 155616 1325496 320 289 0 54 1095 287 70 15 0 15

0 0 906440 42884 155624 1325748 236 387 2 102 1064 276 78 2 5 15

对于内存的监控，在vmstat中重点关注的是swpd、si和so行，从这个输出可以看出，此系统内存资源紧缺，swpd占用了900M左右内存，si和so占用很大，而由于系统内存的紧缺，导致出现15%左右的系统等待，此时增加系统的内存是必须要做的。

2.4 sar -r命令组合

sar命令也可以监控linux的内存使用状况，可以通过“sar –r”组合查看系统内存和交换空间的使用率。请看下面的一个输出：

# sar -r 2 3

Linux 2.6.9-42.ELsmp (webserver) 11/30/2008 _i686_ (8 CPU)

09:57:33 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit

09:57:35 PM 897988 7408556 89.19 249428 6496532 786556 4.71

09:57:37 PM 898564 7407980 89.18 249428 6496532 784276 4.70

09:57:39 PM 899196 7407348 89.17 249440 6496520 782132 4.69

Average: 898583 7407961 89.18 249432 6496528 784321 4.70

其中：

Kbmemfree表示空闲物理内存大小，kbmemused表示已使用的物理内存空间大小，%memused表示已使用内存占总内存大小的百分比，kbbuffers和kbcached分别表示Buffer Cache和Page Cache的大小，kbcommit和%commit分别表示应用程序当前使用的内存大小和使用百分比。

可以看出sar的输出其实与free的输出完全对应，不过sar更加人性化，不但给出了内存使用量，还给出了内存使用的百分比以及统计的平均值。从%commit项可知，此系统目前内存资源充足。

2.5 本节小结

上面介绍了内存监控常用的几个指令以及一些经验规则，其实现在的系统在内存方面出现的瓶颈已经很少，因为内存价格很低，充足的内存已经完全能满足应用程序和系统本身的需要，如果系统在内存方面出现瓶颈，很大的可能是应用程序本身的问题造成的。

Linux服务器性能快速分析通常使用top命令，通过一个命令，就能实时查看服务器的负载、cpu、内存使用率，类似windows 系统的任务管理器。那如何使用top命令查看和分析各项性能指标呢？

只需登录到服务器后，在命令行模式下输入top即可，是不是很容易呢。如下图所示：

前5行是服务器性能指标概览。以上图为例来详细说明各项指标代表的含义，以便于理解。

第1行是任务队列信息：

当前时间 22:52:45

系统运行时间 823 days

当前登录用户数 2 users

系统负载 load average: 0.00, 0.03, 0.06 。 三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。如果15分钟对应的数值在升高，但1分钟对应数值降低，则代表服务器负载呈下降趋势，反之代表负载在升高。

第2行为进程信息：

进程总数 121

正在运行的进程数 1

睡眠的进程数 119

停止的进程数 1

僵尸进程数 0

第3行为cpu信息：

用户空间占用CPU百分比 (us)0.3%

内核空间占用CPU百分比(sy)0.2%

用户进程空间内改变过优先级的进程占用CPU百分比(ni)10%

空闲CPU百分比(id)89.2%

等待输入输出的CPU时间百分比(wa) 0.0%

硬中断（Hardware IRQ）占用CPU的百分比(hi)0.0%

软中断（Software Interrupts）占用CPU的百分比(si)0.2%

虚拟 CPU 等待实际 CPU 的时间的百分比(st)0.2%

第4、5行为内存信息:

物理内存总量 6291456k

使用的物理内存总量 5760744k

空闲内存总量 530712k

用作内核缓存的内存量 209064k

交换区总量6258680k

使用的交换区总量 3132084k

空闲交换区总量 3126596k

缓冲的交换区总量 437464k

第6行开始是进程信息区，下方显示了各个进程的详细信息。字段含义分别为：

PID 进程id

USER 进程所有者的用户名

PR 优先级

NI nice值。负值表示高优先级，正值表示低优先级

VIRT 进程使用的虚拟内存总量，单位kb

RES 进程使用的、未被换出的物理内存大小

SHR 共享内存大小

S 进程状态（D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程 ）

%CPU 上次更新到现在的CPU时间占用百分比，即cpu使用率

%MEM 进程使用的物理内存百分比 ，即内存使用率

TIME+ 进程使用的CPU时间总计

COMMAND 命令名/命令行

各指标含义已详细说明，指标项很多，但我们工作中判断服务器是否存在性能问题，通常关注以下几项指标：

1.CPU

使用率。在top基本视图中，按键盘数字“1”，可监控每个逻辑CPU的状况。CPU使用率数值越高，代表服务器越繁忙。而进程信息区还会显示各进程当前的cpu使用率，若需查询进程下各线程cpu使用率情况，可使用top －p 进程id -H，配合使用jstack命令还可定位到具体占用cpu过高的功能。

2.内存使用率。若使用的内存过高，空闲内存较低，则需注意。

3.服务器负载，若服务器负载 load average超过cpu核心数的话,则说明系统超负荷运行。如果是单核CPU,负载等于1就是满负荷运转了,如果是四核、甚至更多核心的CPU,负载大于1这说明系统当前负载很小,不需要过多关心。