Сбой MySql 8 в цикле без конкретных ошибок и с достаточным объемом памяти

Я использую Ubuntu 20.04.03 с Mysql 8.0.27. Я несколько раз переустанавливал LAMP с нуля, и на данный момент у меня есть только 3 сайта WordPress, но я также протестировал только 1 и только 2 сайта. Увеличил оперативную память до 2 ГБ и своп до 3 ГБ.

Кажется, ничего не работает, потому что Mysql 8.0.27 продолжает падать, вызывая проблемы с подключением к базе данных на каждом сайте каждую ночь, даже если это совершенно новые сайты без трафика. Когда я редактирую сообщение или даже просматриваю любой из этих веб-сайтов, MySql снова падает. Иногда это даже не начинается с systemctl перезапустить mysql.

Журнал ошибок Apache не показывает ничего важного:

/usr/sbin/mysqld (mysqld 8.0.27-0ubuntu0.20.04.1), начиная с процесса 1524639

Инициализация InnoDB началась.

Инициализация InnoDB завершена.

Запуск аварийного восстановления XA... Аварийное восстановление XA завершено.

Устаревшая версия TLS TLSv1 включена для канала mysql_main.

Устаревшая версия TLS TLSv1.1 включена для канала mysql_main.

Сертификат ЦС ca.pem является самозаверяющим.

Канал mysql_main настроен на поддержку TLS. Для этого канала теперь поддерживаются зашифрованные соединения.

X Плагин готов к подключению. Адрес привязки: «127.0.0.1», порт: 33060, сокет: /var/run/mysqld/mysqlx.sock

Я уже проверил, что на самом деле конфиг загружает все версии TLS как приемлемые. Так что никакой реальной ошибки там нет.

журналctl -u mysql Последний журнал журнала:

28 января 10:29:37 www.ignicion.org systemd[1]: mysql.service: Ошибка с результатом «сигнал».
28 января, 10:29:37 www.ignicion.org systemd[1]: mysql.service: запланированное задание перезапуска, счетчик перезапусков равен 5.
28 января, 10:29:37 www.ignicion.org systemd[1]: сервер сообщества MySQL остановлен.
28 января 10:29:37 www.ignicion.org systemd[1]: Запуск MySQL Community Server...
28 января 10:29:43 www.ignicion.org systemd[1]: mysql.service: основной процесс завершен, код = убит, статус = 9/KILL
28 января, 10:29:43 www.ignicion.org systemd[1]: mysql.service: Ошибка с результатом «сигнал».
28 января, 10:29:43 www.ignicion.org systemd[1]: не удалось запустить MySQL Community Server.
28 января, 10:29:43 www.ignicion.org systemd[1]: mysql.service: запланированное задание перезапуска, счетчик перезапусков равен 6.
28 января 10:29:43 www.ignicion.org systemd[1]: сервер сообщества MySQL остановлен.
28 января 10:29:43 www.ignicion.org systemd[1]: Запуск MySQL Community Server...
28 января, 10:29:50 www.ignicion.org systemd[1]: запущен MySQL Community Server.

Я знаю, что это проблема с памятью, но почему? Не похоже, что сервер делает так много. Я отслеживаю процесс, и Mysql потребляет всю память. Эти же новые базы данных отлично работали на Ubuntu 18, поэтому у меня действительно нет идей, и я не могу найти решения связанных проблем, которые я нашел на форуме. Некоторые решения, которые я нашел, говорят о повреждении базы данных/таблицы, но это совершенно новые базы данных, и сбой оборудования был отклонен службой поддержки Digital Ocean.

буду признателен за любую информацию

Обновление №1 Нет резервного копирования или любой другой запланированной задачи. Это просто совершенно новая установка и новые базы данных. Это мой файл конфигурации в Ubuntu 20: /etc/mysql/mysql.conf.d

[mysqld]
пользователь = mysql
адрес привязки = 127.0.0.1
mysqlx-bind-адрес = 127.0.0.1
key_buffer_size = 16M
myisam-recover-options = РЕЗЕРВНАЯ КОПИЯ
log_error = /var/log/mysql/error.log
max_binlog_size = 100M
innodb_file_per_table = 1

И из моего файла журнала ядра (хвост -100 /var/log/kern.log) кажется, что Сигнал SIGKILL 9 Term Kill сигнал убивает mysql из-за слишком большого использования памяти

28 января 18:12:26 www ядро: [623011.971582] oom-kill:constraint=CONSTRAINT_NONE, 
nodemask= (null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task=mysqld,pid=1669785,uid=113

28 января 18:12:26 www ядро: [623011.971617] Недостаточно памяти: убитый процесс 166978 
5 (mysqld) total-vm: 720836kB, anon-rss: 292028kB, файл-rss: 804kB, shmem-rss: 0kB, 
UID:113 pgtables:816kB oom_score_adj:0

28 января 18:12:26 www ядро: [623012.005506] oom_reaper: собран процесс 1669785 (mysqld), теперь anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

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

ОБНОВЛЕНИЕ №2 кот /proc/meminfo

Общий объем памяти: 2030808 КБ
МемСвободно: 54016 КБ
Доступно: 3424 КБ
Буферы: 240 КБ
Кэшировано: 285620 КБ
SwapCached: 44532 КБ
Активный: 1188660 КБ
Неактивно: 495868 КБ
Активный(анон): 1187984 КБ
Неактивный (анон): 495088 КБ
Активный (файл): 676 КБ
Неактивный(файл): 780 КБ
Неизбежный: 19120 КБ
Заблокировано: 19120 КБ
SwapTotal: 3145724 КБ
SwapFree: 0 КБ
Грязный: 0 КБ
Обратная запись: 0 КБ
Страницы: 1383352 КБ
Нанесено на карту: 284872 КБ
Шмем: 276064 КБ
KReclaimable: 47968 КБ
Слэб: 171388 КБ
SReclaimable: 47968 КБ
SUnreclaim: 123420 КБ
Стек ядра: 7744 КБ
Таблицы страниц: 59832 КБ
NFS_Unstable: 0 КБ
Отказ: 0 КБ
WritebackTmp: 0 КБ
Предел фиксации: 4161128 КБ
Committed_AS: 9186644 КБ
VmallocTotal: 34359738367 КБ
VmallocUsed: 16512 КБ
VmallocChunk: 0 КБ
Процессор: 1808 КБ
HardwareCorrupted: 0 kB
AnonHugePages: 0 кБ
Страниц ShmemHuge: 0 kB
ShmemPmdMapped: 0 КБ
FileHugePages: 0 КБ
FilePmdMapped: 0 КБ
CmaВсего: 0 КБ
CmaFree: 0 КБ
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Огромный размер страницы: 2048 КБ
Hugetlb: 0 КБ
DirectMap4k: 1335276 КБ
DirectMap2M: 761856 КБ

ps -aux --sort -rss|head -5

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mysql 1715614 6,7 18,8 1763392 383344 ? SSL 22:21 0:01 /usr/sbin/mysqld
aceitep+ 1686006 0,0 2,0 342620 41076 ? С 19:44 0:02 /bin/php-cgi7.4
aceitep+ 1686009 0,0 1,9 265576 39268 ? С 19:44 0:02 /bin/php-cgi7.4
aceitep+ 1686001 0,0 1,8 342152 38348 ? С 19:44 0:04 /bin/php-cgi7.4

И поскольку я думал, что это связано с некоторыми переменными mysql, я запустил MySql Tunner, и это была рекомендация:

Переменные для настройки:
    innodb_buffer_pool_size (>= 391,3M), если возможно.
    innodb_log_file_size должен быть (= 16M), если это возможно, поэтому общий размер файлов журнала InnoDB равен 25% размера буферного пула.

Так что я буду тестировать, чтобы увеличить это и опубликовать результаты.

ОБНОВЛЕНИЕ №3 Добавлен innodb_buffer_pool_size = 512M к моему /etc/mysql/mysql.conf.d/mysqld.cnf файл и все еще сбой. Логи все те же. :(

Это нормально, что моя общая большая память, выделенная равной нулю, когда я запускаю Show Статус движка InnoDB;

----------------------
БУФЕРНЫЙ ПУЛ И ПАМЯТЬ
----------------------
**Общая большая выделенная память 0**
Словарной памяти выделено 1009720
Размер буферного пула 32765
Бесплатные буферы 29298
Страниц базы данных 3405
Старые страницы базы данных 1276
Модифицированные страницы БД 0

А как насчет того, когда я запускаю шоу переменные типа 'innodb_%';

innodb_buffer_pool_size | 536870912
innodb_change_buffer_max_size | 25

Почему размер буферного пула не совпадает и что это innodb_change_buffer_max_size значит? Какие еще переменные я должен проверить? Еще раз спасибо ребята

хорошо. Решено сейчас. Не существует конкретного решения для такого поведения, поскольку ядро ​​​​убивает mysql из-за использования слишком большого количества оперативной памяти, и когда вы пытаетесь найти причину, конкретных причин нет. Так что единственное, что вы можете сделать, это попытаться поиграть с переменными и много тестировать. Что я узнал:

• По моему короткому опыту, я не знал, что файл конфигурации Myslq (/etc/mysql/mysql.conf.d/mysqlconf.d в Ubuntu 20.04) не показывает много переменных, поскольку эти переменные установлены по умолчанию, поэтому, если мы хотите установить другое значение, мы должны вручную добавить каждую переменную в файл конфигурации.

• Установите и запустите тюнер mysql (погуглите), чтобы он мог указать, с чего начать для ваших конкретных настроек. В моем случае было предложено увеличить innodb_buffer_pool_size. И что innodb_log_file_size должен быть равен 25% от значения innodb_buffer_pool_size для оптимальной производительности. например, innodb_buffer_pool_size = 1 ГБ innodb_log_file_size = 0,25 ГБ

• Я установил innodb_buffer_pool_size = 512M, так как у меня 2 ГБ ОЗУ. Это просто заставило сервер продержаться немного дольше, прежде чем снова рухнуть. Вот с чего вам нужно начать, чтобы узнать больше о каждой переменной Mysql и выполнить расчеты в зависимости от размера вашей базы данных.

Вот мой окончательный файл конфигурации Mysql, так что вы можете попробовать эту конфигурацию. Просто знайте, что размер моей базы данных на данный момент составляет 394 МБ:

[mysqld]
пропустить лог-бин
пользователь = mysql
адрес привязки = 127.0.0.1
mysqlx-bind-адрес = 127.0.0.1
myisam-recover-options = РЕЗЕРВНАЯ КОПИЯ
log_error = /var/log/mysql/error.log
общий_журнал = вкл.
general_log_file=/var/log/mysql/general.log

key_buffer_size = 1M
max_allowed_packet = 1M
thread_stack = 200 КБ
thread_cache_size = 8
max_connect_errors = 100
макс_подключения = 100
#table_cache = 64
#thread_concurrency = 30
binlog_cache_size = 1M
net_buffer_length = 1M

default_storage_engine = InnoDB
innodb_buffer_pool_instances = 1 # Использовать 1 экземпляр на 1 ГБ размера пула InnoDB
innodb_buffer_pool_size = 400M # Использовать до 70-80% оперативной памяти
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 16M
innodb_log_file_size = 16M
innodb_stats_on_metadata = 0
#innodb_thread_concurrency = 0
innodb_read_io_threads = 40
innodb_write_io_threads = 40
innodb_buffer_pool_chunk_size = 10
innodb_lock_wait_timeout = 600
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 3000
innodb_io_capacity_max = 4000
innodb_buffer_pool_dump_pct = 80
innodb_flush_neighbors = 0
innodb_doublewrite = 0
innodb_change_buffer_max_size = 10
innodb_old_blocks_pct = 70
innodb_old_blocks_time = 5000
innodb_use_native_aio = ВКЛ.

# Количество секунд, в течение которых сервер ожидает активности в интерактивном соединении, прежде чем закрыть его.
интерактивный_таймаут = 600

# Количество секунд, в течение которых сервер ожидает активности в неинтерактивном соединении, прежде чем закрыть его.
время_ожидания = 600
net_read_timeout = 300
net_write_timeout = 300
connect_timeout = 1800

# Настройки стола
table_definition_cache = 1 КБ
table_open_cache = 2 КБ
table_open_cache = 2 КБ
open_files_limit = 4000

max_heap_table_size = 100M
tmp_table_size = 100M

#
# * Конфигурация кэша запросов
#
#query_cache_limit = 1M
#query_cache_size = 100M
#query_cache_size = 0
#query_cache_type = 0



# Настройки буфера
join_buffer_size = 256 КБ
read_buffer_size = 256 КБ
read_rnd_buffer_size = 256 КБ
sort_buffer_size = 128 КБ
представление_схемы = ВКЛ.

Если размер моих баз данных со временем увеличится (а они обязательно будут), мне придется увеличить эти значения:

key_buffer_size = 1M
макс_подключения = 100
innodb_buffer_pool_size = 400M
join_buffer_size = 256 КБ
read_buffer_size = 256 КБ
read_rnd_buffer_size = 256 КБ
sort_buffer_size = 128 КБ

Я мог бы увеличить innodb_buffer_pool_size до 1 Гб, но это будет означать, что мне придется уменьшить другие переменные и снова протестировать, чтобы проверить наилучшие настройки производительности. (как я уже сказал, если вы не знаете, необходимо много исследований об этих переменных) С другой стороны, я мог бы просто оставить эти же значения, даже если мои базы данных со временем увеличиваются, но Mysql начнет занимать больше памяти Swamp, поэтому запросы со временем будут немного медленнее.

И опять же, вы можете просто увеличить оперативную память на своем сервере, если можете себе это позволить.

Надеюсь, это поможет кому-нибудь.У меня нет опыта, поэтому я также публикую эти ответы для справки о будущем :)