mariadb oom-killer на CentOS8 в EC2 t2.micro instance
Похоже, у меня проблемы с памятью в моем экземпляре t2.micro (1 ГБ), на котором работают nginx, mariadb, php и WordPress.
Я вижу, что mariadb.service регулярно убивается (я использовал grep -e kill /var/log/messages пример вывода ниже). Как вы видите, mysqld убивает mariadb (разве это не самоубийство?).
Я пробовал различные твики и настройки для mariadb, но я думаю, что это больше общая проблема системы.
Я не смог определить, когда происходят "сбои". Я могу спокойно войти в админку WordPress, работать, а когда я переключаюсь на новую область (вызываю вызов базы данных), сайт зависает. SSH-соединения также зависают в то же время.
Неужели t2.micro просто недостаточно мощный?
Apr 9 11:22:32 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr 9 11:23:25 ip-172-31-20-68 kernel: mysqld invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr 9 11:23:25 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr 9 11:23:25 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=6383,uid=27
Apr 9 11:23:25 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr 9 11:27:04 ip-172-31-20-68 kernel: tuned invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr 9 11:27:04 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr 9 11:27:04 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=6483,uid=27
Apr 9 11:27:51 ip-172-31-20-68 NetworkManager[928]: <info> [1617967671.1410] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
Apr 9 11:27:51 ip-172-31-20-68 NetworkManager[928]: <info> [1617967671.1411] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Apr 9 12:04:48 ip-172-31-20-68 kernel: mysqld invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr 9 12:04:48 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr 9 12:04:48 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=1746,uid=27
Apr 9 12:04:48 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr 9 12:06:04 ip-172-31-20-68 kernel: tuned invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr 9 12:06:04 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr 9 12:06:04 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=dnf,pid=1982,uid=0
Apr 9 12:08:30 ip-172-31-20-68 kernel: php-fpm invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr 9 12:08:31 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr 9 12:08:31 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=2126,uid=27
Apr 9 12:08:31 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
OOM killer - это функция ядра, которая работает от имени процесса, выделяющего память в данный момент. Это может быть тот же процесс, который выбирается для уничтожения, чтобы освободить память.
Правила выбора обычно выбирают процесс с наибольшим отображением анонимной памяти (т.е. без учета файлов, отображенных на память) на физические страницы (т.е. без учета памяти, которая выгружена или в которую никогда не производилась запись).
Обычно можно настроить базы данных на использование меньшего объема памяти в ущерб производительности, и я также ожидаю, что стандартная настройка предполагает, что сервер базы данных является выделенной машиной и должен посвятить все свои ресурсы этой единственной задаче, а это не то, что вы делаете в данном случае.
Так что здесь есть несколько путей:
- запустить отдельную виртуальную машину, предназначенную для базы данных
- настроить параметры базы данных на использование меньшего объема памяти
- использовать более крупную виртуальную машину
Базы данных обычно хорошо адаптируются к тому объему памяти, который у вас есть, и используют его для кэшей, которые известны оптимизатору запросов и могут быть частью расчета стоимости (в отличие от дисковых кэшей на уровне ОС, которые непредсказуемы), поэтому либо ограничьте это значение до некоторого значения, которое оставляет достаточно места для другого ПО, либо убедитесь, что никакому другому ПО место не нужно.
Если этого все равно недостаточно, вам понадобится более крупная виртуальная машина.
Добавление пространства подкачки не поможет, потому что это делает время доступа к внутреннему кэшу базы данных непредсказуемым, так что база данных начнет создавать неоптимальные планы запросов, поскольку она предполагает, что данные находятся в кэше и доступ к копии в памяти будет быстрее, чем перезагрузка данных с диска - но пространство подкачки на ВМ, где вы платите за ввод-вывод, в любом случае не является хорошей идеей.