MySQL падает

[skurudo]

Проверил, проанализировал, оптимизировал, поремонтировал. Везде все ОК, на некоторые таблицы ругается - мол,

Code: Select all

note     : The storage engine for the table doesn't support (check / analyze / optimize / repair)

Неожиданно у плеска подробно описано это самое дело и как надо действовать:
https://kb.plesk.com/ru/6586
PS: Только обязательно, обязательно бэкапы перед этим самым.

[jser]

Бекап-восстановление я уже когда-то при подобных логах пробовал. Безрезультатно. Сервер определяет таблицы как неправильные только когда на него нападают глюки и он пытается перегрузиться. Потом, когда я запускаю его вручную, никаких нареканий от него не слышно.
Хотя когда попробовал сбекапить базы по первому способу, приведенному по Вашей ссылке, InnoDB все ждал запуска процесса в фоновом режиме и не дождался. В результате никакого бекапа всех баз не произошло. Но это всегда можно сделать средствами phpMyAdmin или Sypex Dumper. И восстановить базы можно таким же способом. При этом никаких недоразумений не происходит.

[skurudo]

Мне все-таки немного интересно, как оно так получается? Размер баз или насилие над ними какое совершается в процессе использования?

[jser]

Базы как базы, сверх-супер-гипер-размеров нет. Насилия никакого. Работает сервер. Вдруг начинает периодически падать. В логах о причинах такого его поведения - ничего. Разве что пишет, мол во время падения таблица такая-то была отмечена как крашнутая, нехудо бы ее проверить. Проверка не идет, поскольку сервер говорит, мол InnoDB ее не поддерживает. Можно выполнить рекомендации - сбекапить и восстановить базы. Пусть не через баш, пусть через PhpMyAdmin или SypexDumper - смысл действий и результат от этого не меняется. После какого-то раза заметил, что толку от этих бекапов-восстанослений никакого. Сервер как падал - так и падает, таблицы как работали - так и работают без каких-либо восстановлений. Причина не в них.
В настройках my.cnf я увеличил, насколько возможно, пул, кеши. Подействовало, особенно увеличение размера пула.
При пуле в 128 МБ добавление материалов в Joomla! было адовым занятием. 2-3 минуты раздумий, ошибка 500, а потом оказывается, что материал все же добавился. При пуле в 1,7-1,8 гигабайта материалы в Joomla! стали добавляться шустро и весело. Если увеличить до 2 Гб - сервер не заведется, скажет, мол не могу инициализировать такой пул. Это у меня на VDS под KVM с 4 Гб оперативной памяти и своп-файлом на SSD.
Если во время какой-то тяжелой операции с базой запустить atop, он покажет сильную и продолжительную перегрузку диска и свопа (тот же диск). Возможны кратковременные перегрузки оперативной памяти, но они бывают не слишком часто и не очень долго. Это наводит на мысль, что возможны проблемы с диском, который (физический) делят между собой несколько VDS. Hdparm говорит, что запись у меня идет со скоростью 2180.01 МБ/с, запись - 95.72 МБ/с. Вроде бы неплохо, хотя как для SSD - маловато будет.
Последнее, что добавил в my.cnf: innodb_file_format = barracuda. После этого вдруг все падения прекратились. Почему - до сих пор гадаю. Явилось ли это причиной - однозначно сказать не могу.
Upd.(10.03.2017) Однажды MySQL сервер упал, но теперь хотя бы можно было найти в логах причину. Ею оказалось ораничение на количество открытых файлов - 1024, в то время как серверу нужно было открыть 1051. Удивительная штука - в my.cnf записано open_files_limit = 65536

[pligin]

В последнее время постоянно начал падать MySQL.
Постоянно ошибки из-за нехватки памяти.
Также MySQL не стартует (иногда) при перезапуске сервера.
Раньше (год пользуюсь без проблем) такого никогда не было с любыми нагрузками.

[Deeryo]

Однажды MySQL сервер упал, но теперь хотя бы можно было найти в логах причину. Ею оказалось ораничение на количество открытых файлов - 1024, в то время как серверу нужно было открыть 1051. Удивительная штука - в my.cnf записано open_files_limit = 65536

Похоже проблема связана с systemd, который ломает старые шаблоны использования сервисов и всячески портит жись.
Можно починить так:

Code: Select all

#detect service name
SVCNAME=$(systemctl list-units  -t service | grep -iE "(mysql|mariadb).*\.service" | head -1 | awk '{print $1}')
mkdir -p /etc/systemd/system/$SVCNAME.d
echo '[Service]' > /etc/systemd/system/$SVCNAME.d/limits.conf
echo 'LimitNOFILE=65536' >> /etc/systemd/system/$SVCNAME.d/limits.conf
systemctl daemon-reload
systemctl restart $SVCNAME

Подробности https://ma.ttias.be/increase-open-files ... h-systemd/

[nikivanov]

Тоже заметил падения MariaDB 5.5 раз в 3-7 дней на установленной пару недель назад CentOS 7 из за нехватки памяти (на сервере 1 ГБ ОЗУ и 512 МБ swap). Monit поднимает Машку обратно, но ждать пока повредятся базы не хочется. Только что проделал рекомендации из предыдущего поста, наблюдаю дальше...

[skurudo]

nikivanov, иногда нужно просто добавить памяти :)

[jser]

Или чуть уменьшить пул.

[one]

Или чуть уменьшить пул.

Что за пул?