Сайт начал грузить хостера

[rymljanyn]

Народ может кто подскажет. С какого то перепугу сайт d-nk.com.ua начал грузить проц хостера.

Вот что пишет Хостинг

"В том-то и проблема, что определить причину нагрузки не удается.

Я просмотрел нагрузку по вашему аккаунту с начала лета — она медленно, но постоянно растет — где-то в начале июня она в среднем перевалила через 1%, в начале октября — через 2%, в середине ноября — через 3%.

Потому мне кажется — где-то какие-то данные, которые используются при генерации страниц, накапливаются и таким образом замедляют обработку страниц все дальше и дальше.

Больше всего строк у вас в таблицах: wp_comment_rating, wp_login_fails, wp_postmeta, wp_term_relationships, wp_yapp_related_cache.

Первым делом я бы попробовал отключить комментарии или систему их оценки (рейтинга).

Еще немного инфы

[spoiler]В статистике запросов к сайту нет POST-запросов к /wp-login.php и /xmlrpc.php (пакетный подбор паролей). Также нет запросов к /wp-comments-post.php.

Кроме того, несмотря на большое количество запросов к admin-ajax.php и вообще наличие работы в админке (которая у wp часто является причиной повышенного потребления ресурсов) — основную часть нагрузки создают запросы, приходящиеся на точки входа вне папки wp-admin.

Идея о размере таблиц возникла так как нагрузка растет очень медленно, общее количество запросов достаточно стабильно и сравнительно мало, а в своей практике я сталкивался с проблемами с перегрузкой из-за спaм-комментариев, которые даже на сайте и не отображались (но, видимо, где-то обрабатывались движком). Обнаружить такое можно только исследованием базы данных.

Если нужно — можно привести конкретные цифры потребления по датам и конкретную статистику посещений (если топикстартер не против).

......

Количество запросов к сайту с начала лета возросло в среднем с 9 тысяч до 15 тысяч в день. Это по страничке вебалайзера. Более точную выборку можно сделать за последние десять дней, но за это время количество посещений приблизительно на одном уровне.

Если нужна статистика

Могу открыть доступ всем к webstat (webalizer), могу выдать результаты анализа логов с фильтрованием или без.

И еще немного инфы

Цитата:

- начать кэшировать (хотя при такой посещаемости это смешно)

На сайте стоит wp-super-cache, время хранения кеша — 2 дня.


Узнать, какие страницы/запросы создают основную нагрузку.
Вот тут проблема — каким образом. Учет процессорного времени идет по времени исполнения процесса php. Один процесс php обрабатывает до 500 запросов, т.е. время индивидуального запроса определить не получится. Единственное что я могу сделать — разнести выполнение запросов, идущих на разные точки входа по разным php-процессам, что уже и было сделано для админки и содержимого wp-content.

Соответственно, остается анализ статистики посещений. Статистика за вчера (отсеиваются запросы к статике, так как она не требует исполнения скриптов):

Код:
[[ -- Requests by url  -- ]]
-- [[ d-nk.com.ua ]] --
      1566  /sogodni-poxoron-zagiblogo-pid-mariupolem-truskavchanina/ 
      1482  /wp-content/plugins/yet-another-related-posts-plugin/includes/styles_thumbnails.css.php?width=147&height=95&ver=4.2.5 
       477  /                                         
       452  /feed/                                   
       301  /robots.txt                               
       287  /wp-admin/admin-ajax.php                 
       146  /sogodni-poxoron-zagiblogo-pid-mariupolem-truskavchanina/a_shiht/ 
        99  /u-drogobichi-rozvivatimut-divochij-futbol/ 
        79  /analitika/avtori/oleksandr-magliona/vas-nasiluyut-rasslabtes/ 
        78  /on-vyxodil-s-pod-ilovajska/             
        72  /u-drogobichi-vidbulasya-toloka-z-pribirannya-istorichnoyi-pam-yatki-video/ 
[[ -- Requests by IP   -- ]]
-- [[ d-nk.com.ua ]] --
       464    188.163.74.91  [UA] SOL-FTTB.91.74.163.188.sovam.net.ua
       285   183.79.222.164  [JP]
       200    84.19.190.163  [DE] ns.km34133-04.keymachine.de
       186     91.209.51.22  [UA] 22.51.209.91.akson45.kiev.ua
       180     91.200.40.83  [UA] h83.hvosting.ua
       154   188.165.15.177  [FR] boson034.ahrefs.com
       142    68.180.228.35  [US] b110003.yse.yahoo.net
       141   183.79.223.113  [JP]
       135    66.249.78.207  [US] crawl-66-249-78-207.googlebot.com
       115    185.65.244.61  vps-12273.vps-Ukrаine.com.ua
       106    188.165.15.61  [FR] boson073.ahrefs.com
[[ -- Requests per day -- ]]
-- [[ d-nk.com.ua ]] --
  2015-12-14        8140


Цитата:

А что мешает хостеру зайти в консоль и посотреть потребление оперативки по команде top? Если это демон MySQL грузится, то нужно проверять сколько ему вообще отведено памяти. И самое главное: всё ли нормально с индексами таблиц. Они создаются? Они вообще есть?

MySQL находится на отдельном сервере и в нагрузку не считается. Считается только cron, скрипты сайта и работа с файлами.


На php хостер может поставить eaccelerator для ускорения компиляции скриптов. А все эти "не удалось найти причину" - это ерунда и некомпетентность.[COLOR="Silver"]
eaccelerator — мертвый проэкт. У нас по умолчанию стоит и включен xcache.

Цитата:

Код:
SELECT count(*) FROM `wp_options` WHERE `autoload` = 'yes'
сколько насчитывает?
Код:
mysql> SELECT count(*) FROM `wp_options` WHERE `autoload` = 'yes';
+----------+
| count(*) |
+----------+
|      351 |
+----------+
[/spoiler]
Кому хватит нервов досмотреть и что то продуктивное предложить буду благодарен. Предложений по смене хостера не нужно, просто не тратьте время

Всем спасибо

[Carte-de-France]

Было так, четыре разных программиста бились и не помогли. В итоге выстраивала весь сайт заново, попрощавшись с комментариями (но у меня почти статичный был, не уверена, что Вам поможет).

[natmir]

Попробуйте деактивировать плагин wp-super-cache, но загрузить и активировать другие плагины Hyper Cache и DB Cache Reloaded Fix. Именно эти оба плагина, а не какой-то из них. Не так давно у меня была подобная ситуация и мои хостеры нашли причину именно в плагине wp-super-cache. Механизм действия не расскажу - ничего в этом не понимаю.
Вот из переписки с хостерами: "у Вас накапливается достаточно большое количество одновременно запущенных процессов (это видно по статистике потребления ресурсов, лимит: 20 - максимум: 20)."

После активации плагина DB Cache Reloaded Fix в конфигурационный файл Вашего скрипта (он расположен в папочке сайта) - wp-config.php - нужно добавить строчку: define('WP_CACHE', true); После этого выставить необходимые настройки для плагина в панели администратора. С активацией плагина Hyper Cache проблем не будет.

[Price]

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

[maxikk]

Т.к. у Вас WP
Рекомендую обратить внимание на ревизии, они катастрофично плодят Базу данных.
Решение проблемы: Revision Control
и выбираете, сколько хранить последних редакций страницы, На коммерческих сайтах ставлю 3, на MFA - 0.

[Shakanris]

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