Wordpress кладет сервер, помогите! Что делать?

Здравствуйте.
Сделали сайт на Wordpress. Содержит порядка 150 тыс обычных записей, порядка 40 тыс записей произвольного типа. Все это связано между собой.
Так же есть дополнительные поля с помощью Advanced Custom Field. В общем жутко тяжелая неповоротливая штука.
Установлен кеш Hyper Cache.

Посещаемость 1 тыс в сутки.
Идет жестокая нагрузка на базу данных. Очень долгие mysql запросы, переполнение swap 8 GB.
В связи с нехваткой ОЗУ, ПК переходит на использование жесткого диска. Затем весь раздел жесткого диска переполняется и система зависает.
Хотя сервер достаточно мощный: Intel Pentium Dual Core E5300 2 x 2.6 Ghz 4GB DDR2 500GB

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

Цитата:

Что делать?

Выкинуть WP.
Ну или ввязываться разбирательство и оптимизацию. Сначала надо понять что же там такое страшное то. Какие запросы самые медленные? Что там с индексами?

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

Цитата ("Hungry_Hunter"):

Там все запросы самые медленные

Значит все их нужно анализировать.
Цитата ("Hungry_Hunter"):

Оптимизировать их все - переписать вордпрес разве что

Ну так я же это уже сказал. Выкинуть WP!

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

Slow_sqlquery показывай. Надо смотреть в чем проблема, скорее всего в джойнах и нехватке памяти.
1 тыс в сутки - это 1 запрос в секунду на протяжении 3 часов - это мало.
SQL надо настраивать, что бы он более 80% памяти не жрал
1. я бы палил лог медленных запросов
2. по медленным запросам посмотреть план запроса "чего не хватает" и проставлял бы индексы
3. если реально в памяти проблема то поработать с кэшами джойнов и запросов

База сама сколько "весит"?

Цитата ("Hungry_Hunter"):

лог медленных запросов растет просто на глазах

Показывай кусками, не думаю что в WP тупее и криворукее Битрикса

База весит до 500 МБ

К примеру, много таких запросов:

# Query_time: 25.901452 Lock_time: 0.000099 Rows_sent: 10 Rows_examined: 129370
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

и таких:

# Query_time: 19.617640 Lock_time: 0.000130 Rows_sent: 10 Rows_examined: 129370
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND ( wp_posts.ID NOT IN ( SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id IN (1)) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

Поля wp_posts.post_type и wp_posts.post_status текстовые? Это особенность WP? Если сделать эти поля байтовыми, нагрузка на SQL Server должна значительно уменьшиться.

wertex76, тип varchar, да, это особенность wordpress.

Hungry_Hunter, explain покажи.
ссылка Вот еще кое что. Можно эксперимент поставить.

frig, Как сисадмин появится, попрошу сделать

Hungry_Hunter, тогда и структуру бы хорошо показать. С индексами.

Rows_examined: 129370 это не есть гут.

Да, это совсем не гуд (

EXPLAIN SELECT wp_posts.ID

FROM wp_posts

INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) 

WHERE 1 =1

AND wp_posts.post_type =  'post'

AND (

wp_posts.post_status =  'publish'

)

AND (

(

wp_postmeta.meta_key =  'book_author'

AND CAST( wp_postmeta.meta_value AS CHAR ) LIKE  '%123912%'

)

)

GROUP BY wp_posts.ID

ORDER BY wp_posts.post_date DESC 

LIMIT 0 , 100



1 SIMPLE wp_postmeta ref post_id,meta_key meta_key 768 const 101113 Using where; Using temporary; Using filesort

1 SIMPLE wp_posts eq_ref PRIMARY,type_status_date PRIMARY 8 wp_1.wp_postmeta.post_id 1 Using where


explain SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND ( wp_posts.ID NOT IN ( SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id IN (1)) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 10

#1146 - Table 'wp_1.wp_posts' doesn't exist

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) WHERE 1=1  AND ( wp_posts.ID NOT IN (

                                        SELECT object_id

                                        FROM wp_term_relationships

                                        WHERE term_taxonomy_id IN (1)

                                ) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') AND (wp_postmeta.meta_key = 'views' ) GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value+0 DESC LIMIT 0, 10

1 PRIMARY wp_postmeta ref post_id,meta_key meta_key 768 const 61917 Using where; Using temporary; Using filesort

1 PRIMARY wp_posts eq_ref PRIMARY,type_status_date PRIMARY 8 wp_1.wp_postmeta.post_id 1 Using where

2 DEPENDENT SUBQUERY wp_term_relationships unique_subquery PRIMARY,term_taxonomy_id PRIMARY 16 func,const 1 Using index; Using where

В общем-то индексы не используются. mysql-лю приходится дофига инфы перелопачивать

Каша, конечно, слабо читабельная.
Индексы в wp_postmeta где? Какой движок, сколько записей?

Цитата ("frig"):

Какой движок, сколько записей?

В первом посте все

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

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

Hungry_Hunter, кэш это здорово когда он работает и когда сделан по уму. А что там наворочено в WP, как оно работает и работает ли - я не знаю.
Выкинь каку, в общем.

Hyper Cache, как я понял, не кэширует результаты запросов к БД. Можно попробовать установить W3 Total Cache и настроить Database Cache. В целом, оптимизировать запросы (точнее, схему БД) можно, но мне кажется, проблема в том, что их достаточно много выполняется параллельно и в результате имеем тормоза mysql. Кэширование результатов SELECT'ов должно помочь разгрузить СУБД и каждый конкретный запрос будет выполняться немного быстрее.