У нас есть сервер с 8 ГБ, на котором запущены mysql, 4 Java-приложения и небольшая база данных postgres. У нас возникают некоторые проблемы с подкачкой системы при выполнении некоторых запросов mysql, поэтому, чтобы увидеть, что происходит, мы выполнили несколько команд, чтобы увидеть, как используется память. Теперь проблема в том, что мы не можем найти, кто использует 4 из наших 8 ГБ. Вот данные, которые у нас есть:
[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
Кажется, что буферы и кеш используются очень мало, поэтому память в основном должна использоваться для процессов:
Отсортировано по% 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,5 ГБ. Итак, вопрос в том, кто использует мою физическую память? Если я добавлю RES + буферы + кеш, это будет около 4 ГБ, а на сервере 8 ГБ! Что мы можем сделать, чтобы диагностировать сервер и увидеть, кто использует отсутствующую оперативную память?
РЕДАКТИРОВАТЬ: сервер является гостем 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
Другой способ узнать, сколько резидентной памяти используют два основных процесса:
[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 (vmmemctl) использует недостающую память.
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
Итак, у вас есть 4 ГБ
Жаль, что vmmemctl не использует стандартный метод, чтобы сообщить, сколько памяти он использует, но я думаю, это потому, что это реализовано.
В основная ссылка от vmware предлагает много подробностей о воздушном шаре. Я цитирую, поскольку это относится к нашей исходной проблеме («почему этот сервер пейджингует, если он не использует память?»):
«Обычно гипервизор раздувает баллон виртуальной машины, когда он находится под нехваткой памяти. Раздувая баллон, виртуальная машина потребляет меньше физической памяти на хосте, но больше физической памяти внутри гостевой системы. В результате гипервизор разгружает часть перегрузка памяти гостевой операционной системы при небольшой загрузке виртуальной машины. То есть гипервизор передает нагрузку на память с хоста на виртуальную машину. Раздувание вызывает давление гостевой памяти. В ответ драйвер балуна выделяет и закрепляет гостевую физическую память . Гостевая операционная система определяет, нужно ли ей выгружать гостевую физическую память для удовлетворения запросов на выделение драйвера балуна. Если на виртуальной машине достаточно свободной гостевой физической памяти, раздутие балуна не вызовет подкачки страниц и не повлияет на производительность гостевой системы. В этом случае, как показано на рисунке 6, драйвер балуна выделяет свободную гостевую физическую память из гостевого свободного списка. Следовательно, guest -уровневая подкачка не требуется.
Однако, если гость уже испытывает нехватку памяти, гостевая операционная система решает, какие гостевые физические страницы будут выгружены на виртуальное устройство подкачки, чтобы удовлетворить запросы на выделение драйвера балуна. Гениальность раздувания заключается в том, что это позволяет гостевой операционной системе разумно принимать трудное решение о том, какие страницы следует выгружать без участия гипервизора ».
"гений воздухоплавания" :)
Является ли система гостевой vmware? Если да, драйвер VMware Balloon может использовать некоторую неучтенную память.