我遇到了一个非常有趣的问题，似乎一些物理可能会悄悄消失。我很困惑，所以如果有人能给予帮助，我将不胜感激。
以下是我最喜欢的节目：
按内存使用量排序 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 内存：总计 4041160k，已用 3947524k，可用 93636k，缓冲区 736k 交换：总计 4096536k，已使用 2064148k，可用 2032388k，缓存 41348k PID 用户 PR NI VIRT RES SHR S %CPU %MEM TIME+ 命令 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 iscsid 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 100米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 根 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 ~]# 免费 -m
已使用的、可用的、缓存的共享缓冲区总数
内存：3946 3846 100 0 0 48
-/+ 缓冲区/缓存：3796 149
交换：4000 2037 1963
这是我的 iostat 显示：
[root@ric ~]# iostat -x -d -m 2 Linux 2.6.37 (ric) 2011 年 8 月 16 日 设备：rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util 平均日均值 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 平均价格指数 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 这是交换分区 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
我们可以发现 swap 文件系统使用率很高，消耗了大量的 IO 资源。但是当我们把 top 中的 RSS 列也考虑进去时，我们发现所有进程的 RES 之和并不算多。
所以我的问题是：这是内核级泄漏吗？还是 STServer-1 进程出了问题？（STServer 使用内存池来缓存由于几天没有使用而被换出的文件数据）。
欢迎任何评论。谢谢！
更新1，slabtop显示
活动/总对象（使用百分比）：487002 / 537888（90.5％） 活动/总板坯（使用百分比）：39828 / 39873（99.9%） 活动/总缓存（使用百分比）：102 / 168（60.7%） 活动/总大小（使用百分比）：145605.37K / 154169.46K（94.4％） 最小/平均/最大物体：0.02K/0.29K/4096.00K OBJS 活动使用 OBJ 大小 SLABS OBJ/SLAB 缓存大小 名称 133920 133862 99% 0.02K 930 144 3720K avtab_节点 98896 94881 95% 0.03K 883 112 3532K 大小-32 74052 73528 99% 1.00K 18513 4 74052K 大小-1024 72112 70917 98% 0.44K 9014 8 36056K skbuff_fclone_cache ...
更新2，添加 pmap -x 15168 (STServer-1) 结果
0000000000881000 45116 17872 17272 rw--- [ 匿名 ] 00000000403a1000 4 0 0 ----- [匿名] 00000000403a2000 8192 8 8 rw--- [匿名] ... 00000000510aa000 4 0 0 ----- [匿名] 00000000510ab000 8192 0 0 rw--- [匿名] ... 最多 32 8192 00007f8f2c000000 9832 4004 3964 rw--- [ 匿名 ] 00007f8f2c99a000 55704 0 0 ----- [匿名] 00007f8f34000000 11992 5068 5032 rw--- [匿名] 00007f8f34bb6000 53544 0 0 ----- [匿名] 00007f8f38000000 9768 4208 4164 rw--- [匿名] 00007f8f3898a000 55768 0 0 ----- [匿名] 00007f8f3c000000 13064 4080 4024 rw--- [匿名] 00007f8f3ccc2000 52472 0 0 ----- [匿名] 00007f8f40000000 11244 3700 3688 rw--- [ 匿名 ] 00007f8f40afb000 54292 0 0 ----- [匿名] 00007f8f44000000 11824 7884 7808 rw--- [匿名] 00007f8f44b8c000 53712 0 0 ----- [匿名] 00007f8f4c000000 19500 6848 6764 rw--- [匿名] 00007f8f4d30b000 46036 0 0 ----- [匿名] 00007f8f54000000 18344 6660 6576 rw--- [ 匿名 ] 00007f8f551ea000 47192 0 0 ----- [匿名] 00007f8f58774000 1434160 0 0 rw--- [匿名]内存池 00007f8fb0000000 64628 32532 30692 rw--- [匿名] 00007f8fb7dfe000 1028 1016 1016 rw--- [匿名] 00007f8fb8000000 131072 69512 65300 rw--- [匿名] 00007f8fc0000000 65536 52952 50220 rw--- [匿名] 00007f8fc40a8000 3328 1024 1024 rw--- [匿名] 00007f8fc4aa5000 1028 1028 1028 rw--- [ 匿名 ] 00007f8fc4d12000 1028 1020 1020 rw--- [ 匿名 ] 00007f8fc4f15000 2640 988 936 rw--- [ 匿名 ] 00007f8fc53b6000 2816 924 848 rw--- [ 匿名 ] 00007f8fc5bf6000 102440 0 0 rw--- [ 匿名 ] 总 kB 3202160 348944 327480
看来内核将旧内存（几天没用）交换到交换分区，但是私有内存并没有太多。如果这个程序泄漏了内存，那么它在哪里？在交换区吗？在RSS中？
更新 3，终止 STServer-1 我尝试杀死 STServer-1 进程。然后使用 free -m 检查物理内存。但仍然没有太多剩余。大约剩下 400MB。没有缓存，也没有缓冲区。我写了一个小程序来分配内存，它只能在物理内存中请求 400M，之后，交换将再次被大量使用。
那么我应该说存在内核内存泄漏吗？
更新 4，它再次发生了！ 这里是 grep ^VmPea /proc/*/status | sort -n -k+2 | tail 显示：
/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 内存：总计 4041160k，已用 3951284k，可用 89876k，缓冲区 1132k 交换：总计 4096536k，已使用 645624k，可用 3450912k，缓存 382088k PID 用户 PR NI VIRT RES SHR S %CPU %MEM TIME+ 命令 28352 根 20 0 2585m 1.6g 2320 D 52.2 42.7 267：37.28 STServer-1 3821 呼噜声 20 0 165m 8320 3476 S 10.2 0.2 1797:20 呼噜声 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 平均价格指数 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
任何想法？？
答案1
从 /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 试图消耗最多的 VM 资源，并应该指出使用情况的来源。如果您没有在这个列表中看到大量内存，那么您需要查看 /proc/meminfo 中的其余数字。
答案2
Top 不会显示系统内存，如果您没有针对您的使用情况调整网络缓冲区，则可能使用了过多的内存。