Мой сервер, который и будет героем последующего повествования - это обычный арендованный у 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 от взлома.
1) Закрываем xmlrpc.php
xmlrpc.php - это пожалуй самый ненужный файл на сайте, но при этом он часто используется для взлома сайта и создании нагрузки на него.
В файл .htaccess на вашем сайте (в корне) добавляем следующее:
Кроме этого, можно зайти в файл функции темы functions.php и вставить следующий код:
Add_filter("xmlrpc_enabled", "__return_false");
Теперь не забудьте удалить следы данной функции. Заходим в файл header.php вашей темы и удаляем строчку кода, которая содержит pingback и xmlrpc.php. Как правило эта строчка выглядит так:
2) Закрываем или ограничиваем админку
Второй причиной высокой нагрузки является подбор паролей. Хакеры пытаются взломать вашу админку, создавая тонны запросов. Ставим дополнительную защиту через тот же .htaccess файл.
2.1) Если вы единственный админ сайта с постоянным IP адресом:
Создаем в папке wp-admin .htaccess файл и вставляем в него:
Order deny,allow deny from all allow from xxx.xxx.xxx.xxx
Вместо Х пишем ваш IP адрес. В итоге, в админку сможете зайти только вы и никто больше. Даже попытаться не смогут.
2.2) Если вас не устраивает предыдущий вариант, вы просто можете дополнительно защитить вашу админку (без плагина):
В файл .htaccess в корне сайта вставляем следующее:
Сайт.ру - меняем на свой.
Создаем в корне сайта (там же где.htaccess) файл .htpasswd
В этом файле будет содержаться дополнительный логин и пароль. Данная защита осуществляется на уровне сервера, поэтому она довольно надежна. Логин и пароль желательно ставить отличный от логина и пароля на сайте.
Открываем файл .htpasswd и вставляем следующую строку:
Login:$apr1$bHEXXPPA$zhrhn9vOOr/sdsdi3
Где Login - это ваш логин, а после ваш пароль в специальном зашифрованном виде.
Чтобы сгенерировать свой пароль в таком виде, можно воспользоваться различными онлайн-сервисами, к примеру таким: htaccesstools.com .
В итоге вы получаете готовую строчку (зашифрованный пароль), которую нужно вставить в .htpasswd
Прошел период примерно в 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 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:
Надеюсь эта статья Вам пригодиться и поможет. Если возникнут вопросы пишите в комментариях или в личку.
Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?
Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 10 штук) оказывают чрезмерную нагрузку на центральные процессы хостинга и на базу данных. Повышенная нагрузка была связана частично с ddos-атакой на один мой сайт, ну и в дополнении с тем, что я размещаю сайты на этом хостинге давно уже (более 1,5 года), а никакие работы по очистке мусора с и по оптимизации баз данных не проводил. А ведь сайт можно в некоторой степени сравнить с компьютером. Если не очищать его от ненужных файлов, кряков и прочей лабуды, то компьютер будет со временем поедать и требовать больше ресурсов, что приведет к замедлениям в его работы, частому зависанию. Поэтому нужно заботливо относиться к своим сайтам и периодически проводить действия по оптимизации их работы.
Как снизить нагрузку вордпресса на хостинг и оптимизировать базу данных (MySQL)?
Я провел небольшие действия (о которых расскажу далее), которые позволили мне в результате существенно уменьшить нагрузку на CPU хостинга. Если говорить обобщенно, то удалось снизить нагрузку на CPU с 30-40 до 0,34 – 0,50, а нагрузка на базу данных уменьшить с 90 до 64-70.
В результате проведенных действий по оптимизации базы данных (MySQL) – ее размер удалось уменьшить с 227 мб до 41 мб. Как видим – удалось добиться существенных показателей. А что для этого было сделано?
Оказывает, что любые действия, проводимые в вордпрессе (будь то публикация новой статьи, будь то просто добавление нового плагина и прочее), оказывают какое-то воздействие на базу данных, увеличивая ее в размерах. А чем больше ее размеры, больше различных файлов в ней, находящихся в беспорядочном порядке – тем больше идет нагрузка на процессы хостинга. Поэтому проведя работу по оптимизации базы данных можно существенно сократить эти нагрузки.
Для оптимизации базы данных понадобиться установить и активировать плагин — Optimize DB (о том, как устанавливать плагины читать ). Далее идете в раздел «Инструменты» — находите строчку «Optimize DB» и переходите по ней. Теперь для оптимизации базы данных на вашем сайте остается только нажать на кнопку «Optimize Now».
Вот такие простые действия оптимизируют вашу базу данных на вордпрессе (так сказать упорядочивают в ней хаос и раскладывают все по полочкам).Чтобы работа этого плагина в дальнейшем не создавала дополнительную нагрузку – нужно его просто выключить. Для оптимизации базы данных на вордпрессе раз в неделю или раз в месяц заходите в раздел с плагинами, активизируйте плагин Optimize DB и проводите оптимизацию MySQL (это и есть база данных). А после снова отключайте его.
Но я не ограничился для снижения нагрузки на хостинг только работой с плагином Optimize DB. Была проведена существенная работа по борьбе со спамом. Особенно много спама накопилось на нескольких сайтах (в сумме свыше 6 тыс. штук). Говоря про спам – я имею в виду комментарии спамного характера, большое количество которых также нагружает хостинг. Удалил много комментариев ожидающих проверки (точнее, чтобы полностью их удалить – отправлял их первоначально в корзину, а потом корзину очищал), также очищал папку со спамом. В в последнее время мне существенно помогает плагин «Invisible Captcha». Благодаря нему спам мгновенно отправляется в папку со спамом, а оттуда все спамные комментарии можно мгновенно удалить, очистив эту папку.
Посоветовал бы установить еще плагин «WP Super Cache» (если он не установлен), активировать, и включить кэширование. Особенно полезен он будет, если на ваши сайты уже стало заходить много посетителей. В процессе работы я установил его еще на парочку сайтов. Благодаря кэшированию нагрузка на хостинг также уменьшается.
Вот такая была проведена работа над 10 сайтами, которая заняла у меня около 2 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.
Также стоит отметить, что чем больше на сайте на вордпрессе активировано разных – тем больше нагрузка. Поэтому используйте только те плагины, которые вам необходимы и выключайте те, которые не используете.
Привет, привет. Зачастую блоггеры и веб-мастера сталкиваются с такой проблемой, что рано или поздно их проекты начинают жутко тормозить. Значительно повышается нагрузка на CPU хостинга, а народные методы вовсе не помогает в решении. И сегодня мне хотелось бы рассказать Вам о том, что делать если тормозит сайт на WordPress и как в этом случае снизить нагрузку на сервер.
В большинстве случаев, значительные подвисания и тормоза сайта начинаются абсолютно нежданно, в связи с чем естественно начинается паника. В состоянии страха блоггеры начинают «ковырять» свой сайт, пытаясь спасти его от этой неприятной проблемы. Но чаще всего такие «спасания» заканчиваются плачевно, вплоть до сноса сайта, без возможности восстановления.
Это на самом деле очень плачевно, особенно если блогу уже не один год и на нем накопилось множество интересных и полезных статей, а цифры счетчика посещения радует все больше и больше изо дня в день. Вы бы не хотели бы попасть в такую страшную ситуацию? Тогда Вам очень повезло, мне хотелось бы прямо сейчас уберечь Вас от плохого, и научить тому, как нужно поступать в случае зависания WordPress.
Буквально пару дней назад ко мне обратился один блоггер и инфобизнесмен, которого многие прекрасно знают — Дмитрий Зверев , с просьбой посмотреть сильные подвисания его блога. Естественно я согласен, это ведь моя работа, тем более почему бы не помочь хорошему человеку? 🙂
Так вот, Дмитрий скинул мне все данные от сайта и хостинга, и я приступил к анализированию. Представьте, средняя скорость загрузки сайта составляла аж целых 13 секунд.
Жесть, не правда ли? Да что тут говорить, помимо такой «скорости», и доступность сайта хромала, порой сайт открывался через раз. Одним словом он катастрофически зависал и отказывался полноценно работать. А самое интересное заключалось в том, что при авторизации в админ-панели проблем становилось ещё больше!
Это вызвало у меня ещё больше интереса, потому что я никогда не ранее не сталкивался с подобным! «Ну что ж, попробуем, чем тяжелее — тем интереснее» — подумал я, и приступил к работе.
В первую очередь я начал анализировать активированные и смотреть какие из них больше всего нагружают сайт. Анализ я производил через плагин под названием P3. Если кому-то интересно узнать про него подробнее — подписывайтесь на обновления блога. Я обязательно напишу об этом в одной из следующих статей.
Таким образом я обнаружил 2 плагина, которые грузили блог значительнее остальных, это LeadPages и NextGEN Gallery. Но после их отключения и очистки кэша абсолютно ничего не изменилось. И тогда началось самое интересное. Я начал копать всё глубже и глубже, дабы выискать истинную причину сего безобразия 🙂
После некоторых экспериментов и проверок, я пришел к выводу, что причиной проблемы может быть хостинг. Я писал в службу поддержки Jino, но толкового ответа и помощи так и не дождался. Поэтому, оставалось надеяться только на себя и свой многолетний опыт.
И вот, спустя два дня, и множества попыток, в том числе и абсолютно бесполезных, скорость стала следующей:
И помимо этого, прекратились постоянные сбои в работоспособности и хостеры перестали жаловаться на повышенную нагрузку CPU. Ура! К чему стремился, то и получил — миссия выполнена.
Но что именно я делал и как мне удалось одержать победу? Давайте по порядку.
Снижение нагрузки на сервер
1. В первую очередь, я рекомендую прочитать Вам свою одну из первых статей по повышению скорости загрузки сайта по . В этой статье Вы узнаете как выполнить качественную оптимизацию сайта и его эффективное ускорение для полноценной работы. Так же, в этой статье я демонстрирую лучшие сервисы для проверки скорости.
Но порой этих советов бывает недостаточно, к примеру, как в случае с Дмитрием. После выполнения всех шагов по ускорению из той статьи, сайт стал открываться ещё хуже и хостеры начали буквальным образом блокировать к нему доступ из-за значительно перегруза. Поэтому, пришлось было выполнять и некоторые другие действия.
2. Зачастую тормоза появляются из-за скрипта под название WP-Cron . Данный скрипт, встроенный в WordPress отвечает за планирование задач. К примеру, размещение статей по времени, автоматическая чистка корзины, создание резервной копии с помощью плагина и т.д.
Вроде всё отлично, штука классная и всё такое, но дело в том, что Cron создаёт очень сильную нагрузку на .И порой хостинги не выдерживают такую нагрузку и блокируют доступ к сайту. В этом случае необходимо отключить данный скрипт и нагрузка значительно уменьшится.
Но стоит понимать, что действия, которые у Вас выполняются в автоматическом режиме перестанут работать, придется выполнять их вручную. Но в этом нет абсолютно ничего сложного.
Так вот, для отключения WP-Cron существует несколько способов. Дело в том, что какой-то из них (как было в моем случае) может не заработать, а другой вполне.
1 способ. Переходим в корень Вашего сайта по Ftp, например через FileZilla, и открываете там файл под названием wp-config.php и добавляем новую строчку:
Define(‘DISABLE_WP_CRON’, true);
Желательно добавить её после строки:
Define(‘WPLANG’, ‘ru_RU’);
После чего сохраняете файл и радуетесь, скрипт должен отключиться.
Но если этого не произошло, то необходимо воспользоваться следующим вариантов.
2 способ. Опять же, в корне сайта необходимо открыть файл под название wp-cron.php , найти строчку:
Ignore_user_abort(true);
и закомментировать её (отключить) с помощью двух слэшов. На выходе должно получиться вот так:
//ignore_user_abort(true);
Сохраняем файл и cron отключается.
3. Далее, необходимо включить zlib компрессию , которая позволяет значительно ускорить сайт за счет обработки и сжатия php кода. В первую очередь Вам необходимо написать хостеру и узнать включен ли у Вас функция zlib или же нет. Если подключена — отлично, если же нет — просим включить. После чего переходим в файл header.php и в самый самый верх вставляем следующий код:
Сохраняем файл и ощущаем значительный прирост в скорости.
4. После чего очень важно оптимизировать БД с помощью плагина . Переходим в админ-панель, открываем вкладку «Плагины» — «Добавить плагин» и в поиске вбиваем «WP-Optimize», нажимаем Enter и устанавливаем первый плагин.
Теперь наша база данных оптимизирована, а это ещё один плюсик в сторону ускорения сайта.
5. Теперь наша задача защитить блог от Ddos-атак , т.к. именно такие атаки зачастую и становятся причиной «сноса мозгов» сайта. Для этого, во-первых, я рекомендую установить плагин под названием iThemes Security, про его настройку я расскажу в следующей статье, а во-вторых, важно использовать блокировку подозрительных посетителей с помощью .htaccess .
Я не буду сейчас объяснять как выискивать таких подозрительных и вредоносных , потому что это тема отдельной статьи, а поделюсь с Вами списком IP-адресов, которые я сумел собрать за некоторое время. Именно их и нужно будет заблокировать.
