码迷,mamicode.com
首页 > 系统相关 > 详细

Linux性能监控之Memory篇

时间:2016-01-28 15:15:30      阅读:331      评论:0      收藏:0      [点我收藏+]

标签:

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

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

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

# 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_higepages_low。当空闲内存页的数量低于pages_low的时候,kswapd进程就会扫描内存并且每次释放出32free pages,直到free page的数量到达pages_high。具体kswapd是如何回收内存的呢?有如下原则:

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

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

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

# ps -ef | grep kswapd

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

 

在回收内存过程中还有两个重要的方法,一是LMRLow 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

 

PdflushPFRA是独立运行的,当内核调用LMR时,LMR就触发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,就说明系统的内存是一个瓶颈.

 

转自:http://blog.163.com/bobile45@126/blog/static/96061992201210101619125/

 

Linux性能监控之Memory篇

标签:

原文地址:http://www.cnblogs.com/test0726/p/5166192.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!