Mysql / php Connection, Config, Index, Query, buffers, nfi im out of options

Question

Прежде всего, мой главный вопрос:

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

Справочная информация: У меня есть система, которая обрабатывает несколько соединений с БД, так что я могу использовать небуферизованные запросы в главной таблице select. У меня возникла проблема, когда я вижу паузу в очень простом запросе (выберите идентификатор, имя, заголовок и т. Д. При работе с пределом неуникально-индексированного идентификатора 1), система затем либо вставляет, если запись не найдена, либо перезаписывает в качестве обновления .

Я вижу многосекундные паузы в этих запросах без каких-либо пауз при обработке одного и того же запроса между ними.

Индексы, которые могут быть повреждены или слишком долго обновляться (char (13)), небуферизованные или буферизованные, не имеют большого значения в этом точечном запросе.

Это происходит в нескольких таблицах (они создаются и выбрасываются после того, как прогон обработал их, существует около 30 различных копий, в которых задействованы несколько разные процессы, но данные сохраняются одинаково) в разное время при разных последовательных прогонах , временные интервалы ожидания тоже отличаются.

Кроме того, я смотрю на список процессов mysql и не вижу, что этот запрос ожидает, это заставляет меня поверить, что проблема переноса между php cli и mysql (та же коробка)

Извините, если это не имеет особого смысла - мой мозг сейчас совершенно обессилен и истощен.

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

Answer 1

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

Для меня это звучит просто как блокировка таблицы на таблицах движка MyISAM. Вы не упоминаете, на каком движке работают ваши столы. И каков ваш коэффициент вставки / обновления / выбора? Если у вас высокий уровень обновлений, использование кэша запросов MySQL может быть незначительным улучшением.

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

Не могли бы вы подробнее рассказать о вашем неуникальном индексируемом идентификаторе? ШОУ CREATE TABLE может быть полезным.

EDIT

Если вы уменьшили размер буфера и заметили улучшения, это говорит мне о том, что время, которое требуется для выделения памяти в вашем случае, может быть значительным. Если производительность запросов меньше 1 секунды, я бы начал изучать производительность системы, особенно памяти. Я предлагаю начинать с top, сортировать по памяти и отображать пространство подкачки и количество сбоев страниц. Или запустите vmstat и следите за активностью подкачки. Если вы видите большое время ожидания, вы можете ожидать пропускной способности диска. (Переход на innodb без изменения производительности интересен. Если бы у вас было мало оперативной памяти, я бы подумал, что ситуация с нехваткой памяти выдает себя быстрее.)

Это веб-приложение? Если да, существует ли корреляция между количеством соединений / потоков, соединений httpd и задержкой запросов? Я видел php baloon apache процессы от 35 МБ до 512 МБ и более, и впоследствии машина перешла бы в зону подкачки.

Возможно, у вас также есть проблемы с оборудованием. Всегда стоит потратить время на проверку dmesg на наличие сообщений ядра о проблемах с памятью или диском. В системе работает что-то еще? Будут ли у вас какие-либо задания cron, которые могут конкурировать за диск или память?