最近测试中发现Windows服务器的速度很慢，发现是内存造成瓶颈，现在将Windows内存检测的一些方法总结一下。Windows内存中有三个数据很重要，Pages/sec, Available Bytes和Committed Bytes.

   在测试中内存的缺少会造成频繁的页错误，导致系统不停在磁盘和内存中交换数据，有可能表现出IO瓶颈的现象，实则内存不足。在页错误中，有分为硬件错误和软件错误，硬件错误是指程序需要的数据不在内存中需要从硬盘读取，软件错误是指数据还在内存的缓存中但已不再程序的驻留内存里，需要从内存的其他地方读取。访问硬盘比内存要慢几个数量级，所以当系统出现很多硬件页错误时候，系统就会慢的很多，成为系统产生抖动。

   如何发现硬件页错误呢？通过在性能监视器里监控一下指标：

Memory\Pages/sec， Process(All_process)\Working Set， Memory\Pages Input/sec

Memory\Pages Output/sec

同时可以通过一下计数器看到内存和磁盘之间的频繁交换：

Memory\Page Reads/sec, PhysicalDisk\Disk Reads/sec,

PhysicalDisk\Avg.Disk Read Bytes/sec

其中，Pages/sec是指由于硬件页错误而引起的页交换数量等于Pages Input/sec和Pages Output/sec的总和。Page Faults/sec是页错误的数量包括硬件的和软件的。

因此总结下来，当Pages/sec大于10的时候就表明系统存在抖动（thrashing)，当Available Bytes小于4MB时就说明系统内存不足，Committed Bytes的数值明显大于内存总量的时候，系统就应该增加内存。

有一点值得注意的是，如果某个程序连续的读取内存映像文件（Memory Mapping file）的时候也会造成Pages/sec变的很大，但此时不能认定系统出现抖动，我们还要参考其他数值来确定是否内存出现瓶颈。

    网络是所有子系统中最难监控的了。首先是由于网络是抽象的，更重要的是许多影响网络的因素并不在我们的控制范围之内。这些因素包括，延迟、冲突、阻塞等等。

    大部分的以太网络都是自适应速度的，因为一个网络中可能有不同的网络设备采用不同的速率和工作模式（全双工或半双工）。大部分企业网络都工作在100到1000BaseTX。ethtool命令可以设置网卡的工作速率和模式。

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
                      100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

我们可以看到网卡工作在10Mb/s，模式为半双工，并且打开了自适应开关。我们通过下列命令强制设置网卡工作在100Mb/s全双工模式，并关闭自适应功能。

# ethtool -s eth0 speed 100 duplex full autoneg off

再次运行ethtool显示如下：

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
                      100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
                       100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

用iptraf工具可以清楚的看到每个网卡的工作情况。

# iptraf –d eth0

利用iptraf还可以监听固定TCP端口的流量，如对于Web服务器我们希望监听80端口的流量，对于邮件服务器我们关注25端口的流量。

   

网络中最常见的错误就是冲突，由于网络中目前基本采用交换机环境，因此冲突问题已被消除。但是当网络流量不断增大的时候，就会出现丢包，网卡过载等情况。在网络流量很大的时候我们用sar命令来给出网络中可能的错误:

# sar -n FULL 5 100
Linux 2.6.9-55.ELsmp (sapulpa) 06/23/2007
11:44:32 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
11:44:37 AM lo 6.00 6.00 424.40 424.40 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
11:44:37 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:37 AM sit0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:44:32 AM totsck tcpsck udpsck rawsck ip-frag
11:44:37 AM 297 79 8 0 0

   rxerr/s是接受错误率；txerr/s是发送错误率；coll/s冲突率；rxdrop/s接受帧丢失率；txdrop/s发送帧丢失率；txcarr/s载波错误率；rxfram/s帧排列错误；rxfifo/s接受FIFO错误；txfifo/s发送FIFO错误。从上面输出看出各种错误为零，证明网络工作良好。

   总的来说监视网络性能，我们有遵循一下几点：

1. 检查所有网络接口确保他们都运行在正确的速率；

2. 检查每块网卡的吞吐量确保没有造成过载；

3. 检查流量的类型确保正确的数据流在传送。

接下来我们分析一些具体的情况，在这些情况下I/O会成为系统的瓶颈。我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映除系统的性能情况。

 

情况1：同一时间进行大量的I/O操作

   在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。

# vmstat 1

procs -----memory----- ---swap---io---- --system--cpu----

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

3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57

2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52

2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52

 

    从这个输出我们可以看到CPU有50%的时间都在等待I/O操作，我们还可以看到系统的bi值很大，证明系统有大量的I/O请求将磁盘内容读入内存。

没有很好的工具能看到到底是哪个进程在进行I/O读写。但我们可以通过top命令的输出来猜测

 

# top -d 1

top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40

Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie

Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si

Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers

Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND

3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx

3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx

3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx

3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx

 

    将top的输出通过faults进行排序。我们可以看到vmware产生最多的page faults。也就是说它进行了大量的IO操作。

 

情况2：管道太小

任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000.

RPS=RPM/60=166

1/166=0.0006=6ms 磁盘旋转一周要6毫秒

RD=6ms/2=3ms

磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是：

3ms+3ms+2ms=8ms

IOPS=1000/8=125  这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。

对与系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。

连续I/O常常出现在企业级数据库这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢。我们用iostat来监控，会发现rKB/s,wKB/s会很高。

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00

从输出我们看到w/s=105,wKB/s=53040.所以53040/105=505KB per I/O.

对于随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数：

# iostat -x 1

avg-cpu: %user %nice %sys %idle

2.04 0.00 97.96 0.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

/dev/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00

从输出我们看到w/s=102,wKB/s=2640.所以2640/102=23KB per I/O.

因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值.

IO系统是整个系统中最慢的部分，因为它需要真正的物理操作磁盘的转动和检索。比起内存来要差几个数量级。Linux内核将硬盘IO分页，每一页的大小默认为4K。这时，内存和磁盘的读写以页为单位进行，这些页叫做内存页。用time命令可以检查页的大小：

# /usr/bin/time -v date

<snip>

Page size (bytes): 4096

<snip>

 

主要页错误（Major Page Faults）和次要页错误（Minor Page Faults）：

MPF（Major Page Faults）表示进程需要的数据并不在内存中，需要从磁盘读取。

一旦内存页读入到内存的缓冲区中，程序就在内存中读取或写入数据，叫做MnPF（Minor Page Faults）。MnPF通过重复使用内存页而缩短了内核时间。Time命令可以显示一个进程中MPF和MnPF的数量，在evolution程序第一次启动的时候会有很多MPF：

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 163

Minor (reclaiming a frame) page faults: 5918

<snip>

 

如果再次启动evolution程序，我们就看到MPF消失了，因为此时进程需要的数据已经全部在内存中了：

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 0

Minor (reclaiming a frame) page faults: 5581

<snip>

 

当进程不断的进行IO操作的时候，系统会将这些数据缓存到内存中。所以我们会看到系统的FreeMemory越来越少，而Cache越来越大。如下:

# cat /proc/meminfo

MemTotal: 2075672 kB

MemFree: 52528 kB

Buffers: 24596 kB

Cached: 1766844 kB

有些人为系统的可用内存太少而担心，而事实不是这样，这种情况恰恰证明系统正在高效的利用cache，进而减少MPF，增加MnPF。但从这个输出我们无法断定内存是否为系统瓶颈。

 

前面讲了内存页的定义，接下来我们说说内存页的分类：

1.    Read Pages-这些页通过MPF从磁盘读入，并且是只读的。这些页存在与cache中包括不能修改的静态文件，二进制文件，库文件。内核在需要的时候会将他们读入内存，当内存资源紧张时，内核会释一些放此类的内存页，当程序在此需要的时候，就只能通过MPF重新读入。

2.    Dirty Pages-这些页是内核在内存中修改过的页面。这些页面需要同步回磁盘上。Pdflush负责将他们写回磁盘。当内存不够时，kswapd就会触发pdflush将页面写回磁盘以释放内存。

3.    Anonymous Pages-这些页属于某个进程，但是没有任何磁盘文件与之相关。他们不能和磁盘同步。当内存不够时，kswapd会将他们写入swap分区。

 

应用程序可以用系统调用fsync()和sync()将Dirty Page立即写回磁盘。如果应用程序没有调用此类函数，pdflush进程会定期与磁盘进行同步。

我们来看内存监控的一个例子，用vmstat命令的输出如下：

# vmstat 3
procs          memory            swap     io        system      cpu
r b  swpd   free   buff cache   si so    bi   bo    in   cs   us sy id wa
3 2 809192 261556 79760 886880 416 0    8244  751   426  863  17 3   6 75
0 3 809188 194916 79820 952900 307 0    21745 1005  1189 2590 34 6  12 48
0 3 809188 162212 79840 988920 95  0    12107 0     1801 2633 2  2   3 94
1 3 809268 88756 79924 1061424 260 28   18377 113   1142 1694 3  5   3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9  12 61
2 1 854780 17688 34140 1208980 1   9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31  4384 16524 27808 1490 1634 41 10  7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337  678  932  33 7   3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982  40 12  2 46
5 2 900472 17980 32440 1253884 24  4851 17521 4856  934  1730 48 12 13 26
1 1 904404 17620 32492 1258928 15  1316 7647  15804 919  978  49 9  17 25
4 1 911192 17944 32540 1266724 37  2263 12907 3547  834  1421 47 14 20 20
1 1 919292 17876 31824 1275832 1   2745 16327 2747  617  1421 52 11 23 14
5 0 925216 17812 25008 1289320 12  1975 12760 3181  772  1254 50 10 21 19
0 5 932860 17736 21760 1300280 8   2556 15469 3873  825  1258 49 13 24 15

其中:swpd为虚拟内存的使用大小单位为KB.

     Free为空闲的物理内存的大小(KB);

     Buff为内存中缓存的大小,这些缓存是read()和write()函数使用的(KB);

     Cache进程的地址空间在物理内存中的映射(KB);

     So为从内存写入swap空间的数据大小(KB);

     Si为从swap空间写入内存的数据大小(KB);

     Bo为从内存写入硬盘或swap的页数量;

     Bi为从硬盘或swap写入内存的页数量;

从上面的输出我们可以看到:

1. 大量的disk pages(bi)被写入内存,这点可以从cache的不断增长来证明;

2. 在这个过程中,物理内存始终保持在17MB虽然不断有数据从硬盘读入来消耗内存;

3. 为了保持可用物理内存,kswapd不断的从Buff中偷取内存,来加入空闲列表,buff不断减小;

4. 同时kswapd不断的将垃圾页写入swap空间,我们可以看到so和swpd不断增加.

现在我们可以得出结论,这是一个IO Bound的程序,并且造成了虚拟内存的大量使用,加大物理内存可以改善性能.

总结下来:

1. 当一个系统有越少的页错误(所需数据不在内存,需要从硬盘读入),就会有越好的响应时间.因为内存比硬盘快得多.

2. Free memory数量低是一个好的征兆,因为证明了cache在起作用,除非同时存在大量的bi和so.

3. 如果一个系统有持续的si和so,就说明系统的内存是一个瓶颈.

首先说说虚拟内存和物理内存：

虚拟内存就是采用硬盘来对物理内存进行扩展，将暂时不用的内存页写到硬盘上而腾出更多的物理内存让有需要的进程来用。当这些内存页需要用的时候在从硬盘读回内存。这一切对于用户来说是透明的。通常在Linux系统说，虚拟内存就是swap分区。在X86系统上虚拟内存被分为大小为4K的页。

每一个进程启动时都会向系统申请虚拟内存（VSZ），内核同意或者拒就请求。当程序真正用到内存时，系统就它映射到物理内存。RSS表示程序所占的物理内存的大小。用ps命令我们可以看到进程占用的VSZ和RSS。

# ps –aux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

daemon 2177 0.0 0.2 3352 648 ? Ss 23:03 0:00 /usr/sbin/atd

dbus 2196 0.0 0.5 13180 1320 ? Ssl 23:03 0:00 dbus-daemon-1 --sys

root 2210 0.0 0.4 2740 1044 ? Ss 23:03 0:00 cups-config-daemon

root 2221 0.3 1.5 6108 4036 ? Ss 23:03 0:02 hald

root 2231 0.0 0.1 2464 408 tty1 Ss+ 23:03 0:00 /sbin/mingetty tty1

    内核会定期将内存中的数据同步到硬盘，这个过程叫做Memory Paging。同时内核也要负责回收不用的内存，将他们分给其他需要的进程。PFRA算法（Page Frame reclaim algorithm）负责回收空闲的内存。算法根据内存页的类型来决定要释放的内存页。有下列4种类型：

1．  Unreclaimable – 锁定的，内核保留的页面；

2．  Swappable – 匿名的内存页；

3．  Syncable – 通过硬盘文件备份的内存页；

4．  Discardable – 静态页和被丢弃的页。

 

除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收。与之相关的进程是kswapd。在kswapd中，有2个阀值，pages_hige和pages_low。当空闲内存页的数量低于pages_low的时候，kswapd进程就会扫描内存并且每次释放出32个free pages，直到free page的数量到达pages_high。具体kswapd是如何回收内存的呢？有如下原则：

1.    如果页未经更改就将该页放入空闲队列；

2.    如果页已经更改并且是可备份回文件系统的，就理解将内存页的内容写回磁盘；

3.    如果页已经更改但是没有任何磁盘上的备份，就将其写入swap分区。

# ps -ef | grep kswapd

root 30 1 0 23:01 ? 00:00:00 [kswapd0]

 

在回收内存过程中还有两个重要的方法，一是LMR（Low on memory reclaiming），另一个是OMK(Out of Memory Killer)。当分配内存失败的时候LMR将会其作用，失败的原因是kswapd不能提供足够的空闲内存，这个时候LMR会每次释放1024个垃圾页知道内存分配成功。当LMR不能快速释放内存的时候，OMK就开始其作用，OMK会采用一个选择算法来决定杀死某些进程。当选定进程时，就会发送信号SIGKILL，这就会使内存立即被释放。OMK选择进程的方法如下：

1.    进程占用大量的内存；

2.    进程只会损失少量工作；

3.    进程具有低的静态优先级；

4.    进程不属于root用户。

 

进程管理中另一个程序pdflush用于将内存中的内容和文件系统进行同步，比如说，当一个文件在内存中进行修改，pdflush负责将它写回硬盘。

# ps -ef | grep pdflush

root 28 3 0 23:01 ? 00:00:00 [pdflush]

root 29 3 0 23:01 ? 00:00:00 [pdflush]

每当内存中的垃圾页（dirty page）超过10%的时候，pdflush就会将这些页面备份回硬盘。这个比率是可以调节的，通过参数vm.dirty_background_ratio。

# sysctl -n vm.dirty_background_ratio

10

 

Pdflush同PFRA是独立运行的，当内核调用LMR时，LMR就触发pdflush将垃圾页写回硬盘。