Форум MySQL

Что можно предпринять для повышения стабильности работы базы?
Интересно, что не всегда даже перезапуск демона помогает.
Часто всю систему приходится перезапускать.

В логах что-то интересно есть? Активность мониторится, что этому способствует, может спящих соединений много?

>В логах что-то интересно есть? Активность мониторится, что этому способствует, может спящих соединений много?

Спящих соединений 7 штук.
(Возможно, это много, так как у меня выставлены довольно скромные величины для, например, количество одновременных соединений=10). MySQL работает на домашнем компьютере под XP и соединяет несколько процессов (процессов на данный момент 2, планирую, когда добюсь устойчивости, запускать 7-9 процессов, каждую секунду обращающихся к БД)

А логи где смотреть?
Почему-то не нашёл упоминания лог-файла ни в каких конфигах...

А со спящими соединениями что делать?
Удалять?

Хм... в общем-то не много, но учитывая, что у вас только 10 одновременно открытых, то на все остальные запросы остается 3 соединения. 7 - это не много, 10 - очень мало, почему была выбрана именно эта цифра? Однако к падению это бы не должно приводить, максимум СУБД бы отбрасывала все остальные запросы. А как долго спят эти 7 соединений?

С логами в MySQL сложнее (он бинарный), лучше всего включить лог медленных запросов через my.ini

Спящие запросы пока не трогайте, лучше разобраться что это за запросы, а вот количество одновременных бы соединений лучше чуть-чуть увелчить.

почему была выбрана именно эта цифра?
Я подсчитал сколько у меня процессов может одновременно обратиться к базе, да и поставил. Увеличу.

как долго спят эти 7 соединений?
1758 чего-то
>С логами в MySQL сложнее (он бинарный), лучше всего включить лог медленных запросов через my.ini

Нажимая на кнопку списка процессов, я заметил какие из запросов долго задерживаются, и даже добавил один индекс.

А как включить?
>
>Спящие запросы пока не трогайте, лучше разобраться что это за запросы, а вот количество одновременных бы соединений лучше чуть-чуть увелчить.

max_connections=100 - теперь так.

Есть ещё одна проблема.
Самый сложный трёхтабличный INSERT SELECT периодически (довольно часто) помечается как **DEAD** и выбрасывается из списка процессов, не заполнив таблицу.
Но не слишком редко он успешно завершается, где-то через раз.

Как это исправить?

>Я подсчитал сколько у меня процессов может одновременно обратиться к базе, да и поставил.
>Увеличу.
А как посчитали, это довольно трудно прогнозировать, особенно, если у вас есть множество клиентов, обращающихся к Web-сервису?

>Есть ещё одна проблема.
Он как выполняется, можно посмотреть, с какой ошибкой он завершается? Это из PHP или его выполнение осуществляется какими-то другими средствами?

>А как посчитали, это довольно трудно прогнозировать, особенно, если у вас есть множество клиентов, обращающихся к Web-сервису?
В данном случае я налаживаю не WEB-сервис, а приложение для личных нужд на домашнем компьютере. (выше уже писал)

>
>>Есть ещё одна проблема.
>Он как выполняется, можно посмотреть, с какой ошибкой он завершается? Это из PHP или его выполнение осуществляется какими-то другими средствами?

Да, данный запрос из РНР идёт.
Сам РНР запускается через Kernel32.dll так что посмотреть какая там ошибка через Mysql_error() у меня не очень получается (надо перепиывать классы для MySQL).

Если иначе посмотреть ошибку нельзя, то перепишу, конечно.

Можно ли как-то вывести в лог тексты запросов, которые были помечены как **DEAD** ?
Может, там тексты не такие, как я думаю. (А в списке процессов только начало запроса видно)

Ешё
Текущее количество "грязных" страниц 128 - подсвечивается красным

Количество последовательных запросов, которые InnoDB не смог выполнить из буферного пула и использовал постраничное чтение 8.7к - тоже краное

Это где? В phpMyAdmin?

>Это где? В phpMyAdmin?
Да

У вас просто маленькая нагрузка на MySQL - не обращайте внимание, если пользуетесь в домашних условиях, вам просто не разогнать MySQL полностью, так как она спроектирована для обслуживания большого количества клиентов.

>У вас просто маленькая нагрузка на MySQL - не обращайте внимание, если пользуетесь в домашних условиях, вам просто не разогнать MySQL полностью, так как она спроектирована для обслуживания большого количества клиентов.

На что не обращить внимания? На то что она падает 2-3 раза в день?
Насчёт малой нагрузки - спорно.
Клиентов мало, но таблицы большие и запросы сложные.
В частности, мне пришлось увеличивать long_quiry до 30 секунд, чтобы работало.

Примерно половину времени клиенты ждут обработки их запросов базой.
Это ещё можно стерпеть, но вот выяснить чего она падает часто - было бы важно.

Я просто привожу вам возможные причины, котрые так или иначе бросаются в глаза.
А вообще, понятия не имею куда дальше копать.

Я бы посмотрел журнал, но как это сделать?

Все запросы можно ускорить, если прилагать усилия, настраивать СУБД, формировать структуру данных, заточенную под скорость, вводить ключи. Когда клиенты чего-то ждут - это нормально только лишь в начале работы сервиса, затем нужно добиваться того, чтобы ожидания не было.

Вообще, то что база данных падает - это странно. Если не сложно сообщите версию сервера и операционную систему. Логи нам тут не сильно помогут, там скорее всего ничего ценного не будет, однако в стоит посмотреть в каталоге данных файл с расширением .err - возможно там есть что-то интересное (это лог ошибок).

В логах в основном вот такие сообщения:

InnoDB: Could not create a Windows event semaphore; Windows error 1816 InnoDB: Could not create a Windows event semaphore; Windows error 1816

версия 5.0.51а-community

Операционная система WINDOWS XP SP2

Увеличив размер пула, я существенно снизил время ожидания клиентов, но когда объём базы доходит до 400М, время ожидания снова становится значительным. К сожалению, самые сложные запросы с группировками идут именно к самым большим таблицам. Это не изменить.

Ставьте третий сервис-пак, на втором сервис-паке нельзя сейчас сидеть в том числе и потому, что очень сильно изменился состав Windows API (много новых удобных функций, которые сами в руки просятся). Вы таких сбоев в других программах будете получать все больше и больше.

PS Не факт, конечно, что дело именно в этом, но попробовать стоит.

>Ставьте третий сервис-пак, на втором сервис-паке нельзя сейчас сидеть

Данная версия MySQL была создана ранее 3-го пака, поэтому как-то не верится, что 3-й пак её излечит.

Кстати, падение MySQL выглядит слкдующим образом:
База просто перестаёт отвечать на запросы, но таблицы после перезагрузки системы целы.

>PS Не факт, конечно, что дело именно в этом, но попробовать стоит.
Кажется, я нашёл, почему MySQL падал.
У меня время от времени запрос на пересечение больших таблиц с группировкой посылался, примерно раз в 20 минут, а выполнялся он около 5-10 минут.

Но иногда, не успев закончить с одним запросом MySQL получал аналогичный, вытесняя из оперативной памяти на диск система начинала тормозить, и подходило время обрабатывать 3-й запрос. В результате объём памяти задействованный MySQL уходил за разумные пределы.

Пока я отрегулировал время между запросами, - и падения прекратились.
Но это не совсем удовлетворительное решение так как загрузка компьютера может сильно различаться и даже простые запросы могут исполняться долго, поэтому ориентироваться просто на время - ненадёжно.

Как-то бы сделать, чтобы MySQL сам отслеживал эту проблему и отклонял запрос...

Опишите, если не сложно, не секретно, подробнее запрос, что он делает? Есть несколько механизмов для ограничения активности, но это для того, чтобы их задействовать нужно знать больше о запросе.

>Опишите, если не сложно, не секретно, подробнее запрос, что он делает? Есть несколько механизмов для ограничения активности, но это для того, чтобы их задействовать нужно знать больше о запросе.

Вы имеете в виду длинный запрос на пересечение больших таблиц?

Я его переделывл пару раз, но сейчас пересекаю 3 таблицы: points, results, pointsdata

Смысл в том, чтобы выбрать лучшие точки из таблицы points, по оценкам этих точек results (связаны ключом), группирую по точкам и через HAVING отсекаю явно лишнее, потом остальное сортирую и сокращаю уже через LIMIT, затем пишу оставшееся в таблицу, к которой идут уже существенно более частые обращения.

Потом пришлось ещё добавить связь с pointsdata, чтобы исключить возникающую несмотря на все мои усилия несогласованность таблиц, когда точка есть, а её координаты неизвестны, но содержимое pointsdata никак в этом запросе не используется, только наличие точки в индексе.

Вот и весь запрос (INSERT ... SELECT) примерно 50 строк

Вообще-то я ещё планирую поработать над этим запросом.
В частности, мне надо выбирать только те точки в таблице results для которых стоит флаг success, если есть хотя бы один results c иным флагом, то эту точку надо как можно раньше из обработки отбросить, я пока не придумал как.

Лучшее, что приходит в голову - это делать GROUP_CONCAT по полю флага и потом анализировать строковыми функциями на этапе HAVING

Есть несколько механизмов для ограничения активности, но это для того, чтобы их задействовать нужно знать больше о запросе.
Выше я описал запрос.
Вы можете что-то посоветовать?