我遇到了一个非常棘手的问题，似乎有些身体可能会悄悄地消失。 我很困惑，所以如果有人可以帮忙，我会非常感激。
这里是我的顶级秀：
按内存使用情况sorting Cpu：0.8％us，1.0％sy，0.0％ni，81.1％id，14.2％wa，0.0％hi，2.9％si，0.0％st Mem：共4041160k，使用3947524k，93636k免费，736k缓冲区 交换：总共4096536k，使用2064148k，2032388k免费，41348kcaching PID用户PR NI VIRT RES SHR S％CPU％MEM时间+命令 15168根20 0 3127m 290m 1908 S 108.2 7.4 43376：10 STServer-1 18303根20 0 99.7米12米912 S 0.0 0.3 0：00.86 sshd 7129根20 0 17160 7800 520 S 0.5 0.2 5：37.52 thttpd 2583根10 -10 4536 2488 1672 S 0.0 0.1 1：19.33等 4360根20 0 15660 2308 464 S 0.0 0.1 15：42.71 lbtcpd.out 4361根20 0 186m 1976 964 S 0.5 0.0 82：00.36 lbsvr.out 3932根20 0 100m 1948 836 S 0.0 0.0 30：31.38 snmpd 18604根20 0 66212 1184 820 S 0.0 0.0 0：00.06 bash 18305根20 0 66112 1136 764 S 0.0 0.0 0：00.03 bash 18428根20 0 12924 1076 708 R 1.0 0.0 0：21.10顶部 15318根20 0 99.7m 1020 996 S 0.0 0.0 0：01.15 sshd 15320根20 0 66228 996 788 S 0.0 0.0 0：00.80 bash 1719根20 0 90216 980 884 S 0.0 0.0 0：02.29 sshd 15492根20 0 66216 972 780 S 0.0 0.0 0：00.20 bash 15382根20 0 90300 964 892 S 0.0 0.0 0：00.57 sshd 1688根20 0 90068 960 852 S 0.0 0.0 0：00.57 sshd 2345根20 0 90068 928 852 S 0.0 0.0 0：00.50 sshd 16175根20 0 90216 924 884 S 0.0 0.0 0：00.64 sshd 2377根20 0 90068 908 852 S 0.0 0.0 0：00.44 sshd 2725根20 0 90216 896 884 S 0.0 0.0 0：05.27 sshd 3929 root 20 0 182m 896 816 S 0.0 0.0 0：43.61 systemInfoSubAg 15986根20 0 66216 884 772 S 0.0 0.0 0：00.03 bash
这是我的免费节目：
[root @ ric〜]＃free -m
caching总共使用的空闲共享缓冲区
Mem：3946 3846 100 0 0 48
- / + buffers / cache：3796 149
交换：4000 2037 1963
这里是我的iostat显示：
[root @ ric〜]＃iostat -x -d -m 2 Linux 2.6.37（ric）08/16/2011 设备：rrqm / s wrqm / sr / sw / s rmb / s wmb / s avgrq-sz avgqu-sz await svctm％util sda 93.24 222.57 95.44 64.40 4.10 1.12 66.96 1.37 25.46 2.78 44.44 sda1 0.00 0.00 0.00 0.00 0.00 0.00 40.80 0.00 4.00 3.10 0.00 sda2 0.00 0.00 0.00 0.00 0.00 0.00 22.35 0.00 22.52 14.80 0.00 sda4 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 33.00 33.00 0.00 sda5 92.73 7.49 53.39 45.79 0.57 0.21 16.08 0.72 34.67 3.19 31.67 sda6 0.50 215.08 42.06 18.61 3.53 0.91 150.14 0.65 55.27 6.36 38.58 设备：rrqm / s wrqm / sr / sw / s rmb / s wmb / s avgrq-sz avgqu-sz await svctm％util sda 596.02 139.30 248.26 153.73 3.38 1.14 23.02 147.54 482.67 2.49 99.90 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda5 596.02 129.35 244.28 150.25 3.30 1.09 22.79 146.51 488.14 2.53 99.90 这是swap分区 sda6 0.00 9.95 3.98 3.48 0.08 0.05 35.20 1.03 193.60 75.20 56.12
有些编号来自/ proc / meminfo
MemTotal: 4041160 kB MemFree: 130288 kB Buffers: 820 kB Cached: 40940 kB SwapCached: 82632 kB SwapTotal: 4096536 kB SwapFree: 2005408 kB uname -a显示：Linux ric 2.6.37＃4 SMP Fri Jan 14 10:23:46 CST 2011 x86_64 x86_64 x86_64 GNU / Linux
我们可以发现交换fs被大量使用。 而且它消耗了很多的IO资源。 但是当我们把RSS列在最前面时，我们发现所有进程RES的总和不是太多。
所以我的问题是：这是一个内核级泄漏？ 或者STServer-1进程有问题？ （STServer使用momery池来caching由于几天没有使用而被换出的文件数据）。
欢迎任何评论。 谢谢！
udpate 1，slabtop显示
主动/总对象（使用％）：487002/537888（90.5％） 主动/总板（使用％）：39828/39873（99.9％） 主动/总高速caching（使用百分比）：102/168（60.7％） 活性/总量（使用％）：145605.37K / 154169.46K（94.4％） 最小/平均/最大对象：0.02K / 0.29K / 4096.00K OBJS主动使用OBJ尺寸板坯OBJ / SLAB CACHE SIZE NAME 133920 133862 99％0.02K 930 144 3720K avtab_node 98896 94881 95％0.03K 883 112 3532K size-32 74052 73528 99％1.00K 18513 4 74052K size-1024 72112 70917 98％0.44K 9014 8 36056K skbuff_fclone_cache ...
更新2，添加pmap -x 15168（STServer-1）的结果
0000000000881000 45116 17872 17272 rw --- [anon] 00000000403a1000 4 0 0 ----- [anon] 00000000403a2000 8192 8 8 rw --- [anon] ... 00000000510aa000 4 0 0 ----- [anon] 00000000510ab000 8192 0 0 rw --- [anon] ...多达32 8192 00007f8f2c000000 9832 4004 3964 rw --- [anon] 00007f8f2c99a000 55704 0 0 ----- [anon] 00007f8f34000000 11992 5068 5032 rw --- [anon] 00007f8f34bb6000 53544 0 0 ----- [anon] 00007f8f38000000 9768 4208 4164 rw --- [anon] 00007f8f3898a000 55768 0 0 ----- [anon] 00007f8f3c000000 13064 4080 4024 rw --- [anon] 00007f8f3ccc2000 52472 0 0 ----- [anon] 00007f8f40000000 11244 3700 3688 rw --- [anon] 00007f8f40afb000 54292 0 0 ----- [anon] 00007f8f44000000 11824 7884 7808 rw --- [anon] 00007f8f44b8c000 53712 0 0 ----- [anon] 00007f8f4c000000 19500 6848 6764 rw --- [anon] 00007f8f4d30b000 46036 0 0 ----- [anon] 00007f8f54000000 18344 6660 6576 rw --- [anon] 00007f8f551ea000 47192 0 0 ----- [anon] 00007f8f58774000 1434160 0 0 rw --- [anon] 内存池 00007f8fb0000000 64628 32532 30692 rw --- [anon] 00007f8fb7dfe000 1028 1016 1016 rw --- [anon] 00007f8fb8000000 131072 69512 65300 rw --- [anon] 00007f8fc0000000 65536 52952 50220 rw --- [anon] 00007f8fc40a8000 3328 1024 1024 rw --- [anon] 00007f8fc4aa5000 1028 1028 1028 rw --- [anon] 00007f8fc4d12000 1028 1020 1020 rw --- [anon] 00007f8fc4f15000 2640 988 936 rw --- [anon] 00007f8fc53b6000 2816 924 848 rw --- [anon] 00007f8fc5bf6000 102440 0 0 rw --- [anon] 总计kB 3202160 348944 327480
看起来内核交换旧的内存（不用几天）来交换分区，但私有内存不是太多。 如果这个程序泄漏内存，那么它在哪里呢？ 在交换？ 在RSS？
更新3，杀死STServer-1我试图杀死STServer-1进程。 使用-m来检查物理内存。 但还剩下不多。 剩下大约400MB。 没有caching，没有caching。 我写了一个小程序来分配内存，它只能在物理内存中请求400M，之后，swap会再次大量使用。
所以我应该说有一个内核内存泄漏？
更新4，它再次发生！ 这里是grep ^ VmPea / proc / * / status | sort -n -k + 2 | 尾部显示：
/ proc / 3841 / status：VmPeak：155176 kB / proc / 3166 / status：VmPeak：156408 kB / proc / 3821 / status：VmPeak：169172 kB / proc / 3794 / status：VmPeak：181380 kB / proc / 3168 / status：VmPeak：210880 kB / proc / 3504 / status：VmPeak：242268 kB / proc / 332 / status：VmPeak：254184 kB / proc / 5055 / status：VmPeak：258064 kB / proc / 3350 / status：VmPeak：336932 kB / proc / 28352 / status：VmPeak：2712956 kB
顶部显示：
任务：共225次，1次跑步，224次睡眠，0次停止，0次僵尸 Cpu：1.9％us，1.3％sy，0.0％ni，51.9％id，43.6％wa，0.0％hi，1.3％si，0.0％st Mem：4041160k共计，3951284k使用，89876k免费，1132k缓冲区 交换：总共4096536k，使用645624k，存储3450912k，存储382088k PID用户PR NI VIRT RES SHR S％CPU％MEM时间+命令 28352根20 0 2585m 1.6g 2320 D 52.2 42.7 267：37.28 STServer-1 3821 snort 20 0 165m 8320 3476 S 10.2 0.2 1797：20 snort 21043根20 0 17160 7924 520 S 0.0 0.2 1：50.55 thttpd 2586根10 -10 4536 2488 1672 S 0.0 0.1 0：28.59 iscsid
iostat显示：
设备：rrqm / s wrqm / sr / sw / s rmb / s wmb / s avgrq-sz avgqu-sz await svctm％util sda 72.50 0.00 351.00 2.50 12.25 0.01 71.02 174.22 213.93 2.83 100.20 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda5 64.00 0.00 50.00 0.00 0.43 0.00 17.76 76.06 59.44 20.04 100.20 交换分区 sda6 8.50 0.00 301.00 2.50 11.81 0.01 79.79 98.16 239.39 3.30 100.20
任何想法？？
从/ proc中检查VmPeak：
$ grep ^VmPea /proc/*/status | sort -n -k+2 | tail /proc/32253/status:VmPeak: 86104 kB /proc/5425/status:VmPeak: 86104 kB /proc/9830/status:VmPeak: 86200 kB /proc/8729/status:VmPeak: 86248 kB /proc/399/status:VmPeak: 86472 kB /proc/19084/status:VmPeak: 87148 kB /proc/13092/status:VmPeak: 88272 kB /proc/3065/status:VmPeak: 387968 kB /proc/26432/status:VmPeak: 483480 kB /proc/31679/status:VmPeak: 611780 kB
这应该显示哪个PID试图消耗最多的虚拟机资源，并应该指出使用的来源。 如果你没有在这个列表中看到大量的内存，那么你需要查看/ proc / meminfo中剩下的数字。
顶部不显示系统内存，如果你没有为你的用例调整networking缓冲区，你可能会使用太多的内存。