2017-02-16 4 views
3

Почему подключение к моей базе данных InnoDB часто задерживается на целое количество секунд?Подключение к базе данных MySQL медленное, занимает n секунд

Некоторого фон

У меня есть очень небольшая база данных MySQL, состоящая из таблицы "пользователей (150 записей) и 'связи' таблицы (растущих 150 * 150 записей). Таблицы и индексы составляют менее 5 МБ.

Когда пользователи активны, 5-50 записей в 'соединениях' меняются (вес изменен) или добавляются (если они еще не существовали). Все приложение работает плавно, а время загрузки меньше ~ 100 мс.

За исключением случаев, когда они не являются.

Детали

Под даже очень малых нагрузках, время загрузки страницы шип от 60 мс до где-то между 1000 мс и 10000 мс.

Использование профилировщика в Symfony, я мог бы задержать задержку на 95%% в операторе getRepository, тогда как запросы потребовали всего ~ 1 мс на запрос. Это заставило меня поверить, что подключение к базе данных было медленным действием. Я написал вспомогательный скрипт, регулярно подключающийся к базе данных для проверки этой теории.

<?php // call this script commandline using watch 
$a = microtime(true); 
$pdo = new PDO('mysql:host=127.0.0.1;dbname=mydb','myuser','mypass'); 
file_put_contents('performance.txt', (microtime(true)-$a).PHP_EOL, FILE_APPEND); 

Тайна

Подключение к базе данных последовательно принимал 1-3 мс, или 1,001-1,003 мс, или 2,001-2,003 мс, или 3,001-3,003 мс, и т.д. целое число суммы секунд, плюс нормальное время. Ничего между ними, например, 400 мс или 800 мс. После того, как запись не началась, соединение было сделано почти мгновенно. Как только некоторые записи были выполнены через приложение, были достигнуты более высокие номера.

В чем причина этого поведения? Кажется, что InnoDB page_cleaner выполняет свою работу каждые 1000 мс, может быть, это часть объяснения?

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

EDIT

По запросу the variables and global status.

Дополнительная информация: Я подключаюсь непосредственно к 127.0.0.1 (см. Фрагмент кода выше), и я проверил флаг разрешения пропуска имени без каких-либо последствий. Кстати, это сервер Debian.

РЕДАКТИРОВАТЬ 2

я обнаружил, что задержки были либо 1, 3, 7 или 15 секунд. Обратите внимание на шаблон: 1 секунду, + 2s, + 4s, + 8s. Это действительно выглядит как проблема с тайм-аутом ...

+1

Изменение к таблицам памяти, вероятно, не поможет, если проблема заключается связь, если я понимаю, вы выдаете правильно. Вещи, которые я подозревал бы: недостаточно потоков/(db) соединений, настроек пула соединений (только потому, что у нас была проблема с этим однажды :)) или что-то в этом роде. Соединение медленное, а не запрос. Может быть, посмотрите на экран «innotop», когда происходит медленность? если вы не видите каких-либо длинных запросов и более высокой нагрузки, возникает проблема с созданием подключений. – Nanne

+0

Не знаю о 'innotop', спасибо за отзыв. Нагрузка: 0,00, QPS: 10-20, Slow: 0, QCacheHit: 50%, KCacheHit: 100,00%. Кажется, что запрос действительно не проблема. – TacoV

+0

Я переключился на ПАМЯТЬ как тест. Неясная проблема задержки соединения сохраняется ... – TacoV

ответ

1

Общепринято, что обратный поиск dns занимает много времени. Наряду с размером host_cache это может привести к неустойчивому поведению.

Отключите его, добавив это к моему.cnf

[mysqld] 
skip-name-resolve 

Обратите внимание, что все гранты должны быть указаны ip, а не по имени, если вы измените это.

Существует более читать в manual

+0

Я уже добавил это к my.cnf, как показано в конфигурационном дампе («skip_name_resolve ON»). Проблема сохраняется. – TacoV

Смежные вопросы