Я несколько раз получал уведомления от моей системы мониторинга о 98% памяти. Я побежал top и насчитал только около 60% используемой памяти, если я суммирую объем памяти столбец. Через несколько часов использование памяти вернулось к норме (~ 70%). Я подозревал fs cache, но free -m не доказывает этого.
Любые идеи? Сервер: x86-64, ubuntu 12.04, 8 ГБ ОЗУ
# free -m
total used free shared buffers cached
Mem: 7958 7835 123 0 8 39
-/+ buffers/cache: 7787 171
Swap: 975 975 0
#top
top - 10:11:48 up 179 days, 14:25, 1 user, load average: 1.99, 1.81, 1.59
Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.8%us, 0.6%sy, 0.0%ni, 82.8%id, 13.6%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8149424k total, 8017556k used, 131868k free, 6708k buffers
Swap: 999420k total, 999372k used, 48k free, 37952k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30562 mysql 20 0 6033m 2.6g 3160 S 14 32.9 74:37.56 mysqld
10898 www-data 20 0 25.3g 2.0g 1560 S 16 25.6 19:44.10 java
9570 rabbitmq 20 0 2611m 166m 1540 S 6 2.1 628:08.96 beam.smp
13166 redis 20 0 94276 72m 584 S 0 0.9 23:24.47 redis-server
3798 root 20 0 348m 29m 988 S 0 0.4 167:36.37 cimprovagt
7614 root 20 0 51468 28m 1256 S 0 0.4 0:02.59 bash
3677 root 20 0 4706m 26m 0 S 0 0.3 110:47.59 java
3458 bind 20 0 668m 5328 1488 S 0 0.1 0:23.38 named
7595 root 20 0 85380 2956 880 S 0 0.0 0:00.25 sshd
2061 root 10 -10 4996 2948 2104 S 0 0.0 13:39.72 iscsid
632 syslog 20 0 244m 2404 360 S 0 0.0 7:12.39 rsyslogd
5855 newrelic 20 0 107m 1852 1248 S 0 0.0 128:23.28 nrsysmond
1 root 20 0 24340 1516 736 S 0 0.0 0:29.96 init
2741 root 20 0 17340 1308 944 R 0 0.0 0:00.04 top
4214 root 20 0 45336 1264 1020 S 0 0.0 6:12.72 cdm
4235 root 20 0 12428 1108 908 S 0 0.0 10:55.38 processes
4178 root 20 0 19124 1064 856 S 0 0.0 7:20.07 controller
5853 ntp 20 0 37772 1036 872 S 0 0.0 7:40.35 ntpd
4179 root 20 0 86044 1024 848 S 0 0.0 9:55.54 spooler
4008 root 20 0 4090m 980 756 S 0 0.0 0:08.70 console-kit-dae
3790 root 20 0 422m 952 668 S 0 0.0 89:21.80 cimprovagt
3629 root 20 0 50032 868 752 S 0 0.0 1:17.44 sshd
4075 root 20 0 182m 844 408 S 0 0.0 0:02.90 polkitd
27661 root 20 0 101m 776 772 S 0 0.0 0:00.02 mysql
18465 root 20 0 101m 732 732 S 0 0.0 0:00.04 mysql
3436 root 20 0 19112 716 636 S 0 0.0 0:11.25 cron
3783 root 20 0 1009m 716 432 S 0 0.0 0:04.83 cimserver
26239 root 20 0 22092 700 696 S 0 0.0 0:00.03 bash
4181 root 20 0 13196 696 596 S 0 0.0 4:18.57 hdb
3406 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3410 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3428 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3429 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3432 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3972 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
18452 root 20 0 22076 620 620 S 0 0.0 0:00.00 bash
361 root 20 0 22104 568 568 S 0 0.0 0:00.04 udevd
3441 root 20 0 15980 560 464 S 0 0.0 26:28.16 irqbalance
654 messageb 20 0 23948 516 324 S 0 0.0 0:01.98 dbus-daemon
676 root 20 0 21188 504 504 S 0 0.0 0:00.00 bluetoothd
3665 root 20 0 4400 492 488 S 0 0.0 0:00.00 sh
5546 rabbitmq 20 0 7672 488 308 S 0 0.0 1:04.49 epmd
26238 root 20 0 26092 476 476 S 0 0.0 0:00.24 screen
2060 root 20 0 4504 440 400 S 0 0.0 3:18.60 iscsid
буферы является кеш ФС.
Буферы связаны с конкретным блочным устройством и охватывают кэширование метаданных файловой системы, а также отслеживание страниц в полете. Кэш содержит только данные о припаркованных файлах. То есть буферы запоминают, что находится в каталогах, какие права доступа к файлам, и отслеживают, из какой памяти выполняется запись или чтение для конкретного блочного устройства. Кеш содержит только содержимое самих файлов.
https://stackoverflow.com/a/12547130/636573
Top также показывает 13% IOWAIT на снимке, который вы нам предоставили. На мой взгляд, это похоже на то, что база данных OLTP не получает достаточного количества операций ввода-вывода в секунду, которые ей необходимы. Обновите свою подсистему хранения.
Хорошо, сначала вернитесь и убедитесь, что ваш верхний вывод отсортирован по использованию памяти (RESИдентификационный размер), и если это не так, обновите свой вопрос с помощью который вывод. Тогда вы действительно сможете увидеть, что пожирает вашу оперативную память.
Во-вторых, забудьте о %MEM столбец. Этот торт - ложь (из-за округления).
Сконцентрируйтесь на RESидентифицируйте размер программ (и если вас беспокоит переключение на VIRTразмер) вместо - сумма те столбцы и числа будут соответствовать тому, что вы видите в free & top вывод.
Глядя на ваш главный результат, вы получаете гигантский (2,6 Гбайт) процесс MySQL и гигантский (2,0 Гбайт) процесс Java - я подозреваю, что эти двое являются вашими соучастниками в пережевывании всей вашей оперативной памяти (каким бы ни был этот конкретный процесс Java. просьба сделать MySQL генерирует огромные наборы результатов или промежуточные данные).
У процесса Java также есть виртуальный размер 25 ГБ (!!) - очевидно, что происходит внутренняя утечка памяти, которую сборщик мусора не освобождает (или, возможно, он имеет дело с огромным набором результатов неэффективно).
Я готов поспорить, что ваша система, вероятно, использует 4-5 ГБ ОЗУ в «нормальный день», и когда эти два процесса объединяются, они поглощают все остальное (а затем и некоторые), и вы попадаете в плохое место.
Узнайте, что они делают, исправьте, и ваша проблема исчезнет.