Я несколько раз получал уведомления от своей системы мониторинга о 98% памяти. Я запустил topи насчитал только около 60% памяти, если суммироватьПамятьколонка. Через несколько часов использование памяти вернулось к норме (~70%). Я подозревал кэш fs, но free -mэто не доказано.
Есть идеи? Сервер: x86-64, ubuntu 12.04, 8Gb RAM
# 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
решение1
буферыявляетсякэш ФС.
Буферы связаны с определенным блочным устройством и охватывают кэширование метаданных файловой системы, а также отслеживание страниц в процессе. Кэш содержит только данные припаркованных файлов. То есть буферы запоминают, что находится в каталогах, какие разрешения у файлов, и отслеживают, какая память записывается или считывается для определенного блочного устройства. Кэш содержит только содержимое самих файлов.
https://stackoverflow.com/a/12547130/636573
Top также показывает 13% IOWAIT на снимке, который вы нам дали. Мне кажется, что база данных OLTP не получает достаточного количества дисковых IOPS, которые ей нужны. Обновите подсистему хранения.
решение2
Хорошо, сначала вернитесь и убедитесь, что ваш главный вывод отсортирован по использованию памяти ( RESразмеру идентификатора), и если это не так, продолжайте и обновите свой вопрос с помощьючтовывод. Тогда вы действительно сможете увидеть, что именно пожирает вашу оперативную память.
Во-вторых, забудьте о %MEMстолбце. Этот конкретный торт — ложь (из-за округления).
Сосредоточьтесь на RESident size программ (и если вас беспокоит swap to, VIRTual size) вместо этого — sumтестолбцы и числа будут соответствовать тому, что вы видите в freeрезультатах top.
Если посмотреть на ваш главный вывод, то вы видите гигантский (2,6 ГБ) процесс MySQL и гигантский (2,0 ГБ) процесс Java — я подозреваю, что эти двое — ваши сообщники, которые пожирают всю вашу оперативную память (что бы этот конкретный процесс Java ни просил MySQL сделать, он генерирует огромные наборы результатов или промежуточные данные).
Процесс Java также имеет виртуальный размер 25 ГБ (!!) — очевидно, что он внутренне утекает память, которую сборщик мусора не освобождает (или, возможно, он неэффективно справляется с огромным набором результатов).
Я готов поспорить, что ваша система, вероятно, использует 4-5G оперативной памяти в "обычный день", а когда эти два процесса объединяются, они поглощают все остальное (и даже больше), и вы оказываетесь в Bad Place.
Выясните, что они делают, исправьте это, и ваша проблема исчезнет.