Назад | Перейти на главную страницу

Высокая средняя нагрузка на сервер MySQL

Недавно мы столкнулись с серьезной проблемой производительности на нашем сервере MySQL. Сервер приложений и сервер базы данных разделены. На стороне сервера базы данных средняя нагрузка мгновенно увеличивается. Загрузка процессора тоже остается высокой (около 200%).

средняя нагрузка: 16,91, 21,48, 30,91

В конце приложения мы вручную закрыли соединения с базой данных, где бы они ни открывались вручную. my.cnf также немного настроен с использованием следующих параметров:

innodb_buffer_pool_size = 4G
query_cache_type        = 1
wait_timeout            = 1800

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 32

query_cache_limit       = 5M
query_cache_size        = 640M
query_cache_type        = 1

Но все равно видимых улучшений нет. Использование сервера по-прежнему очень велико. Что могло пойти не так с конфигурацией? Как поддерживать среднюю нагрузку на сервер в норме (или хотя бы близкой к норме)?

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

Вы можете собирать данные с помощью системных инструментов, таких как sar, free, iostat, vmstat и т. Д.

Установите мониторинг для сбора и отслеживания данных 1,2

Чтение ваших журналов также часто бывает полезным.

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

  1. Какую проблему вы пытаетесь решить?

Моя средняя загрузка необычно высока.1

  1. Итак, теперь мы знаем, какую реальную проблему решаем, и у нас есть направление. Давайте соберем некоторую информацию, которая поможет нам найти решение.

    • Связана ли проблема со временем? Происходит ли это регулярно или случайно.
    • Проверьте свои журналы, все журналы, а не только журналы конкретных служб, так как что-то еще может быть причиной проблемы. Записи журнала обычно имеют временные метки, это помогает вам коррелировать события между несколькими приложениями и службами - используйте их. При необходимости увеличьте и детальность журнала.
    • Следите за тем, что делает ваша система. Используйте такие инструменты, как top, vmstat, iostat, sar, ps, tcpdump или даже полноценный мониторинг.

  2. Проанализируйте собранную информацию. Что на самом деле происходит в системе, когда служба перестает отвечать? Каково состояние ресурсов системы?

  3. Примите соответствующие меры для исправления. Надеюсь, что происходит довольно очевидно, у вас заканчивается память и выходит OOM killer, ваша активность подкачки слишком высока, ваша очередь выполнения слишком длинная, вы привязаны к iobound и т. Д. Если это не очевидно, то вы ' Возможно, вы собираете неверные данные - вы знаете, что делать, вернитесь к пункту 2.

  4. Следите за тем, что делают изменения, внесенные в 4..

  5. Исправили ли изменения проблему? Это лучше? Это хуже? Нет разницы? Куда вы пойдете дальше, зависит от того, что вы найдете. Возможно, вам придется вернуться к 2. и собрать более подходящие данные или 3. повторно проанализировать, какие данные у вас есть, или 4. потому что вы определили ряд потенциальных решений.

  6. Задокументируйте свои выводы и внесенные изменения.