资源描述
在我们的生产系统中，因为一些原因，我们在一部分服务器上安装了版本号为2.6.38的内 核(曾经为Debian 6 backports的版本)，这个版本被证明是存在很多bug。下面开始描述 该内核版本中存在的一个bug。背景和症状：系统：Debian 6, 32 bit内存:4GiB作为客户端挂载nfs, nfs server提供了大量的小文件症状：在运行一段时间后，触发oom killer，大量进程被杀死。但是诡异的是，触发oom killer 的时候，实际上系统还是有大量的内存是可用的分析：幸运的是，我们有日志可以分析，先查看syslogapache2 in voked oom-killer: gfp_mask=OxdO, order=O, oom_adj=0, oom_score_adj=Oapache2 cpuset=/ mems_allowed=0Pid: 3270, comm: apache2 Not tai nted 2.6.38-bpo.2-686-bigmem #1Call Trace:? T.646+0x5a/0x135? T.645+0x30/0x20e? security_real_capable_noaudit+0x1f/0 x39? out_of_memory+0x1fa/0x280snipCPU 6: hi: 186, btch: 31 usd: 177CPU 7: hi: 186, btch: 31 usd: 111active_a non: 131731 in active_a non:27084 isolated_a non :0active_file:222873 in active_file:185534 isolated_file:0un evictable:685 dirty:51 writeback:0 un stable:0 free:259021 slab_reclaimable:194035 slab_u nreclaimable:5733 mapped:5063 shmem:325 pagetables:927 boun ce:0DMA free:4240kB mi n:784kB low:980kB high:1176kB active_a non :0kBin active_a non:0kB active_file:0kB in activeile:0kB un evictable:0kB isolated(a non ):0kB isolated(file):0kB prese nt:15808kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:11328kB slab_u nreclaimable:312kB kern el_stack:0kB pagetables:OkB un stable:OkB boun ce:0kB writeback_tmp:OkB pages_sca nn ed:0all_ un reclaimable? yeslowmemeserve: 0 867 4032 4032Normal free:43732kB min: 44116kB low:55144kB high:66172kB active_a non:0kBin active_a non:0kB active_file:0kB in active_file:8kB un evictable:0kB isolated(a non ):0kB isolated(file):0kB prese nt:887976kB mlocked:0kB dirty:8kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:764812kB slab_u nreclaimable:22620kBker nel_stack:2704kB pagetables:24kB un stable:0kB bou nce:0kB writeback_tmp:0kB pages_sca nn ed:112 all_ un reclaimable? yeslowmemeserve: 0 0 25324 25324HighMem free:988112kB mi n:512kB low:40772kB high:81036kB active_a non :526924kB in active_a non :108336kB active_file:891704kB in active_file:742128kBun evictable:2740kB isolated(a non ):0kB isolated(file):0kB prese nt:3241528kB mlocked:2740kB dirty:196kB writeback:0kB mapped:20248kB shmem:1300kB slab_reclaimable:0kB slab_ un reclaimable:0kB ker nel_stack:0kB pagetables:3684kB un stable:0kB boun ce:0kB writeback_tmp:0kB pages_sca nn ed:0 all_ un reclaimable? no lowmem_reserve: 0 0 0 0DMA: 4*4kB 2*8kB 43*16kB 14*32kB 12*64kB 6*128kB 2*256kB 0*512kB 1*1024kB0*2048kB 0*4096kB = 4240kBNormal: 668*4kB 1385*8kB 1673*16kB 1*32kB 1*64kB 1*128kB 2*256kB 2*512kB0*1024kB 1*2048kB 0*4096kB = 44328kBHighMem: 123*4kB 37567*8kB 28863*16kB 4814*32kB 359*64kB 132*128kB 48*256kB 19*512kB 7*1024kB 1*2048kB 0*4096kB = 987988kB417632 total pagecache pages8311 pages in swap cacheSwap cache stats: add 20440, delete 12129, find 11215/11322Free swap = 9923268kBTotal swap = 10000424kB1245168 pages RAM1017346 pages HighMem210680 pages reserved47964 pages shared745096 pages non-shared预备知识：Memory Zone: 在32位系统中，内存被分为3个区域，DMA zone, Normal zone和HighMem zone, 其中DMA zone主要用于DMA传输数据，位于低地址空间，其服务对象为各种驱动程序， 其大小为16MiB，其中Normal zone是kernel可以直接访问的地址空间，其大小为924MiB,基本上所有的内核数据都在这个区域，同时如果内核要访问更高地址空间的内容，均 需要通过Normal zone映射过去才可以。地址空间大于940 MiB的为HlghMem zone.Memory watermark:在Linux的内存管理中，对于内存是否该释放是针对每个zone考量的。而考量的参数有 high, low, min三个参数。当内存可用量小于low的时候，kernel开始释放内存，当内存 可用量小于min的时候，oom-killer就开始活跃了。kernel要么不释放内存，一旦开始释 放内存，它将持续释放内存一直到可用的内存大于high。参考下图：好，预备知识准备完毕，现在开始进入诊断流程。让我们先来关注下面这行：Normal free:43732kB min44116kB low:55144kB high:66172kB我们看到Normal zone可用的(free )内存小于min,这是触发oom-killer的原因。在这 个时候，HighMem zone可用空间还是很多，同时几乎没有swap使用。那么我们看看到底是什么占用了这么多内存，先看内核空间的：# slabtop -s c | headActive / Total Objects (% used) : 1610968 / 2176420 (74.0%)Active / Total Slabs (% used) : 39335 / 39335 (100.0%)Active / Total Caches (% used) : 61 / 85 (71.8%)Active / Total Size (% used) : 423355.27K / 461223.70K (91.8%)Mi nimum / Average / Maximum Object : 0.01K / 0.21K / 8.00KOBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME490588 490588 100% 0.65K 10012 49 320384K nfs_i node_cache1203584 708306 58% 0.06K 18806 64 75224K kmalloc-64188960 188520 99% 0.12K 5905 32 23620K den try#我们看到nfs_inode_cache占用了大概300 MiB,在正常情况下，nfs_inode_cache应该 30 MiB左右。所以nfsnode_cache在这里是异常的。我们尝试设置在内存不够用的情况下，优先回收in ode cache，但是没有效果，最后我们通 过升级内核到3.2版本，系统恢复了正常。
展开阅读全文