Запускайте Debian 12 на VPS с небольшим объемом оперативной памяти без сбоев, приводящих к ошибке нехватки памяти и отключению MySQL.

На VPS с небольшим объемом памяти можно запустить Debian 12 и базу данных, но стабильность зависит от всей рабочей нагрузки, а не только от настроенного кэша MySQL. Когда доступная память заканчивается, Linux может вызвать механизм завершения процессов (OOM killer), который завершает один из процессов для защиты остальной части системы. Если этим процессом является база данных, симптом может выглядеть как случайный сбой. Практическая цель состоит в предотвращении длительного дефицита памяти и подтверждении того, что именно завершило ядро; никакие параметры настройки не могут гарантировать, что события OOM никогда не произойдут.

В Debian 12 используется MySQL или MariaDB?

Проверьте сервер перед изменением его конфигурации. Debian 12 (Bookworm) использует MariaDB в качестве default-mysql-serverпакета по умолчанию; Oracle MySQL устанавливается отдельно. В информации о пакетах Debian MariaDB указана как зависимость сервера от этого метапакета. Выполните:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

Используйте приведенные ниже инструкции для MariaDB только в том случае, если установлена ​​служба MariaDB. Oracle MySQL во многих случаях использует похожие имена параметров, но структура пакетов, имена служб, доступные переменные и значения по умолчанию могут отличаться. Для получения информации о точно установленной версии MySQL обратитесь к руководству.

Основные источники: пакет default-mysql-server из Debian Bookworm и руководство по использованию памяти в MySQL 8.0 .

Как определить, что ошибка нехватки памяти (OOM) привела к сбою базы данных?

Сначала отличите ошибку нехватки памяти (OOM kill) ядра от ошибки базы данных, перезапуска службы, перезагрузки или проблемы с диском. В Debian journalctlпрочитайте журнал systemd. Найдите журнал текущей загрузки и изучите журнал службы MariaDB:

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

Если в логе ядра указано имя mariadbdили mysqldсообщение об ошибке нехватки памяти (OOM), это свидетельствует о принудительном завершении работы с памятью. Если соответствующей записи нет, проверьте собственный журнал ошибок службы, а также историю перезагрузок или мониторинга провайдера. Журналы могут быть недоступны после перезагрузки, если журналирование не является постоянным, а управляемый VPS-провайдер может предоставлять доступ только к части диагностических данных хоста.

Необходимо зафиксировать базовые показатели, когда сервер подвергается репрезентативному трафику, а не только в режиме ожидания:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

В таблице vmstatследите за столбцами siи soна предмет постоянной активности подкачки и выгрузки данных. Само по себе выделение ненулевого объема памяти для подкачки не является проблемой; продолжающаяся подкачка в сочетании с медленным временем отклика указывает на нехватку памяти. В документации Linux обработка ошибок нехватки памяти рассматривается как крайняя мера, когда память не может быть в достаточной мере освобождена. См. концепции управления памятью ядра Linux и руководство по journalctl в Debian .

Что следует измерить перед настройкой?

Записывайте общий объем оперативной памяти, текущее и пиковое использование файла подкачки, самые ресурсоемкие процессы, количество подключений к базе данных и обычную пиковую нагрузку веб-приложения. База данных использует общую память с Debian, веб-сервером, рабочими процессами приложения, агентами мониторинга и кэшем файловой системы. VPS также может иметь ограничение на объем памяти контейнера или cgroup, меньшее, чем физическая оперативная память хоста; размер кэша базы данных должен соответствовать ограничению памяти, доступному для сервиса, а не большему общему объему памяти хоста.

Для MariaDB проверьте текущие настройки, связанные с памятью, и пиковую нагрузку на соединения:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

Буферный пул InnoDB кэширует страницы таблиц и индексов. Ограничения на количество соединений и буферы запросов могут увеличивать потребность в памяти по мере роста количества одновременно выполняемых операций. Избегайте умножения каждого буфера для каждого соединения на значение, max_connectionsкак если бы каждый буфер всегда был полностью выделен, но рассматривайте очень высокий потолок количества соединений как риск при пиковых нагрузках. В руководстве по памяти MariaDB рекомендуется задавать размеры глобальных кэшей, буферов для каждого соединения и настроек механизма одновременно, и особо упоминаются пулы соединений приложений. Ознакомьтесь с руководством по выделению памяти MariaDB и руководством по обработке слишком большого количества соединений .

Как оптимизировать размер MariaDB на небольшом VPS?

Вносите изменения по одному, сохраняйте копию исходной конфигурации и проверяйте во время планового технического обслуживания, повлияет ли перезапуск на пользователей. В конфигурации MariaDB, поставляемой Debian, обычно содержатся файлы в каталоге `/etc/mdb` /etc/mysql/mariadb.conf.d/; перед редактированием проверьте активные каталоги `/etc/mdb` в вашей установке. Небольшой файл, который можно просто удалить, проще, чем заменять основной файл поставщика:

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

Для общего VPS с объемом оперативной памяти около 1 ГБ приведенный ниже пример является лишь осторожным начальным значением, а не универсальным безопасным профилем. Значения следует уменьшать или увеличивать в зависимости от измеренной пиковой нагрузки на память, размера базы данных, рабочей нагрузки, а также объема оперативной памяти, выделенной для операционной системы и приложений:

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB считывает настройки из файлов параметров при запуске; проверьте поддерживаемые вашей версией имена разделов и эффективные значения. Если этот файл не загружается, удалите встраиваемый модуль и проверьте журнал. Перезапуск базы данных прерывает существующие соединения, поэтому запланируйте его соответствующим образом:

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

Оцените результат, исходя из стабильности и качества обслуживания. Меньший размер буферного пула может уменьшить количество попаданий в кэш и увеличить количество операций чтения с диска. max_connectionsСлишком сильное уменьшение может, наоборот, привести к ошибкам «Слишком много соединений». Сравните Max_used_connectionsс настроенным лимитом и проверьте размеры пулов приложений, прежде чем снова изменять этот лимит. Если база данных по-прежнему завершает работу во время пиковой нагрузки или время отклика ухудшается из-за постоянного использования файла подкачки на диске, перейдите на больший объем оперативной памяти или отделите базу данных от приложения.

Может ли использование файла подкачки предотвратить сбой из-за нехватки памяти (OOM)?

Файл подкачки предоставляет Linux более медленное место для перемещения некоторых страниц памяти и может поглотить кратковременный пик. Он не добавляет быструю оперативную память, не устраняет утечки памяти и не делает VPS недостаточного размера пригодным для длительной рабочей нагрузки. Интенсивное использование файла подкачки может привести к зависанию как базы данных, так и приложения. Перед созданием VPS проверьте, поддерживает ли ваш провайдер файлы подкачки и достаточно ли на нем дискового пространства.

Если поддерживается, файл подкачки размером 1 ГиБ можно создать следующим образом. Отрегулируйте размер в соответствии с рекомендациями поставщика и доступным дисковым пространством и проверьте результат каждой команды:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Чтобы включить эту функцию после перезагрузки, добавьте эту запись, /etc/fstabпредварительно убедившись, что аналогичная запись еще не присутствует:

/swapfile none swap sw 0 0

Затем проверьте файл sudo findmnt --verify --verboseи убедитесь, что он присутствует в swapon --show. Если fallocateне поддерживается файловой системой или провайдер блокирует файл подкачки, остановите процесс и используйте поддерживаемую провайдером процедуру. Не отключайте OOM killer и не присваивайте MySQL экстремальный рейтинг защиты от OOM: это не создаст память и может подвергнуть остальной части небольшого VPS большему риску.

Как вы поняли, что изменения сработали?

Проведите наблюдение за VPS в течение как минимум одного обычного периода высокой нагрузки. Полезный результат будет иметь несколько признаков:

• В ходе выполнения рабочей нагрузки, которая ранее вызвала инцидент, новых записей об ошибке OOM-kill ядра не обнаружено.
• MariaDB остается активной, и количество перезапусков неожиданно не увеличивается.
• vmstat 1При обычном трафике не наблюдается непрерывной смены пакетов (swapin и swapout).
• Приложение продолжает быстро реагировать, а пиковые нагрузки на подключение к базе данных остаются ниже нового лимита без ошибок подключения.
• Резервное копирование завершено, и запросы к базе данных продолжают выполняться с соблюдением допустимой задержки приложения.

Не используйте «запуск службы» как единственный критерий успеха. Настройка, которая поддерживает работу MariaDB, но заставляет систему постоянно использовать файл подкачки, не решает основную проблему с производительностью. Аналогично, один спокойный день не подтвердит работоспособность ежемесячного импорта, резервного копирования, всплеска трафика или пакетного задания, которое еще не было выполнено.

Когда тюнинг перестаёт быть правильным решением?

Если после разумной настройки кэша и параллельного доступа сохраняется нехватка памяти, если активность подкачки сохраняется, задержка запросов становится неприемлемой или приложение постоянно превышает лимит подключений, выбирайте более мощный VPS или разносите рабочие нагрузки на разные серверы. Размер базы данных также имеет значение: слишком маленький буферный пул может предотвратить всплеск потребления памяти, но при этом сделать узким местом дисковый ввод-вывод. Если приложение и база данных имеют резкие, но предсказуемые пики, сначала определите, открывает ли приложение избыточное количество подключений или одновременно выполняет ресурсоемкие задачи.

При использовании Oracle MySQL вместо стандартной для Debian MariaDB, перед применением этих примеров проверьте имя службы, путь к файлу параметров и переменные памяти, сверив их с руководством пользователя соответствующего сервера. В любом случае, сохраняйте проверенные резервные копии и изменяйте переменные по одной. Надежный результат не гарантирует, что Linux никогда не вызовет обработку ошибки нехватки памяти (OOM); это свидетельствует о том, что VPS обладает достаточным запасом мощности для пиковой нагрузки и что MySQL или MariaDB больше не являются повторяющимися жертвами этой проблемы.

Дополнительные основные источники информации: руководство по устранению неполадок при запуске MariaDB , в котором отмечается, что серверу также требуется память для других механизмов, буферов для каждого соединения и операционной системы, а также справочное руководство MySQL 8.0 .