Помощь Оптимизация wordpress или что-то еще?

UFOS · 21 Янв 2011

Есть выделенный сервер 2ghz Cor2Duo память 3gb
Установлен Debian 507

Проц конечно слабоват но не думаю, что уж на столько.

На сие деле Висит WordpPress ласт вершн 3.0.4 Включено ЧПУ.
База данного сайта составляет полтора гигабайта. Постоянно оптимизируется раз в 3 часа.

Плагины имеем:
All in One SEO Pack
Customize Meta Widget
Executable PHP widget
FeedMaster (1.7 версия до 2ки пока не стал обновлять всего хватает)
Optimize DB
RusToLat
Simply Exclude
WP-NoRef
WP-SpamFree
WP Missed Schedule
WP Super Cache
XML Sitemap Feed

конфиг апача,

Timeout 40
KeepAlive Off
MaxKeepAliveRequests 200
KeepAliveTimeout 2

StartServers 2
MinSpareServers 2
MaxSpareServers 5
MaxClients 50
MaxRequestsPerChild 0

вывод mysqltuner

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny5
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1515M (Tables: 26)
[!!] Total fragmented tables: 1

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2h 24m 35s (259K q [29.957 qps], 5K conn, TX: 1B, RX: 48M)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 906.0M global + 2.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 1.1G (40% of installed RAM)
[OK] Slow queries: 0% (306/259K)
[OK] Highest usage of available connections: 32% (32/100)
[OK] Key buffer size / total MyISAM indexes: 128.0M/88.4M
[OK] Key buffer hit rate: 99.9% (125M cached / 69K reads)
[OK] Query cache efficiency: 58.5% (140K cached / 240K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (71 temp sorts / 71K sorts)
[!!] Temporary tables created on disk: 48% (63K on disk / 129K total)
[OK] Thread cache hit rate: 97% (157 created / 5K connections)
[OK] Table cache hit rate: 95% (137 open / 143 opened)
[OK] Open file limit used: 8% (180/2K)
[OK] Table locks acquired immediately: 99% (221K immediate / 222K locks)

после 24х часов ничего не меняется. Везде Ок параметры подбирал очень долго.

Что имеем на выходе? Посещаемость 3к уников в сутки.

Загрузка ЦПУ меньше 90% не падает, а почти всегда 100% Памяти благо хватает, бывают попрыгайчики до 3гб со свопом но это когда feedmaster срабатывает и какой нить гуглобот рыщет.

Можно ли что-то с этим сделать? Да знаю оптимально сменить движок на менее ресурсосберегающий, но еще варианты? Может mysql подкрутить? По top только mysql загружает проц на 60-80% остальное Apache. Может плагины сменить на какие либо альтернативные? Уж больно лагадром большой на таком компе...Уже месяц бьюсь с оптимизацией вереща гугль (((

ХельП!

UFOS · 23 Янв 2011

itex написал(а):

Ну по поводу работы nginx и кеширующих плагинов решается
вставками в "location / {" конфигурации сайта nginx

Код:

#supercache
set $supercache_file '';
set $supercache_uri $request_uri;
set $supercache_file /var/www/html/$http_host/www/wp-content/cache/supercache/$http_host/$uri/index.html;
if ($is_args)
{
set $supercache_file '';
}
# only rewrite to the supercache file if it actually exists
if (-f $supercache_file) {
rewrite ^(.*)$ /wp-content/cache/supercache/$http_host$uri/index.html last;
}
set $supercache_file /var/www/html/$http_host/www/static_cache$uri/index.html;
if ($is_args)
{
 set $supercache_file '';
}
# only rewrite to the supercache file if it actually exists
if (-f $supercache_file) {
rewrite ^(.*)$ /static_cache$uri/index.html last;
}

И добавления двух локейшен

Код:

#location $supercache
	location /wp-content/cache/supercache
	{
 		gzip_static on;
 		root   /var/www/html/$host/www/;
 		proxy_cache_key $proxy_host-$scheme-$host-$uri-$request_uri-$is_args-$args;
		proxy_cache_valid  200 304 1h;
		proxy_cache_valid  301 1h;
		proxy_cache_valid  any 1h;     
		proxy_ignore_headers "Cache-Control" "Expires";
		proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504;
		open_file_cache max=1024 inactive=600s;
		open_file_cache_valid 2000s;
		open_file_cache_min_uses 1;
		open_file_cache_errors on;
	}
	location /static_cache
	{
 		gzip_static on;
 		root   /var/www/html/$host/www/;
 		proxy_cache_key $proxy_host-$scheme-$host-$uri-$request_uri-$is_args-$args;
		proxy_cache_valid  200 304 1h;
		proxy_cache_valid  301 1h;
		proxy_cache_valid  any 1h;     
		proxy_ignore_headers "Cache-Control" "Expires";
		proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504;
		open_file_cache max=1024 inactive=600s;
		open_file_cache_valid 2000s;
		open_file_cache_min_uses 1;
		open_file_cache_errors on;
	}

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

Спасибо, попробую может поможет, только не понятно все же почему wordpress так mysql гоняет при каждом запросе учитывая что треть базы уже в кеше mysql и отдается мгновенно.

UFOS · 25 Янв 2011

Поставил, настроил, прирост есть да, но прирост только на выдаче кэша. Вообщем как и было где то на 10% быстрее. Как я понимаю сейчас апач не плодит сессии и нагрузка меньше, а мускуль как жрал 80% CPU так и жрет ;( Может можно как то переделать (оптимизировать) запросы самого WP на mysql? по сути в процессах к базе всего 70 подключений в пик, я считаю что это не так много.

itex · 27 Янв 2011

Ну смотрите "SHOW PROCESSLIST" в mysql, какие запросы долго висят и делайте explain. Возможно надо будет сделать дополнительные индексы. На практике у меня почемуто очень тормозил firestats, пришлось отключать на некоторых блогах.

UFOS · 23 Мар 2011

Апну мою старую тему...

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

Помогите гуру )

aleksy_g · 23 Мар 2011

А что на предмет wp-file-cache

Очень даже вменяемый подход как к оптимизации работы с базой так и апачу в разы дышать легче. После подключения (с минимальными настройками) этот красавец сразу в половину снял потребность WP в памяти,ну а запросов так вообще стало раз в 7-8 меньше. Реально не ожидал. А в сочетании с нормально оптимизацией БД можнно в итоге ещё эдак в половину облегчить душу процу. ЗЫ.Мой хостер иногда наезжал на тему нагрузки моих сайтов (домен первого уровня и под ним несколько субчиков), после установки только этого плуга претензий не стало.

porsche2 · 24 Мар 2011

Пробовали такой метод?

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

1.Файловое кеширование, или кешироание nginx

roxy_cache одиноково работают и перекладывают нагрузку на HDD, хотя при 3к уников это не критично совсем

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

2. Нужно настроить/проверить кеширование на клиенте, чем больше можно запихать серферу в кеш, тем меньше запросов от него получим если он начнет просматривать сайт.

3. RSS тоже желательно кешировать 10-20 минут достаточно, и нагрузки будет меньше.

4. В Google запрос типа "wordpress оптимизация" может помочь, хотя ХЗ там одно и тоже перемалывают, но есть интересные моменты в плане php

5. Маловато индейцев, попробуйте хотябы так:

PHP:

StartServers 7
MinSpareServers 7 
MaxSpareServers 17
ServerLimit      ???
MaxClients       ???
MaxRequestsPerChild 2000

6. сапа дает тормоза при генерации страниц

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

8. Плагины должны быть актуальны версии WP, плагины от старых версий могут вытворять все что угодно.

9. HDD может быть тормозной или присмерти, нужно проверить

3-5 человеков на сайте, даже для тормозного WP мало чтобы грузить проц на 100%, ищите и лечите проблему, а потом уже будете заниматься кешами и оптимизацией.

xRay_TFB · 25 Мар 2011

Отследите график нагрузки:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Если завелись роботы:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Если есть сложные и тяжелые запросы к БД

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Записать логи по медленным запросам:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Для анализа медленных запросов:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

или

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Пример, как это делается:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

А здесь расписано про mtop и mkill

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

И про профилирование:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

UFOS · 25 Мар 2011

porsche2 написал(а):
Пробовали такой метод?
*** скрытое содержание ***
1.Файловое кеширование, или кешироание nginxroxy_cache одиноково работают и перекладывают нагрузку на HDD, хотя при 3к уников это не критично совсем Если время файлового кеша которое можно себе позволить менее 1 часа, то файловый кеш не годиться, т.к. при большом количестве страниц скрипты будут только писать и стирать файлы, а реальных попаданий в кеш будет мало.
2. Нужно настроить/проверить кеширование на клиенте, чем больше можно запихать серферу в кеш, тем меньше запросов от него получим если он начнет просматривать сайт.
3. RSS тоже желательно кешировать 10-20 минут достаточно, и нагрузки будет меньше.
4. В Google запрос типа "wordpress оптимизация" может помочь, хотя ХЗ там одно и тоже перемалывают, но есть интересные моменты в плане php
5. Маловато индейцев, попробуйте хотябы так:

PHP:

StartServers 7 MinSpareServers 7 MaxSpareServers 17 ServerLimit ??? MaxClients ??? MaxRequestsPerChild 2000

6. сапа дает тормоза при генерации страниц
7. Можно по одному отключать плагины и смотреть как они влияют на нагрузку БД, какой-нибудь из плагинов может давать нагрузку.
8. Плагины должны быть актуальны версии WP, плагины от старых версий могут вытворять все что угодно.
9. HDD может быть тормозной или присмерти, нужно проверить
3-5 человеков на сайте, даже для тормозного WP мало чтобы грузить проц на 100%, ищите и лечите проблему, а потом уже будете заниматься кешами и оптимизацией.

Мемкеш не пробовал но я не думаю что будет прирост хотя как последняя надежда я попробую.
Конфиг пхп вообще на минимально 2 максимально 5 для SpareServers, все остальные настройки уже испытаны, ничего не помогает, загрузка mysql 99% всегда и стабильно.

colyd · 26 Апр 2011

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

Помощь Оптимизация wordpress или что-то еще?

UFOS

Создатель

UFOS

Создатель

UFOS

Создатель

itex

Гуру форума

UFOS

Создатель

aleksy_g

Создатель

porsche2

Мой дом здесь!

xRay_TFB

Постоялец

UFOS

Создатель

colyd

Создатель