我们有8GB的服务器，运行mysql，4个java应用程序和一个小的postgres数据库。 我们在运行一些mysql查询时遇到了一些系统分页的问题，所以为了看看发生了什么，我们运行了一些命令来查看内存是如何被使用的。 现在的问题是，我们无法find谁正在使用我们的8 GB中的4个。 这里是我们的数据：
[root@server1 ~]# free -mt total used free shared buffers cached Mem: 7983 7934 49 0 65 584 -/+ buffers/cache: 7284 699 Swap: 5951 1032 4919 Total: 13935 8966 4968 所以缓冲区和caching似乎有一个非常小的用法，所以内存应该主要用于进程：
按照％MEM的顺序排列（只有％MEM> 0.0的进程）
top - 16:31:00 up 3 days, 16:26, 3 users, load average: 0.51, 0.53, 0.56 Tasks: 153 total, 1 running, 151 sleeping, 0 stopped, 1 zombie Cpu(s): 9.9%us, 0.6%sy, 0.0%ni, 85.3%id, 4.1%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 8175264k total, 8126480k used, 48784k free, 70312k buffers Swap: 6094840k total, 1057440k used, 5037400k free, 595348k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ DATA nFLT nDRT COMMAND 7377 mysql 15 0 2677m 1.8g 4624 S 3.0 22.7 107:28.89 2.6g 95k 0 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/my 17836 root 21 0 2472m 1.0g 9872 S 2.3 13.2 11:18.44 2.4g 403 0 /usr/local/jdk1.6.0_25//bin/java -Djava.util.logging.config.file=/tomcat/conf/logging.properties -Drmi 17969 root 18 0 731m 222m 10m S 3.0 2.8 14:06.67 640m 33 0 /java//bin/java -Xms256m -Xmx256m -Xloggc:/var/log/gestorDeTramas.gc -XX:+PrintGCDetails -Dservice.mod 17980 root 21 0 407m 77m 10m S 0.0 1.0 0:04.35 313m 36 0 /java//bin/java -Xms32m -Xmx64m -Xloggc:/var/log/mensajero.gc -XX:+PrintGCDetails -Dservice.mode=rmi - 19866 postgres 15 0 160m 43m 34m S 11.3 0.5 1:51.57 9856 4 0 postgres: postgres mapas 127.0.0.1(46751) idle 24892 postgres 15 0 160m 41m 32m S 0.0 0.5 1:09.97 9804 3 0 postgres: postgres mapas 127.0.0.1(36534) idle 24891 postgres 15 0 160m 40m 31m S 0.0 0.5 0:50.74 9892 1 0 postgres: postgres mapas 127.0.0.1(36533) idle 24886 postgres 15 0 160m 40m 31m S 4.7 0.5 0:51.35 9936 0 0 postgres: postgres mapas 127.0.0.1(36528) idle 23622 postgres 15 0 160m 40m 31m S 0.0 0.5 0:55.42 9952 1 0 postgres: postgres mapas 127.0.0.1(47826) idle 24887 postgres 15 0 160m 40m 31m S 0.0 0.5 0:44.11 9888 2 0 postgres: postgres mapas 127.0.0.1(36529) idle 24880 postgres 16 0 160m 38m 29m S 4.3 0.5 0:42.49 9920 2 0 postgres: postgres mapas 127.0.0.1(36522) idle 24881 postgres 15 0 160m 29m 20m S 12.6 0.4 0:04.66 9948 0 0 postgres: postgres mapas 127.0.0.1(36523) idle 4139 root 34 19 256m 11m 1652 S 0.0 0.1 0:11.58 18m 902 0 /usr/bin/python -tt /usr/sbin/yum-updatesd
所以，如果我添加RES列，我得到3.5GB左右。 所以，问题是，谁在使用我的物理记忆？ 如果我添加RES +缓冲区+caching大约4GB和服务器有8GB！ 我们可以做些什么来诊断服务器，看看谁在使用丢失的内存？
编辑：服务器是VMware客人。
还要注意，mysql进程有很多页面错误。
更多数据：
[root@server1 ~]# cat /proc/meminfo MemTotal: 8175264 kB MemFree: 47204 kB Buffers: 63180 kB Cached: 611144 kB SwapCached: 513392 kB Active: 3458724 kB Inactive: 538952 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 8175264 kB LowFree: 47204 kB SwapTotal: 6094840 kB SwapFree: 5037416 kB Dirty: 342108 kB Writeback: 44 kB AnonPages: 3303684 kB Mapped: 61352 kB Slab: 79452 kB PageTables: 19236 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 10182472 kB Committed_AS: 5778312 kB VmallocTotal: 34359738367 kB VmallocUsed: 266052 kB VmallocChunk: 34359471959 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 2048 kB
查看两个顶级进程正在使用多less驻留内存的另一种方法是：
[root@server1 ~]# cat /proc/7377/smaps | grep ^Rss | awk '{A+=$2} END{print A}' 1852112 [root@server1 ~]# [root@server1 ~]# cat /proc/17836/smaps | grep ^Rss | awk '{A+=$2} END{print A}' 1081620
该系统是一个VMware客户？ 如果是，则VMware Balloon驱动程序可以使用一些不计数的内存。
感谢Minto Joseph的回答，我发现VMware气球驱动程序（vmmemctl）正在使用缺less的内存。
cat /proc/vmmemctl target: 1000894 pages current: 1000894 pages rateNoSleepAlloc: 16384 pages/sec rateSleepAlloc: 2048 pages/sec rateFree: 16384 pages/sec timer: 325664 start: 3 ( 0 failed) guestType: 3 ( 0 failed) lock: 3623088 ( 29 failed) unlock: 623698 ( 0 failed) target: 325664 ( 2 failed) primNoSleepAlloc: 3620199 ( 11 failed) primCanSleepAlloc: 2900 ( 0 failed) primFree: 2622165 errAlloc: 28 errFree: 28 getconf PAGESIZE 4096
所以你有4GB的
很遗憾，vmmemctl并没有使用标准的方法来报告它使用了多less内存，但是我认为这是因为它是如何实现的。
vmware的主要参考提供了许多关于膨胀的细节。 我引用，因为它与我们原来的问题（'为什么这个服务器分页，如果它没有使用内存'？）：
“通常情况下，虚拟机pipe理程序在内存压力下虚拟机虚拟机膨胀，通过膨胀虚拟机，虚拟机在主机上占用更less的物理内存，但客户机内部的物理内存更多，因此pipe理程序会卸载部分在客户操作系统的内存过载的同时稍微加载虚拟机，也就是说，虚拟机pipe理程序将内存压力从主机传输到虚拟机，气球感应引起访客内存压力，作为响应，气球驱动程序分配和引导访客物理内存客户操作系统决定是否需要分页客户物理内存以满足分配请求，如果虚拟机具有足够的空闲客户物理内存，则膨胀气球不会导致分页，也不会影响客户的性能。在这种情况下，如图6所示，气球驱动程序从来宾空闲列表中分配空闲来宾物理内存 级别的分页是没有必要的。
然而，如果访客已经处于内存压力之下，则访客操作系统决定将哪些访客物理页面调出到虚拟交换设备以便满足气球驱动程序的分配请求。 膨胀的天才在于它允许客户操作系统智能地做出关于哪些页面被分页而不需要pipe理程序参与的艰难决定。
“膨胀的天才”:)