Wordpress начал резко грузить весь сервачный mysql.

смотрите долгие запросы по логами и делайте explain

поставьте плагины кеша, они могут совсем снять нагрузку

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

Покажите вывод pt-summary . Посмотрите статус дисков md и состояние SMART.

Кстати, буквально два дня назад 7 февраля было первое воскресенье месяца - день когда в дебиане тормозит вообще все, потому что запускается запланированная проверка raid.

С железом проблем нет, СМАРТы идеальные. Рейд собран, проверка рейда прошла успешно.

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

Может у кого были те же проблемы с сайтами на WP ?

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

>поставьте плагины кеша, они могут совсем снять нагрузку

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

проход mysqltuner'ом, включение логов медленных запросов, дебаг кода.

в 99% случаев как правило - проблема в коде.

например при открытии главной из БД зачем то выбираются сразу 10к записей вместо того что бы показать первые 100 записей, а остальные на следующей странице.

Так же интересно было бы посмотреть на выводы top, htop,mytop.

Тривиальный тест записи\чтения на диски через dd и т д.

Какое железо на сервере, используете ли полнотекстовой поиск ?

Железо: Intel® Core™ i7-4770 Quadcore Haswell – 4 ядра, 32 GB DDR3 RAM, 2 x 2 TB 6 Gb/s SATA 7200 rpm/Enterprise; Debian 7 Wheezy 64 bit

Не используем, InnoDB.

Вот такие запросы в основном проскакивают по mytop:

916712 user localhost kvant_ 0 Query SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (663,858,866,873,914,977,995,1180,1201,1334,1366,1426,1458,1488,1536,1542,1553,1566,1578,1626,1630,1923,1988,1989,2001,2024,2134,2323,2

916714 user localhost titanl 0 Query SELECT wp_posts.* FROM wp_posts WHERE ID IN (1686,331,2361,1144,3135,2323,3001,1547,3379,1894,2656,3247,2372,542,2531,2778,2148,1704,2077,2984,1218,1893,873,439,2441,3464,2620,2452,472,899,2322,2308,2251,29

916717 user localhost bladel 0 Query SELECT * FROM wp_posts WHERE ID = 1401 LIMIT 1

920318 user localhost mister 0 Query SELECT wp_posts.ID FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (8) ) AND wp_posts.post_type =

920319 user localhost hairta 0 Query SELECT wp_posts.ID FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (40) ) AND wp_posts.post_type =

11258 root localhost mysql 1468 Sleep

Остальные просто в sleep статусе и нет инфы никакой по запросам к бд.

>Тривиальный тест записи\чтения на диски через dd и т д.

Тестировали, вроде проблем не было...

На сайтах используется get_posts 40 рандомных постов по индексу, скорее всего он грузит. Вопрос в том, что нагрузка как-то очень резко увеличилась. Не знаю, может таблицы могли поломаться или еще что?

Судя по картинкам - нагрузки нет.

Своп - есть. Может сильно свопит.

Ну а что же с slow log ? Нет запросов ?

Чтобы не терять время на возможно не самые важные запросы, которые в случайный промежуток времени выскочили в mytop, лучше cобрать запросы за день и проанализировать с помощью pt-query-summary. Кроме того, там дополнительная статистика по запросам собирается. в mytop ее нет вообще.

pt-summary достанет всякую информацию о железе, о важности которой вы даже не подозревали. pt-mysql-summary тоже неплохо бы.

Можно еще проверить какой выставлен cpu governor. Кажется, частоты низковаты. Но опять же, pt-summary показал бы нормальную ситуацию когда одно ядро разогревается. на скрине atop этого не видно.

Поддерживаю. Тем более, что судя по конфигу это Хетцнер. И почему-то в atop не видно ядер.

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

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

Strelnik, Будет звучать дебильно но не пробовали memcached под wp?