Я пытаюсь устранить проблему нехватки памяти, которая, кажется, затрагивает mysqld служба. Служба умирает совершенно случайно - иногда раз в неделю, иногда каждые два дня.
Мой VPS имеет 6 ГБ оперативной памяти и нет файла подкачки (мой провайдер не разрешает / не поддерживает подкачки). Мое приложение PHP-исходя из (Symfony framework) и работает на Apache 2.2.
Сегодня вечером я наблюдал всплеск использования оперативной памяти. К сожалению, мне не удалось получить точный результат free -m, но я помню это -/+ buffers/cache для столбца free было около 1G. Использование ОЗУ увеличивалось и уменьшалось с 4,8 ГБ до 5,2 ГБ.
Во время окна обслуживания я выключил httpd, mysqld и mongod, после чего у меня есть следующие free -m вывод:
[root@XXXYYYZZZ ~]# free -m
total used free shared buffers cached
Mem: 6144 4916 1227 0 0 1207
-/+ buffers/cache: 3709 2434
Swap: 0 0 0
Мой вопрос в том, что происходит с этими 3709M используемой памяти? В top команда мало что раскрывает:
top - 19:54:58 up 3 days, 6:35, 2 users, load average: 0.00, 0.01, 0.05
Tasks: 21 total, 1 running, 20 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 6291456k total, 5034692k used, 1256764k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 1236060k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 19236 1180 932 S 0.0 0.0 0:00.02 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/23992
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/23992
140 root 16 -4 10644 520 248 S 0.0 0.0 0:00.00 udevd
482 root 20 0 179m 1252 828 S 0.0 0.0 0:00.04 rsyslogd
493 dbus 20 0 21408 616 376 S 0.0 0.0 0:00.00 dbus-daemon
510 root 20 0 66632 1232 520 S 0.0 0.0 0:00.00 sshd
517 root 20 0 22184 904 668 S 0.0 0.0 0:00.00 xinetd
870 root 20 0 66828 924 276 S 0.0 0.0 0:00.00 saslauthd
871 root 20 0 66828 680 32 S 0.0 0.0 0:00.00 saslauthd
886 root 20 0 83080 2664 840 S 0.0 0.0 0:04.99 sendmail
894 smmsp 20 0 78668 2108 648 S 0.0 0.0 0:00.03 sendmail
944 root 20 0 114m 1232 628 S 0.0 0.0 0:00.81 crond
955 root 20 0 88304 21m 1784 S 0.0 0.3 0:05.25 miniserv.pl
22840 root 20 0 96276 4448 3460 S 0.0 0.1 0:00.09 sshd
22842 root 20 0 105m 1988 1524 S 0.0 0.0 0:00.03 bash
22985 root 20 0 96300 4168 3164 S 0.0 0.1 0:00.03 sshd
22987 root 20 0 57848 2340 1624 S 0.0 0.0 0:00.04 sftp-server
23313 root 20 0 96276 4472 3460 S 0.0 0.1 0:00.68 sshd
23315 root 19 -1 105m 2024 1544 S 0.0 0.0 0:00.16 bash
25080 root 19 -1 14900 1220 992 R 0.0 0.0 0:00.00 top
Я знаю, что Linux выполняет кэширование в ОЗУ, но я бы сказал, что это довольно нерегулярно. Я могу ошибаться, и на самом деле надеюсь, что ошибаюсь.
Внимательно прочитав drop_cache вызов, который я мог выполнить, чтобы удалить кеш, я решил попробовать пойти с этим, только чтобы получить следующее:
[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied
Итак, я не могу сбросить кеши, не могу создать файл подкачки, и я летаю довольно близко к солнцу с потреблением оперативной памяти (и я заработал несколько ожогов из-за mysqld вылетает).
Кто-нибудь знает, как это лучше разобраться?
Если я собираюсь отказаться от своего VPS-провайдера, который меня сильно раздражает в последнее время, мне нужно твердое доказательство того, что я не неверно интерпретирую данные о производительности или, что еще хуже, этот законный процесс фактически потребляет столько оперативной памяти.
Большое спасибо!
Я запустил virt-what и получил openvz
/var/log/messages-20161009:Oct 2 16:43:43 XXXYYYZZZ kernel: [56050139.271683] Out of memory in UB 23992: OOM killed process 22029 (mysqld) score 0 vm:5044284kB, rss:656944kB, swap:8280kB
/var/log/messages-20161009:Oct 2 16:43:55 XXXYYYZZZ kernel: [56050150.552528] Out of memory in UB 23992: OOM killed process 30486 (mysqld) score 0 vm:310088kB, rss:214456kB, swap:0kB
/var/log/messages-20161009:Oct 5 12:56:17 XXXYYYZZZ kernel: [56295842.893210] Out of memory in UB 23992: OOM killed process 13284 (mysqld) score 0 vm:5066092kB, rss:694760kB, swap:40kB
/var/log/messages-20161023:Oct 22 17:54:09 XXXYYYZZZ kernel: [1219419.032263] Out of memory in UB 23992: OOM killed process 789 (mysqld) score 0 vm:5057832kB, rss:698980kB, swap:0kB
/var/log/messages-20161023:Oct 22 17:54:20 XXXYYYZZZ kernel: [1219428.340161] Out of memory in UB 23992: OOM killed process 21700 (mysqld) score 0 vm:310088kB, rss:271892kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:14:47 XXXYYYZZZ kernel: [1804212.497098] Out of memory in UB 23992: OOM killed process 25691 (mysqld) score 0 vm:5057548kB, rss:690164kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:15:06 XXXYYYZZZ kernel: [1804222.381820] Out of memory in UB 23992: OOM killed process 23659 (mysqld) score 0 vm:310088kB, rss:248376kB, swap:0kB
Во-первых, если вы не проводите какое-то тестирование ты никогда не нужно сбрасывать кеши. Ядро Linux использует «свободную» память для кешей. Если что-то запрашивает память и она недоступна в другом месте, запрос будет удовлетворен из кэш-памяти.
Чтобы начать решать вашу проблему, вам следует заглянуть в свои журналы. Они должны содержать информацию из системы OOM о том, почему она не работает и что она сделала.
Как предполагали другие, похоже, что вы можете использовать контейнерный VPS (openvz и т. Д.). Если это так, вполне вероятно, что ваше единственное реальное решение - перейти на другой VPS, который использует другую технологию виртуализации, например. KVM и т. Д.
Ошибка, которую вы получили
[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied
Включен ли результат noclobber (man bash и поиск> |). Попробуйте вот так
sync; echo 3 >| /proc/sys/vm/drop_caches
И кстати - можно попробовать начать с этого
sync; echo 2 >| /proc/sys/vm/drop_caches
Вы также можете увидеть вывод команды slabtop, чтобы узнать, что ест вашего барана. Не то чтобы это сильно поможет, но вы, по крайней мере, будете знать, исходит ли он из какого-то блочного кеша или нет.
Также установите пакет sysstat и включите sar с разрешением в 1 минуту, чтобы вы могли анализировать производительность вашей системы исторически, а не отслеживать онлайн в реальном времени.