Поддержка WP Slow MySQL Queries

Это происходит с тысячами людей каждый день: по какой-то таинственной причине их веб-сайт может WordPress или Drupal сайт стал очень медленным за ночь (я имею в виду от 3 до 10 раз медленнее, чем обычно).

Административная область бэк-офиса загружается за несколько секунд (более 2 секунд начинает работать плохо), и все это становится болезненным для использования. В исключительных случаях вся страница может даже прерваться и вывести сообщение «невозможно обслуживать страницу», что является кошмаром для каждого веб-мастера.

После обращения в техподдержку вашей хостинг-компании технический специалист просматривает несколько файлов журнала и возвращается с ужасным ответом: «Я вижу некоторые медленные запросы в вашем Файл журнала медленных запросов MySQLПожалуйста, оптимизируйте ваше приложение ».

Читать: «Это твоя вина, исправь это», Но действительно ли ваш сайт вызывает это? Возможно, нет.

Основные предпосылки

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

Вот несколько простых шагов, которые могут помочь вам найти проблему самостоятельно:

1. Иметь четкую метрику производительности для мониторинга / улучшения:
   1. Количество SQL-запросов (16-80 идентификаторов в пределах нормального диапазона)
   2. Время генерации страницы (производительность php)
      1. время, необходимое серверу для создания страницы из базы данных и шаблона – в секундах. Обычно это меньше одной секунды, от 0,3 с до 0,7 с).
   3. Плагины как Статистика загрузки страницы WP или WP Super Cache вывод этой информации.
2. Попробуйте отключить плагиныначиная с наименее критических, и посмотрите, улучшатся ли показатели
3. Переключиться на одну из тем WordPress по умолчанию подобно TwentyFifteen, Я знаю, это отстой, если ты в производстве. Альтернативой является создание клона вашего сервера.
4. Важный: Если ваша загрузка ЦП очень высока или если ваш сервер находится под большой нагрузкой:
   1. Убедитесь, что у вас установлен и работает какой-то плагин кэширования (большинство людей могут установить и настроить WP Super Cache за несколько минут).
   2. Без кеширования даже ресурс с умеренной посещаемостью может быть загружен для ресурсов

Если нагрузка на сервер слишком велика, все показатели будут искажены или полностью неверны, поэтому работа детектива будет более сложной. Если у вас нет доступа к Статистика использования процессора Linuxпосмотрите на просмотры страниц вашего сайта в Статистика WordPress, Гугл Аналитика (у него есть статистика в реальном времени) или другой инструмент аналитики. Если вы видите несколько человек, просматривающих сайт, маловероятно, что вы потребляете много ресурсов – но это действительно зависит от конфигурации вашего сайта.

Вы можете клонировать сервер или масштабировать его настолько, чтобы получить некоторые данные, которые имеют смысл для целей отладки. Кроме того, найдите, что потребляет процессор, и сначала решите эту проблему.

Возможные причины медленных запросов MySQL

Важно признать, что это вполне может быть ошибка вашего сайта, и, следовательно, ваша вина. Вот закономерно медленный запрос (2,13 с), хотя все может быть намного хуже… попробуйте сами:

ВЫБРАТЬ SQL_NO_CACHE SQL_CALC_FOUND_ROWS wp_posts. * ОТ wp_posts ВНУТРЕННИЙ ПРИСОЕДИНИТЬСЯ wp_term_relationships НА(wp_posts.Я БЫ = wp_term_relationships.object_id) ВНУТРЕННИЙ ПРИСОЕДИНИТЬСЯ wp_term_taxonomy НА(wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id) ВНУТРЕННИЙ ПРИСОЕДИНИТЬСЯ wp_terms НА(wp_term_taxonomy.term_id = wp_terms.term_id) ГДЕ 1знак равно1 А ТАКЖЕ wp_term_taxonomy.taxonomy знак равно «Post_tag» А ТАКЖЕ wp_posts.post_type знак равно ‘после’ А ТАКЖЕ (wp_posts.post_status знак равно ‘публиковать’) GROUP ПО wp_posts.Я БЫ ПРИКАЗ ПОwp_posts.Дата публикации DESC ПРЕДЕЛ 0, 6

Причины могут включать в себя:

• Плагины с интенсивной базой данных, например связанные посты … ищите плагины, которые выполняются каждый раз, когда вы загружаете страницу
• Очень большая база данных (2+ миллиона строк)
• Очень большое количество запросов MySQL (сотни на страницу)
• Большое количество просмотров без кэширования (приводит к большому количеству запросов)
• Сочетание вышеперечисленного

При наличии многих служб общего хостинга база данных находится в другом «ящике», чем ящик Apache / PHP, поэтому проблемы с производительностью более изолированы. Если у тебя есть виртуальный частный сервер (VPS)MySQL и PHP могут находиться на одной машине. Это означает, что снижение производительности Apache / PHP также может повлиять на производительность MySQL. Это может усложнить изоляцию проблемы, поэтому следите за текущим использованием ЦП при проверке производительности запросов. Если процессор (или дисковый ввод-вывод) уже насыщен, это приведет к ложному срабатыванию

Но если вы ничего не изменили (может быть, произошло автоматическое обновление?) И если ваш сайт имеет относительно скромный размер (база данных меньше 200 МБ), вы можете не задушить ресурсы сервера базы данных, особенно если вы используете протестированное приложение, такое как WordPress, с простыми настройками и проверенными плагинами.

Существует несколько причин медленных запросов MySQL, не связанных с вашим веб-приложением:

• Аппаратная проблема с сервером MySQL
• Проблемы с подключением к серверу MySQL
• Ограниченное количество одновременных подключений MySQL (менее 10)
• Неадекватные настройки конфигурации на сервере MySQL
• Сетевая задержка между веб-сервером и сервером MySQL
• Совместно используемые ресурсы используются другим клиентом
• Медленное хранение на сервере
• И более…

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

Ваш запрос плохо спроектирован или это был случайный случай?

Давайте вернемся к нашему первоначальному ответу службы поддержки:

«Я вижу некоторые медленные запросы в вашем файле журнала медленных запросов MySQL, пожалуйста, оптимизируйте ваше приложение»,

Это просто: если ваш запрос медленный из-за его дизайна, то низкая производительность должна быть постоянной при каждом выполнении одного и того же запроса.

В течение многих лет, когда я запускал веб-сайты, я часто обнаруживал, что известные веб-приложения, такие как WordPress, работали достаточно хорошо из коробки (без плохих / медленных плагинов), и что очень маловероятно, что они будут генерировать ужасно медленные запросы, особенно для небольших сайтов с низким трафиком. На самом деле, многие из них по-прежнему очень хорошо работают с сайтами, у которых в базе данных более 100 000 страниц. Вы можете использовать плагин, такой как Монитор запросов увидеть, если

• Запрос выполняется для определенной медленной страницы
• Запрос выполняется так медленно, как подсказывает журнал

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

Если вы подозреваете, что производительность PHP отрицательно влияет на скорость запросов, вы можете дополнительно изолировать тестирование запросов, используя MySQL менеджер, такой как phpMyAdmin выполнить запрос вне среды PHP. Эта утилита часто предоставляется веб-хостами.

Вот как выглядит phpMyAdmin. Как видите, это довольно большая база данных

Запись: выполнять только запросы только для чтения, такие как ВЫБРАТЬ в целях отладки. Вы не хотите добавлять / удалять некоторую информацию … если вы не знаете, что делаете. Также, если вы беспокоитесь, что MySQL может кэшировать запросы, используйте ВЫБРАТЬ SQL_NO_CACHE принудительно отключить кеш для этого конкретного запроса (больше информации о команде no cache).

Зайдя в phpMyAdmin> База данных> SQL и воспроизведя медленный SQL-запрос из журнала, вы можете увидеть, является ли запрос действительно медленным каждый раз, или же медленный журнал только что записал исключительное событие, которое не является репрезентативным или реальной производительности.

Возможно также, что что-то еще, например, сетевое соединение между PHP и MySQL, влияет на производительность запросов в веб-приложении. Если вы подозреваете, что сеть медленная, обратитесь в службу поддержки для проверки связи с сервером MySQL. Время приличного ответа составляет от 0,5 мс до 2 мс.

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

Если воспроизведение запроса в phpMyAdmin последовательно дает намного более быстрое время запроса, чем то, что записал медленный журнал, то можно предположить, что сам запрос не является ошибочным и что проблема кроется в другом месте: вам не нужно менять код или «оптимизировать» запрос.

Этот запрос был помечен как «медленный» в журнале. Но на самом деле он выполняется быстро в 99,9% случаев. Ложная тревога

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

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

Медленный журнал MySQL может быть простым выходом (обвинить клиента, двигаться дальше). Когда-нибудь они правы. Много раз, они не. С небольшой методологией вы можете быстро проверить, действительно ли «медленный» запрос медленный или нет. Это сэкономило мне много времени (и денег!) При работе с медленными проблемами с базой данных.

Настройте производительность MySQL самостоятельно

Если у вас есть административный доступ к MySQL и вы хотите отредактировать файл конфигурации MySQL, вы можете установить MySQLTuner сценарий (есть также очень удобный Версия для Windows, которая может получить доступ к удаленному серверу MySQL что я использую). Это очень крутой инструмент, который проанализирует ваш текущий сервер MySQL и предложит некоторые изменения конфигурации, которые легко сделать (сделайте резервную копию вашего файла конфигурации перед внесением изменений!).

Вещи как размер кеша запросов (отличная статья о кеше запросов) и т. д.… может значительно улучшить производительность MySQL. Это не для всех, и далеко выходит за рамки этой статьи. Благодаря Пол Штраус для того, чтобы предложить это.

Вывод

Отладка проблем с производительностью сайта не всегда проста (обширный обзор на WordPress.org), особенно если у вас нет навыков администратора или видимости данных, необходимых для понимания того, что происходит, чтобы это исправить. Работа с поддержкой веб-хостинга B.S просто делает это намного сложнее.

Попутно вам, скорее всего, придется пройти (к сожалению) типичный сценарий поддержки, который будет «обвинять клиента», и вы будете наступать на несколько наземных мин, когда будете искать ответы. Если ваша техническая поддержка не делает этого, они великолепны, и вы должны быть рады работать с ними.

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

Если появится замечание «у вас медленные запросы», я надеюсь, что эта статья сэкономит ваше время и… здравомыслие. Удачи, и не стесняйтесь оставлять вопросы в комментариях.

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