В php
приложение MySQL
иногда становится медленнее. Когда я перезапускаю службу MySQL, то она работает нормально.
Вот некоторые ключевые конфигурации, которые я сделал в my.cnf
файл:
skip-external-locking
skip-name-resolve
Я тоже включил и проверил slow query logs
, Там нет ничего, так как это прерывистый проблема.
Все пользователи связаны с IP-адресом сервера.
MySQL Tunner Предложение:
——— Показатели эффективности ——————————————
[-] В течение: 19 ч. 23 м. 22 с. (5K q [0,072 qps], 1K conn, TX: 2M, RX: 606K) [-] Чтение / запись: 99% / 1% [-] Двоичная регистрация отключена [-] Всего буферов: 1.1G глобально + 2.7M на поток (максимум 5000 потоков) [OK] Максимально допустимое использование памяти: 1,1 ГБ (32,15% от установленной оперативной памяти) [!!] Максимально возможное использование памяти: 14,2 ГБ (422,17% от установленной ОЗУ) [OK] Медленные запросы: 0% (0 / 5K) [OK] Максимальное использование доступных соединений: 0% (4/5000) [!!] Прерванные соединения: 4,72% (89/1886) [!!] Кеш запросов отключен [OK] Сортировки, требующие временных таблиц: 0% (0 временных сортировок / 92 сортировки) [!!] Временные таблицы, созданные на диске: 70% (608 на диске / 868 всего) [OK] Частота попаданий в кэш потоков: 99% (4 созданных / 1K подключений) [OK] Частота попаданий в кеш таблиц: 95% (открыто 166, открыто 173) [OK] Используемый лимит открытого файла: 0% (76 / 25K) [OK] Столовые блокировки получены немедленно: 100% (2K немедленные / 2K блокировки)Дайте мне знать, если вам нужно больше информации для решения этой проблемы.
Проверьте Mysql Log первый
И, возможно, вы находитесь в 75% ожидания системы, скорее всего, из-за тяжелой замены.
Расширенная команда EXPLAIN показывает подробности о ваших запросах, когда вы не знаете, что происходит http://dev.mysql.com/doc/refman/5.0/en/explain-extended.html
Используйте Query Cache http://dev.mysql.com/doc/refman/5.1/en/query-cache-configuration.html
Убедитесь, что параметры файла конфигурации сервера MySQL оптимизированы в соответствии с вашим оборудованием http://dev.mysql.com/doc/refman/5.5/en/option-files.html
Убедитесь, что вы используете оптимизированные типы данных при создании структуры таблицы. Например, поля «Комментарии» имеют размер 256 символов, ответьте на MYSQL с полем с типом VARCHAR (256) вместо использования TEXT. Запрос будет намного быстрее.
Это:
[--] Total buffers: 1.1G global + 2.7M per thread (5000 max threads)
С этим связано:
[!!] Maximum possible memory usage: 14.2G (422.17% of installed RAM)
Что плохо, потому что, как только вы начинаете использовать больше оперативной памяти, чем у вас есть в вашей системе, вы начинаете переключаться на диск, и производительность снижается, резко.
Для этого нет веских причин:
[!!] Query cache is disabled
Проверка использования памяти может помочь решить эту проблему:
[!!] Temporary tables created on disk: 70% (608 on disk / 868 total)
При использовании INNODB общая производительность СУБД зависит от множества конфигураций (в my.ini), и их настройка является экспериментальной работой, которая зависит от широкого спектра факторов, от физических возможностей до индексации таблиц для присоединения или даже сортировки запросов.
В общем, я думаю, что наиболее важным свойством конфигурации INNODB является innodb_buffer_pool_size
InnoDB, в отличие от MyISAM, использует буферный пул для кэширования как индексов, так и данных строк. Чем больше это значение, тем меньше дискового ввода-вывода необходимо для доступа к данным в таблицах. На выделенном сервере базы данных вы можете установить этот параметр до 80% от объема физической памяти машины. Не устанавливайте его слишком большим, поскольку конкуренция за физическую память может вызвать подкачку в операционной системе.
Если ваша база данных выросла в последнее время и innodb_buffer_pool_size
мал, это будет первая точка подозрения. Конечно, изменение этого свойства (обычно с некоторыми другими параметрами, такими как innodb_log_file_size
) это боль, потому что вы должны сбросить и восстановить все ваши данные.
Если это не сработало, то вам следует подумать о других возможностях, что не так просто.
max_connections = 100 — не 5000
long_query_time = 1 — сделать медленный журнал более удобным
Держите медленный журнал на
оставить кеш запросов выключенным
(608 на диске / 868 всего) -> СМОТРИТЕ на медленный журнал
Используйте pt-query-digest, чтобы найти «худший» запрос.