MySQL - Медленный запрос - таблица wp_options. Веб-сайт не может обрабатывать трафик
После нескольких дней исследований я разместил веб-сайт на экземпляре c1.medium, Amazon Linux и базу данных MySQL на экземпляре db.m1.instance. RDS работает под управлением MySQL версии 5.6.13. Я выделил 100 ГБ для инстанса БД и установил для предоставленного IOPS значение 1000. Веб-сайт основан на фотографиях, позволяет пользователям загружать материалы и в часы пик имеет более 400 посетителей.
Как только я включил медленное ведение журнала запросов, я обнаружил, что проблема связана с таблицей wp_options, которая при просмотре phpmyadmin, которую я обнаружил, содержит информацию о плагинах и теме WordPress. Пример:
УСТАНОВИТЬ временную метку = 1390186963;
ВЫБЕРИТЕ option_name, option_value FROM wp_options WHERE autoload = 'yes';
Время: 140120 3:04:17
Пользователь @ Хост: xxxx Id: 744
Query_time: 49.248039 Lock_time: 0.000180 Rows_sent: 485 Rows_examined: 538
После экспериментов с некоторыми параметрами БД я установил query_cache_type на 1 и query_cache_size на 64 МБ. Я надеялся, что включение кеширования остановит базу данных от повторного вызова таблицы wp_options, но, к сожалению, это не так. Какие-либо предложения? Что нужно сделать дальше, чтобы выяснить причину этой проблемы? Если посмотреть на показатели CloudWatch, кажется, что оборудования достаточно, а может и нет?
Ниже приведены скриншоты показателей CloudWatch для обоих экземпляров.
Query_time: 49.248039 Lock_time: 0.000180 Rows_sent: 485 Rows_examined: 538
Это из вашего журнала медленных запросов означает, что выполнение этого запроса заняло 49 секунд. Попробуйте бежать
CREATE INDEX wp_options_autoload ON wp_options (autoload);
А затем попробуйте снова загрузить свои страницы.
Хотя в таблице всего 538 строк, это чрезвычайно долгое время для выполнения этого запроса.
вы можете изменить wp_options на тип MEMORY. Для этого вам нужно преобразовать любой blob-объект в большой varchar и увеличить размер кучи в RDS.
Однако может быть более разумным решить эту проблему, поставив сервер кеширования перед WordPress, чтобы исключить запросы.
1000 IOPS - это очень много ресурсов.
IOPS интересны, когда вы много читаете / пишете на диск. Wordpress должен использовать 90% чтения и 10% записи. Большую часть времени вы должны попадать в кеш памяти.
Если ваша база данных и запросы настроены правильно, вам не потребуется столько операций ввода-вывода в секунду.
Учитывая количество людей, использующих Wordpress (я не знаю этот конкретный плагин), я готов поспорить, что запросы настроены правильно.
RDS ограничен движком InnoDB. Этот движок использует параметр innodb_buffer_pool_size для кэширования данных в памяти. Об этом нужно позаботиться в первую очередь. К счастью, это значение автоматически устанавливается RDS (фактор памяти, имеющейся в вашем экземпляре RDS).
49 мс - это не так уж и медленно. Бьюсь об заклад, ваша проблема в другом. Попробуйте инструмент, который проанализирует ваши медленные запросы (упорядочит и объединит их): http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html
Чтобы получить файл журнала медленных запросов: http://www.palominodb.com/blog/2011/10/20/exporting-mysqlslowlog-table-slow-query-log-format
В большинстве случаев вам не нужно играть с параметром query_cache. Если вы установите слишком большое значение, вы даже можете столкнуться с потерей производительности (каждый раз, когда вы меняете данные, вам необходимо аннулировать кеш для соответствующего запроса).
Наконец, графики Cloudwatch показывают, что ваша БД спит, но ваш веб-сервер использует слишком много ЦП.
Узкое место здесь определенно не ваша БД.