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

Тайм-аут административных страниц WordPress или 30 секунд для загрузки в Elastic Beanstalk, PHP 5.6, Apache, RDS и CloudFlare

Недавно я перенес веб-сайт WordPress, унаследованный мной от Rackspace, на AWS, и у меня сильно упала производительность. Я новичок в DevOps, поэтому не знаю, с чего начать.

Эта проблема:

После того, как я укажу DNS (Cloudflare) с нашего старого сервера на новый, WordPress (особенно в разделе администратора) ненадолго найдется. Но через час или около того страница администратора загружает тайм-аут или загружается до 30 секунд. Я еще не протестировал все страницы, но похоже, что это происходит на страницах с редакторами, так что «новая публикация» или редактирование страницы. Когда время ожидания страницы истекает, я вижу сообщение об истечении времени ожидания Cloudflare.

Я должен отметить, что я делаю это переключение около 11 вечера, никто, кроме меня, не должен входить в систему, а веб-трафик составляет около 150 пользователей.

Я также заметил, что наш экземпляр RDS начинает загружать ЦП на 100%, а количество подключений к БД резко увеличивается примерно до 1000.

Поскольку RDS ХОРОШО превзошел предел max_connections, WordPress больше не может подключаться к базе данных, и теперь передняя часть сайта показывает сообщение «Не удается установить соединение с базой данных».

На этом этапе я мог бы перезапустить свои экземпляры ECV2, но база данных RDS все еще сортирует 1000 подключений.

Я также заметил, что это кажется (классический) Elastic Load Balancer перестает равномерно распределять трафик между обоими экземплярами.

Я попробую еще раз в эти выходные, но что мне искать в журналах? Перед тем, как инстансы EC2 отключились, я просмотрел журналы и увидел следующее:

pid 17186:tid 139743773734656] (70007)The timeout specified has expired: [client 127.0.0.1:58604] AH01075: Error dispatching request to : (polling), referer: http://m.facebook.com

Обзор спецификаций:

Сервер - в AWS мы используем от 2 до 6 серверов m3.large EC2 с балансировкой нагрузки / автомасштабирования, управляемых Elastic Beanstalk (для интеграции с Github) и классическим балансировщиком нагрузки, Cloudflare используется для завершения DNS и SSL.

Мы используем Apache 2.4 с PHP 5.6 и PHP-FPM на 64-битной Amazon Linux / 2.7.1 AMI.

RDS - R3.Large запущена Aurora и часть кластера с запущенной репликой чтения. Пару дней назад я пробовал использовать R3 Large, и загрузка страницы администратора составляла 15-30 секунд… Все еще очень медленно.

Я также должен упомянуть, что RDS был настроен на нем, помимо Elastic Beanstalk. Я не думаю, что это должно иметь значение. Однако на этом сервере есть еще две базы данных для пары небольших сайтов, которые практически не получают трафика и скоро будут выведены из эксплуатации.

Я включил кеширование объектов через W3TC и добавил несколько правил Cloudflare для отключения производительности и приложений для / wp-admin * как рекомендуется здесь

Пара вещей, которые я прочитал в Интернете

ОК, я нашел ответ. Я познакомился с инструментом MyTop, который по сути является Top для запросов MYSQL. Благодаря этому инструменту я смог увидеть, что один запрос выполнялся тысячи и тысячи раз и в итоге просто заглушал все.

После того, как я идентифицировал запрос, я перешел на новую реликвию и, используя трассировку стека их базы данных, смог найти, в каком php-файле выполнялся код, который сделал запрос, и именно там я обнаружил цикл while, который вышел из-под контроля. Я не уверен, почему этот цикл не был проблемой на старом сервере, но я закомментировал этот код, и теперь AWS работает как мечта.

Похоже, у вас есть 2 отдельные проблемы:
1) Подключение занимает 30 секунд.
2) Превышение предела 1000 подключений для экземпляра db.r3.large RDS aurora, после которого истечет время ожидания новых подключений, так как php больше не может устанавливать новые сеансы с RDS.

1-й очень похож на проблему разрешения имен DNS. Проверьте, как настроены подключения к вашей базе данных (IP или полное доменное имя). Если это полное доменное имя - проверьте свой /etc/nsswitch.conf и проверьте свой облачный флэш-накопитель. Вы хотите убедиться, что прямое и обратное разрешение имен работает должным образом, и 30-секундная задержка не вызвана этим. Вы также можете выполнить tcpdump port 53, чтобы проверить, что происходит с разрешением имени.

Для 2-го нужно выяснить, почему количество подключений превышает 1000.
Если вы не используете RDS Aurora, какое у вас «нормальное» количество подключений? В зависимости от того, какая БД используется, будут разные запросы для проверки. Если обычно используется более 1000 подключений, вам придется соответствующим образом настроить свой экземпляр RDS (или перепроектировать приложение, возможно, вы используете плагин Word Press, который увеличивает это количество подключений).
Если в базе данных, отличной от RDS, количество подключений значительно меньше 1000 - тогда вам придется устранить причину этих дополнительных подключений.
Несколько ссылок для начала: