Мой сервер, который и будет героем последующего повествования - это обычный арендованный у FirstDedic сервер среднего класса с процессором DualCore Xeon E3110 3.00Ghz. Оперативной памяти было установлено 4 Гб, жесткий диск 500 Гб. На сервере был установлен nginx 1.01 в качестве frontend, и apache 2 в качестве backend, с запуском скриптов в режиме CGI.
История приключилась с сайтом, который был размещен на моем сервере, собственно, не сайт, а чужой личный блог . Ранее на блоге наблюдались пики трафика до 10000 в сутки, но с подобной нагрузкой сервер справлялся на ура абсолютно без оптимизации на стандартных файлах конфигурации.
И вот, в один прекрасный «Женский день», утром, приходит SMS от сервиса мониторинга сайтов, что сервер недоступен. Естественно, от такой новости мгновенно просыпаюсь, и пробую пинговать сервер. Пинг присутствовал, но очень вялый. Соединение по SSH установить невозможно, потому что все ресурсы сервера отданы неизвестному процессу, или процессам.
Соединившись по KVM, я отправил сервер в перезагрузку, и сразу после загрузки соединился по SSH. В процессах, я увидел страшную картину: запущено около 1000 процессов php от имени автора блога, кроме того, Load averages больше сотни. Очень страшный показатель, который показывает, сколько приходится ожидать процессу своей очереди на порцию ресурсов.
Естественно, времени мне хватило только чтобы это увидеть, запустив команду top. Уже через минуту сервер перестал отвечать на запросы, и пришлось его вновь перезагрузить, и сразу после перезагрузки выключить apache. Теперь я гарантированно получил сервер, который не израсходует все ресурсы. Начал проводить анализ, я вывел число открытых соединений командой netstat и ужаснулся. Было более 10000 установленных соединений с nginx. Это значит, что за последнюю минуту было 10 тысяч попыток зайти на сайт клиента – хорошая нагрузка.
Попытавшись порыться в настройках WordPress, естественно с согласия клиента, Я обнаружил, что был активирован плагин для кэширования WP Super Cache, который я выключил, потому что при выполнении самую большую нагрузку на файловую систему давал именно он. Выключив плагин, сайт стал выполнять очень много запросов в базу данных – неудивительно. Поэтому первым делом я включил систему кэширования запросов в MySQL, так как нагрузку давала всего одна страница, на которую и было множество переходов. После включения кэширования запросов, база данных вздохнула свободнее, но не настолько, насколько хотелось бы, притом, что основную нагрузку теперь давал сам Wordpress.
Выключив все возможные плагины и переписав тему с наименьшим количеством запросов, нагрузка не уменьшалась. Пришлось идти на крайние меры - я включил принудительное кэширование проксированных запросов в nginx. Для этого я прописал в секции http следующую строку
Proxy_cache_path /path/to/cache levels=1:2 keys_zone=wpblog:10m max_size=10m;
В нужную нам секцию server прописываем:
Proxy_cache_valid 200 3m; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080;
Как только я это сделал, нагрузка на сервер резко упала. Однако мы получили множество неудобств, связанных с администрированием и комментированием. Несмотря на неудобство, проблема была решена. Однако сознание подсказывало, что включать вручную такое кэширование не всегда будет время и возможность, а оставлять как есть не вариант для автора блога. Таким образом, пришлось запрещать кэширование для авторизованных пользователей, и пользователей, оставивших свои комментарии. В итоге получается примерно такая секция server:
Proxy_cache_valid 200 3m; location / { if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_") { set $do_not_cache 1; } proxy_no_cache $do_not_cache; proxy_cache_bypass $do_not_cache; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080; } location ~* wp\-.*\.php|wp\-admin { proxy_pass http://127.0.0.1:8080; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ { root /path/to/static; access_log off; expires max; add_header Last-Modified: $date_gmt; } location ~* \/[^\/]+\/(feed|\.xml)\/? { proxy_pass http://127.0.0.1:8080; }
После этого неудобства в работе полностью компенсируются бесперебойностью.
Как итог ко всему вышеописанному, сервер был недоступен в течение 2 часов, за это время поток трафика значительно уменьшился, но после этого случая были и другие подобные праздничные всплески посещаемости, которые сайт успешно выдержал, не дав ощутимой нагрузки на сервер. С тех самых пор стараюсь на все размещенные сайты на WordPress ставить такую конфигурацию.
Google Analytics на сайте клиента, после того, как сервер окончательно поднялся, показывал 6000 посетителей онлайн. Эта цифра быстро падала, потому что актуальность запроса, по которому сайт был в топе всех поисковых систем, терялась каждую минуту. К концу дня, количество посетителей стало семизначным, но владелец ресурса до сих пор смотрит на меня волком, потому что цифра могла быть в разы выше, как и его доход.
Используя этот конфиг могу с уверенностью сказать, что сервер переносит несколько подобных сайтов. Так как мой проект после добавления в Google-Новости стал привлекать много трафика, как собственно и с Яндекс-блогов.
В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер . Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.
Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.
Все довольно просто и очень эффективно. Это позволяет нам избежать огромного количества статических HTML страниц, что значительно уменьшает объем занимаемого сайтом места. Также существует множество других плюсов, но есть и свои минуса, одним из которых есть нагрузка на сервер. Есть множество способов ее уменьшения. Я расскажу о трех из них, которыми пользуюсь сам. Они показали неплохие результаты, поэтому есть смысл в их использовании.
Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.
Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.
Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.
После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку
Define("WP_CACHE", true);
Лучше это делать ближе к концу файла, но не дальше строк
If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");
Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.
- Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
- Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
- Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
- Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
- Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.
Это были основные настройки плагина Hyper Cache. Для того, чтобы проверить его работоспособность, заходим на наш сайт как незарегистрированный пользователь и смотрим исходный код страницы. В конце должна присутствовать такая строка.
Если она есть, то плагин работает нормально.
Снижение нагрузки на сервер за счет кэширования запросов к базе данных.
Для этого можно использовать специальный плагин DB Cache Reloaded . Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.
Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.
Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код
queries in seconds.
Приведенный выше вариант будет выводить информацию о количестве обращений к БД и времени загрузки страницы. Замечу, что информация будет видна только вам. То есть будет выводиться только тогда, когда вы авторизированны на сайте. Выглядеть это будет примерно так:
Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.
Оптимизация шаблона WordPress
Оптимизация шаблона или темы сводится до уменьшения количества обращений к базе данных. Так как шаблоны создаются универсальными, то разработчики стараются все автоматизировать. Все это делается для удобства пользователей. Но если вы уже разобрались с темой, которую будете использовать, то можно уже начинать ее оптимизировать. Весь смысл состоит в том, чтобы заменить стандартные PHP кода с обращениями к базе на статичные. Проделывать такое мы будем в двух файлах – шапке сайта и футере. Начнем с первого.
Оптимизация header.php
1. Находим код
и меняем его на название своего блога. У меня это
Сайт - создание и продвижение сайтов, блогов, заработок на сайте.
2. Код, отвечающий за вывод описания, заменяем на статический.
3. Строка, отвечающая за вывод кодировки.
; charset=" />
Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:
4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.
" />
Это нужно сделать для улучшения безопасности блога, так как именно эта информация является опасной и может сообщить злоумышленникам то, что им знать не нужно. Тем более если вы используете более раннюю версию движка, то данное изменение вам необходимо.
5. Заменяем путь к таблице стилей вашего шаблона на статичный.
" type="text/css" media="screen" />
После модификации будет иметь примерно такой вид:
6. Меняем путь к RSS ленте на статический.
RSS Feed" href="" />
После изменения будет выглядеть вот так:
7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).
" />
Заменяем на
Оптимизация файла footer.php
В принципе здесь, по большому счету, можно оптимизировать только вывод копирайта. Для этого код
заменяем на свой текст. У меня это
- «Оптимизация WordPress за счет уменьшения количества обращений к данным »
На этом я заканчиваю данную статью. Если у вас остались какие-то вопросы, вы всегда сможете задать их в комментариях.
На этом все. Удачи вам и успехов в оптимизации сайтов.
Из этой статьи вы узнаете как значительно ускорить сайт на WordPress с использованием Memcached.
Пошаговая инструкция
Memcached - система распределенного кэширования памяти
Memcached кэширует данные и объекты прямо в память RAM и сокращает время доступа к внешнему ресурсу (например, вызовы БД или API-вызовы). Это особенно помогает динамическим системам, таким как WordPress или Joomla!, заметно ускоряя время обработки запроса.
Важно: перед началом хотим заметить, что Memcached не имеет встроенных мер безопасности для работы на shared-хостинге! Данная инструкция подходит только для выделенного сервера (VPS).
Установка Memcached
На нашем сервере используется Plesk с CentOS 7.x. Тем не менее, это руководство применимо и к другим системам, однако при выполнении следующих операций нужно использовать утилиты, специфичные для определённых систем (например, apt-get вместо yum). Для того чтобы установить Memcached, в первую очередь следует подключиться к серверу по SSH и использовать командную строку:# yum install memcached
После завершения установки вводим следующую команду:
# service memcached start
Далее следует установить PECL-версию Memcached для нужной версии PHP. WordPress полностью совместим с PHP 7, поэтому давайте активируем Memcached для последней версии PHP - 7.1. Начнём с установки всех необходимых пакетов для добавления их к нашему кастомному PHP-модую в Plesk:
# yum install make plesk-php71-devel gcc glibc-devel libmemcached-devel zlib-devel
Соберите модуль, следуя этим инструкциям. Вы можете не указывать директорию Memcached вручную, просто нажмите Ввод при запросе:
/opt/plesk/php/7.1/bin/pecl install memcached
Следующим шагом станет добавление строчки к соответствующему конфигурационному файлу, чтобы зарегистрировать модуль в PHP. Вы можете использовать командную строку, не открывая самого файла в редакторе:
# echo "extension=memcached.so" > /opt/plesk/php/7.1/etc/php.d/memcached.ini
И наконец, перечитайте обработчики PHP, чтобы модуль отобразился в информации о PHP в графическом меню Plesk.
# plesk bin php_handler -reread
Теперь Вы можете вызвать страницу phpinfo(), чтобы проверить корректную загрузку модуля Memcached:
Либо используйте командную строку:
# /opt/plesk/php/7.1/bin/php -i | grep "memcached support"
Защитите и контролируйте ваш Memcached
Memcached по умолчанию использует порт 12211.Из соображений безопасности можно перенаправить данный порт на локальную машину.Добавьте следующую строку в конец файла /etc/sysconfig/memcached и перезагрузите службу Memcached:
OPTIONS="-l 127.0.0.1"
Для мониторинга и получения статистики от Memcached используйте следующие команды:
echo "stats settings" | nc localhost 11211
/usr/bin/memcached-tool localhost:11211
Активируйте Memcached в WordPress
Как только Memcached установлен на сервер, он доступен для активации в WordPress. В первую очередь нужно активировать бэкенд Memcached специальным скриптом, который автоматически определяет, использовать ли Memcached в качестве кэширующего механизма.Скачайте скрипт с https://github.com/bonny/memcachy и переносите все файлы в директорию /wp-content/.
Если Вы не меняли порт Memcached по умолчанию (11211), Вы можете использовать его напрямую. Если вы изменили его, то в файл wp-config.php, лежащий в корневой директории вашей установки WordPress, следует добавить следующий код:
$memcached_servers = array(array("127.0.0.1", 11211));
Теперь, когда активирован бэкенд, мы установим кэширующий плагин для сохранения и предоставления обработанных страниц через Memcached. Установите плагин Batcache (https://WordPress.org/plugins/batcache/) используя инструкцию по установке:
- скачайте и разархивируйте архив;
- загрузите файл advancaed-cache.php в директорию /wp-content/;
- откройте wp-config.php и добавьте следующую строку:
- загрузите batcache.php в директорию /wp-content/plugins.
define("WP_CACHE", true);
Важно: убедитесь, что Memcached для выбранной версии PHP включён корректно, иначе добавление этой строки вызовет ошибку!
Вот и всё! Теперь можете открыть advanced-cache.php и отрегулировать настройки по вашему усмотрению. Файл batcache.php - это небольшой плагин, который регенерирует кэш на статьях и страницах. Не забудьте активировать плагин в бэкенде на странице плагина!
Проверьте правильность работы Memcached в WordPress
Теперь давайте убедимся, что все действия были выполнены как нужно. Самым простым способом подтвердить то, что генерируемая страница выдаётся из кэша, станет добавление дополнительного поля заголовка к ответу.Чтобы это сделать, нужно изменить файл advanced-cache.php. Откройте его и найдите строку
var $headers = array();
Замените её на:
var $headers = array("memcached" => "activated");
Откройте инструменты разработчика в своём браузере (F12 для Crhome), выберите вкладку «Network» и перезагрузите страницу несколько раз, чтобы быть уверенным, что страница грузится из кэша, и проверьте ответные заголовки. Если вы видите поле memcached - у уас всё получилось!
Обратите внимание, если вы вошли (залогинились) в административную панель сайта на WordPress, кэширование не будет задействовано и система всегда будет отдавать незакэшированную версию страницы. Каким образом проверить функциональность кэша в этом случае? Разлогиньтесь или откройте новую вкладку браузера в режиме «Инкогнито» и используйте инструменты разработчика в браузере.
Вместо изучения заголовков можно проверить исходный код загружаемой страницы. На то, что страница была загружена из кэша, указывают следующие строки:
Проведём стресс-тест вместе с Blitz.io
Мы можем провести нагрузочное тестирование с помощью стресс-теста, симулирующего множество одновременных посещений ресурса на протяжении определённого времени. Если ваш сервер не защищён от повышенной нагрузки, он начнёт отвечать медленнее до тех пор, пока не сможет больше обрабатывать запросы. Если Memcached активирован, сервер продержится дольше и не будет выдавать ошибок.
Давайте запустим некоторые тесты на загрузку и производительность с помощью сервиса Blitz.io.
Отметим: для этого стресс-теста использован небольшой сервер с одним CPU и 500Мб памяти.
Стресс-тест без использования Memcached
Результат БЕЗ использования Memcached:
Результат такой же, как у стресс-теста Varnish. Как видите, пришлось прекратить стресс-тест, так как сервер не смог обрабатывать запросы быстрее 5 секунд при 50 одновременных подключённых пользователях. Всего лишь через 15 секунд сервер полностью перестал отвечать на запросы.
Стресс-тест WordPress и включённый Memcached
Как видите, Memcached позволяет сохранять стабильность работы сервера даже под высокой нагрузкой. Маленький тестовый сервер выдержал болше 400 одновременных запросов и дольше 50 секунд без каких-либо ошибок. После 50 секунд и почти 450 одновременных пользователей сервер всё-таки перестал принимать дальнейшие запросы. На более мощной конфигурации эти цифры были бы значительно выше.
Таким образом, использование Memcached - отличная идея для тех, кто хочет большей устойчивости к нагрузке. При помощи этой системы даже можно обезопасить сайт от небольших атак. Для защиты сервера от настоящей ДдоС-атаки (Distributed Denial of Service - атака на отказ в обслуживании) следует использовать сервис CloudFlare, Куратор или аналогичные системы фильтрации.
Заключение: WordPress отлично работает с Memcached
Memcached может значительно улучшить производительность сайта на WordPress и снизить нагрузку на CPU вашего сервера. Он прост в установке и работает «из коробки».Перевод: Антон Ларгин (Русоникс)
Оригинал.
Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление ресурсов процессора вашим аккаунтом превысило суточную норму , установленную тарифным планом.
В письме от провайдера, как правило, сообщаются:
- пункт Договора/Правил, который был нарушен;
- суть нарушения;
- текущее состояние аккаунта;
- предлагаемые меры, которые клиенту необходимо выполнить для возобновления предоставления услуги.
Выявляем причину повышения нагрузки на хостинг
Первое, что необходимо сделать, это понять основную причину, по которой возрасла нагрузка на ЦП.
1. Нагрузка на CPU из-за неоптимальной работы скриптов или неоптимизированной базы данных
Оптимизация CMS: Отключите неиспользуемые и тяжелые плагины CMS, настройте кэширование посредством CMS (для WordPress например можно использовать WP Super Cache или WP-cache.com).
Оптимизация базы данных: Запросы к MySQL, которые выполняются более 0,5 секунд, часто создают избыточную нагрузку на дисковую систему сервера и на его процессор. Проверьте логи медленных запросов к БД (можно запросить у хостера) и выполните оптимизацию структуры БД, а также почистите её от неактуальной информации.
2. Избыточное число запросов к сайту
Повышение нагрузки на CPU может быть свидетельством большого количества запросов от поисковых и иных роботов, или, особенно при скачкообразном резком росте - свидетельством DDOS-атаки или Brute-Force атаки.
Проверка источников запросов: откройте лог-файл со статистикой запросов по User-Agent - из него вы сможете понять, какие роботы с какой периодичностью обращаются к вашему сайту (например YandexBot, bingbot). В логах со статистикой по IP-адресам проверьте, не идёт ли с каких-либо IP огромный поток обращений (если да, то возможно это атака на сайт). Узнать больше информации про IP (кому он принадлежит) можно при помощи сервисов Whois.
Настройка ограничения для роботов : Настройте файл robots.txt: установите таймаут обращения роботов к вашему сайту при помощи директивы Crawl-delay:
Для отдельного бота:
User-agent: bingbot Crawl-delay: 10 # задает таймаут в 10 секунд только для бота bingbot
Или сразу для всех ботов:
User-agent: * Crawl-delay: 10 # задает таймаут в 10 секунд для всех поисковых роботов
Настройка ограничений по IP-адресам: Для блокировки доступа по IP добавьте в файл.htaccess, находящийся в корневой папке сайта, следующие строки (в примере ниже блокируем доступ к сайту для IP-адресов 121.123.123.123 и 121.122.122.122):
Order Allow,Deny Allow from all Deny from 121.123.123.123 Deny from 121.122.122.122
3. Реальное увеличение посещаемости ресурса
С развитием сайта посещаемость его растёт, и чем выше посещаемость, тем больше нагрузка на CPU. В случае перехода порога посещаемости в 10000 уникальных посетителей в сутки на обычном виртуальном хостинге сайту будет однозначно тесно и необходимо переносить его на выделенный сервер.
4. Слабый хостинг
Довольно часто уже при количестве посетителей более 1000 у пользователя возникают проблемы с превышением нагрузки на хостинг. При этом оптимизация сайта и ограничения для роботов не дают особого эффекта и с хостинга продолжают приходить уведомления о превышении нагрузки. Скорее всего, ваш сайт превзошёл возможности оборудования провайдера - в этом случае лучше сразу сменить хостинг на более качественный. Мы уже сталкивались с подобной проблемой на хостинге reg.ru и других, и после перехода на новый качественный хостинг , и проблема исчезла.
После проведенного анализа рынка услуг виртуального хостинга был найден наиболее оптимальный вариант по соотношению Цена/Качество. Рекомендуем бесплатно попробовать этот хостинг , и перейти на него (при заказе введите промо-код сайт и получите скидку 10% на услуги хостинга ).
Прошел период примерно в 30 дней, в работе сайта больше проблем нет и высокая нагрузка на сервер, процессор больше не наблюдается. Теперь следует рассказать как мне удалось справиться с периодической высокой нагрузкой WordPress на процессор и сервер.
Все началось совершенно спонтанно и с каждым днем ответ сервера становился все более долгим. Затем в один прекрасный момент в панели webmaster Yandex, появилось соответствующее критическое уведомление. В котором был указан долгий ответ сервера практически на 40 — 50 страницах сайта. Все по-порядку.
Содержание статьи:
Высокая нагрузка создаваемая WordPress сайтом на серверный процессор CPU — основные симптомы этой проблемы
На моем сайте проблема возникала совершенно спонтанно и в разные временные периоды. Толчком 100% нагрузки на CPU сервера становились переходы между страницами сайта. Примерно на 2-й странице, возникал резкий скачек в работе процессора сервера. Хочется заметить, что в этот момент оперативная память практически не имеет колебаний. А количество процессов совершенно незначительно и не должно так пагубно нагружать серверный процессор.
Основные характерные признаки нагрузки, которые встречаются у многих вебмастеров:
- Повышение лимита нагрузки процессора на хостинг-сервере.
- WordPress начал создавать недопустимую нагрузку на CPU.
- Пиковые значения, жесткая перегрузка процессора на хостинге.
- Долгий ответ сервера, варьируемое значение колеблется от 5 до 30 секунд.
- Чрезмерная нагрузка происходит спонтанно, в разные временные периоды.
- Происходит заторможенность сайта, страницы практически не загружаются или этот процесс проходит очень долго.
- Сайт в пиковых пределах крашится.
- WP создает долгий ответ сервера, сайт работает не стабильно. В пиковых скачках CPU, оперативная память работает в штатном стабильном режиме.
- Количество затронутых и исполняемых процессов в периоды скачков минимальны.
- Потоковое пакетное обращение и задействованные соединения на nginx или apache минимальны.
- Данная аномалия проходит несколько раз в день, в разные промежутки времени. Заканчивается также быстро, как и началась.
Это именно то, что происходило с моим сайтом в течении месяца. Наглядным примером будут следующие изображения:
Как видите количество задействованных процессов минимально. Оперативная память удерживается в стабильном значении, с учетом открытого браузера и огромного количества страниц. А вот все ядра CPU работают в критической нагрузке, изначально причину понять вообще невозможно.
Какие методы я перепробовал в борьбе с критической нагрузкой на CPU
Самое банальное, я грешил на плагины WP и нехватку памяти. Хотя так по-честному, движок использует всего 16 мб памяти из допустимых 512 мб которые я выделил. Что собственно я пробовал:
- Провел полное обновление Debian, затем почистил всю систему.
- Удалил 99% сохраненных ревизий баз данных на VestaCp.
- Раз двадцать просматривал конфигурационные файлы в VestaCp на наличие ошибок.
- Нашел в почтовом сервере Exim большое количество системных логов (полностью удалил).
- Проверял сайт на наличие вирусов (отсутствуют).
- Делал трассировку до сайта, проверял скорость интернет соединения.
- На сайте отключил сохранение ревизий записей, большего на сайте не предпринимал. Сайт оптимизирован под 98% смысл его проверять.
После всех проделанных действий, проблема не решилась. В течении месяца скачки и пиковые критические нагрузки WP на процессор сервера продолжились.
В чем собственно заключалась проблема чрезмерной нагрузки WP на CPU, и как я ее решил
Проблема заключалась в ошибке WP Cron (крона). Месяца четыре назад я устанавливал плагин, который запрещает обновляться движку, темам и плагинам. Первым звонком по моим пониманием, были ошибки в серверных логах сайта адресованные wp-cron.php. Ошибка заключалась в выделении памяти на процесс, а точнее нехватки памяти. Когда я вспомнил про эту ситуацию, то сразу обратил внимание.
Что мне помогло:
- Я установил плагин WP Crontrol — планировщик задач wp cron. Советую установить его сразу, очень хорошее решение.
- После установки, я увидел картину в пиковую нагрузку из примерно 900 идентичных событий, которые как я понимаю касаются изображений.
Самое простое решение обнулить все события wp cron до изначального состояния, делается это в functions.php. Достаточно вставить в самом начале файла под
В результате все 900 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:
Надеюсь эта статья Вам пригодиться и поможет. Если возникнут вопросы пишите в комментариях или в личку.
