Высокая нагрузка создаваемая WordPress-блогом на сервер и крайне несуразное решение этой проблемы

Обновлено 29 января 2024 Просмотров: 159 765 Автор: Дмитрий Петров

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru.

Хочу поделиться с вами небольшим нюансом из жизни этого блога. Расскажу предысторию. Начиная с весны 2015 года у меня на повестке дня стоит одна и та же техническая проблема — периодически (несколько раз в день) на сервере , где расположен блог KtoNaNovenkogo.ru (и еще один сайт, который тоже работает на WordPress), нагрузка на память и процессор достигает 100%.

В этот промежуток времени (где-то около получаса) админка выдает 502 ошибку, а для посетителей сайт хоть и доступен, но страницы открываются довольно медленно (от 5 до 15 секунд). Если бы кеширование на блоге не использовалось, то и они бы выдавали 502 ошибку. Помогает только либо двукратная перезагрузка сервера, либо тупое ожидание пока все само собой рассосется.

WordPress блог на сервере

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

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

Эпизодически запредельная нагрузка WordPress на сервер

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

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

Однако, после традиционного «мы это делать не должны, но все же сделаем» ребята из техподдержки сказали, что судя по всему Ддоса нет (хотя какую-то фильтрацию агрессивных IP они все же настроили на всякий пожарный). Нагрузку же, по их мнению, генерит сам сайт. Правда, через несколько лет меня все же по настоящему атаковали и защититься помог лишь CloudFlare (спасибо ему за это).

Я же им отвечал, что в обычном режиме нагрузка крайне низкая, ибо на обоих WordPress блогах установлен плагин Hyper Cache с 10 дневным периодом обновления закешированных страниц. Собственно, в Parallels, который используется в Инфобоксе, есть панелька, где нагрузку на сервер по процессору и памяти можно отслеживать в реальном времени. Обычно там довольно идеалистическая картинка отображается:

Нагрузка на сервер

Но несколько раз за сутки эти значения вырастают до 100% (самый затык начинается, когда память забивается на все 100) и сайт даже со стороны посетителей начинает еле ворочаться. Техподдержка на протяжении всего периода моих обращений к ним что-то пыталась предложить, мониторили сервер в течении нескольких суток и ничего особо не замечали такого, на что можно было бы повлиять и «сделать всем нам хорошо».

Из того, что запомнилось перечислю:

  1. Меняли во все стороны значение максимального числа подключений (так и не понял чего это такое), но все без толку. По-моему, даже при увеличении этого числа сайт со стороны посетителей в момент высокой нагрузки тупил еще сильнее.
  2. Повышали тарифный план (на пару недель в тестовом режиме — без доплаты) с моего Linux VPS-2048 до 4 гигов оперативки и двойного увеличения процессорной производительности. Как ни парадоксально, но баги со 100% нагрузкой не только остались, но и приводили практически к полной недоступности сайта для посетителей (не смотря на кеширование), ибо страницы открывались по минуте. Поэтому экстренно все вернули взад.
  3. Переводили с обычного виртуального сервера (типа контейнер) в облако. Ничего не поменялось, разве что перегружаться сервер в этом режиме стал существенно дольше. Поэтому вернули опять же все взад.

Я уже сам своим куцым умишком стал думать, что может служить причиной этой неприятности. Пробовал играться с настройкам Хипер Кеша — отключал кеширование на лету, еще с какими-то непонятными мне галочками эксперименты проводил. Кстати, по ходу дела сделал отзывчивый дизайн для блога и сумел таки добить техподдержку Инфобокса, чтобы они мне в nginx кеширование статичных элементов в браузерах пользователей настроили. Но все это ожидаемо не принесло ровным счетом никаких подвижек в решении проблемы с эпизодически высокой нагрузкой на сервер.

Пришло в голову, что на эти периоды мой блог мог подвергаться брутфорсу (автоматическому перебору паролей для доступа в админку). Чтобы не возиться в htaccess и вручную не прятать файл авторизации, решил поставить плагин, который как раз препятствует брутфорсу — Login LockDown. Вроде он сейчас видит несколько попыток в час подбора пароля и пресекает их, но на «зависоны» это опять же никак не повлияло.

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

Собственно, в силу того, что перепробовано было уже все, что только могло прийти в голову мне или тем, кто писал на эту тему в интернете (в меру моих скромных умственных способностей, конечно же), верить в «чудо» я уже перестал и оно, как водится, пришло совершенно нежданным.

Как удалось решить проблему (надеюсь, что окончательно)

Все началось с того, что несколько дней назад что-то сподвигло меня посмотреть на исходный код одной из страниц своего блога. Дело это весьма полезное, ибо в шапке (между тегами Head) WordPress имеет дурную привычку пихать совершенно лишние метатеги и служебные гиперссылки link, которые могут ухудшать отношение поисковых систем к сайту.

За примерами долго ходить не надо — совсем недавно обнаружил там такую гадость, что волосы дыбом встали. Об ее обнаружении и удалении даже отдельный пост написал (хотя тема уже всплывала довольно давно, но я ее не воспринял тогда серьезно) — Проблема с All in One SEO Pack и ее решение.

В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:

Три новых служебных ссылки в шапке WordPress 4.4

Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

В общем, сие пока решил отложить до прояснения ситуации и появления рецептов «купирования ненужных отростков». Да, опять же, если в теме, то расскажите, ибо сильно эти ссылки меня раздражают. Хотя бы для чего они нужны и не несут ли какого диструктива в продвижение блога. Но тут я пока отступил.

Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:

Отображение эмодзи смайликов в WordPress

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал про коды эмодзи смайликов, которые можно использовать для их вставки. Чуток погуглил и убедился, что таки да — этот код помогает отображать на страницах WordPress эти самые эмодзи смайлики.

Так как emoji смайлы у меня выводятся от силы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров в файлик функшион.пхп из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

Это вариант самого полного отключения поддержки эмодзи в WordPress. Хотите в админке оставьте. Все, после этого наступило приятное чувство чистоты кода от всяко разного.

На тех страницах, где я эмодзи все же использовал, пришлось чуток подправить текст. Я просто открыл эти статьи на редактирование в админке и прямо в самом начале (в Html редакторе, а не в визуальном) добавил этот самый код, который удалил из шапки всех страниц:

<script type="text/javascript">
			window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":".png","source":{"concatemoji":"http:\/\/ktonanovenkogo.ru\/wp-includes\/js\/wp-emoji-release.min.js?ver=4.4"}};
			!function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data[0])):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings);
		</script>
		<style type="text/css">
img.wp-smiley,
img.emoji {
	display: inline !important;
	border: none !important;
	box-shadow: none !important;
	height: 1em !important;
	width: 1em !important;
	margin: 0 .07em !important;
	vertical-align: -0.1em !important;
	background: none !important;
	padding: 0 !important;
}
</style>

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

Как пришло осознание

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

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

Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).

Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Комментарии и отзывы (26)

Евгений Вершинин

отображать на старницах WordPress эти самые эмодзи смайлики.

^^^^^^^^^

Бросилось в глаза орфографическая ошибка. Но за статью спасибо. На своих сайтах отключу.

seoonly.ru

Спасибо за код!

Хрюндель

Не проверял, может это бот какого то поисковика тебя мучает и создает такую нагрузку? У меня как то была проблема с байду, который клал мой впс регулярно. В конечном итоге я просто запретил его в htaccess

Дмитрий

Евгений Вершинин: спасибо, поправил.

Хрюндель: накануне как раз изучал возможности блокировки левых ботов, но на практике так и не попробовал. Если проблемы возобновятся, то буду в эту сторону смотреть. Спасибо.

Елена

Добрый день!

Боюсь лезть в код ибо чайник:( Этот эмодзи, который мне тоже без надобности, можно отключить в админке одним кликом, не ковыряясь в коде?

Вообще подобные баги — не редкость:( Столкнулась месяц назад с неприятной ситуацией, решить которую не могу по сей день, веду лишь бесконечную переписку с хостером Таймвэб с одной стороны и с Яндексом с другой. У Таймвэба полетел сервер, на котором расположены два моих сайта, проблему в течении часа устранили, но с того момента на обоих сайтах заглючила метрика: стала выдавать стопроцентный нулевой аптайм, якобы сайты недоступны в принципе. Это безобразие продолжается по сей день: Таймвэб катит бочку на Яндекс, Яндекс на Таймвэб, а посередке я — в роли мячика, такой вот печальный футбол получается:)

Наверно, тоже надо нестандартное решение поискать, но, как говорит Задорнов, «соображалки» моей не хватает. Единственное, что приходит в голову: может, хостера сменить? Хотя, где гарантия, что не сменяю в итоге «часы на трусы»? А без реальных данных по аптайму тяжко, тк я не смогу вовремя увидеть, если реально что-то произойдет и оперативно среагировать. Сторонних сервисов полно, но Яндекс всегда оповещал о перебоях с сайтами, теперь эта функция недоступна для меня.

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

Андрей

На скорую руку проверил, не обнаружил ничего, только тот самый код, который приведен в последнем скрине. С праздниками Всех!

Владимир

Я системный администратор и немного понимаю, как работает сервер, но никак не могу понять, как смайлики могут приводить к таким проблемам 🙂

Если проблема все же вернется, то рекомендую посмотреть логи самого сервера, веб сервера, отдельно посмотреть логи cron, проверить, нет ли каких-либо подозрительных заданий в cron или планировщике at.

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

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

Если проблема вернется и вы решите с ней бороться, можете обратиться ко мне. Емейл остался в комментарии. Я не анонимус, у меня есть свой блог, помогу бесплатно, пообщаемся по скайпу. Мне любопытны такие ситуации. Раньше приходилось решать похожие проблемы.

AlexZsoft

У меня тоже такая беда была, помогло перераспределение хеширования с apatch на nginx. И от он сео пак отказался, т.к. много лишнего генерирует и в плагине p3 показывает повышенную нагрузку. Поставил seo by yoast, пол года полёт нормальный. Так же избавился от всех плагинов, которые можно заменить кодом и полностью почистил сервер от логов и темпов. Было забито 700мб, сейчас 200мб оперативки. 7 сайтов, один из которых 3000 человек в день.

Дмитрий

Только что зашел на сайт, с 4 попытки. 502 выдавалась.

Андрей

Была подобная проблема с высокой нагрузкой 2 года назад. Решил за несколько недель упорного труда. Сейчас самая высокая нагрузка не превышает 6-8 ср. Посещалка 3.5-5.5 т. в сутки. Два сайта. Всё решилось после тщательного анализа логов, поисков разных решений в интернете и прописывания потом нескольких строчек в .htaccess. Виноваты были то ли боты, то ли взломщики, которые набирали некорректные адреса страниц (постоянно в течении нескольких часов с небольшими перерывами) и принуждали сервер генерировать 404 (никакие кэши не спасали) и ещё ломились в админку с разных IP. Но бОльшую нагрузку оказывали 404.

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

AlexZsoft

Кстати смените адрес входа в админку wp-login.php, а то стандартный стоит.

Леся

Есть классный скрипт кеша для ВП от MaxCache — решает все проблемы с нагрузкой ВП, уверяю вас. Не реклама, пишу искренне, мне помог решить подобную проблему — с нескольких секунд загрузки (доходило и до 10-15 сек.) уменьшил время до 0.22 доли секунды. И нагрузка на сервер просто исчезла, стала минимальной, я перешла даже на более дешёвый тариф хостинга ). Недавно были всплески посещаемости сайта до 23к — не тормознул ни разу.

Alex

На моем сайте тоже wp 4.4, но кода emoji нет и нет ссылок в head. Причем, я ничего не редактировал. Нагрузка у меня тоже повышенная, борюсь с ней блокировкой ботов

Макс

Аналогично, обновился до WordPress 4.4.1 и стала реально высокая нагрузка.

При обычных 15-20 процессорных минут. Уже 3 дня выдает под 60 процессорных минут. Ищу откуда ноги растут и как решить проблему...

Denis

1. Воспользуйтесь плагином P3 Profiler,

https://wordpress.org/plugins/p3-profiler/

Этот плагин замерит время выполнение всех установленных плагинов на вашем WordPress. Соответственно самые тормозные можно будет заменить на более быстрее аналоги.

2. Установите плагин CleanTalk и включите в нем опцию SpamFireWall. Это снизит нагрузку на CPU,

https://wordpress.org/plugins/cleantalk-spam-protect/

SpamFirWall фильтрует спам-ботов и скан-трафик до загрузки страницы/создания SQL запросов в БД, что и позволяет снизить нагрузку на сайт в приделах 5-30%.

vpsadm.ru

На самом деле сайт ваш открывается довольно-таки быстро, по ощущениям. Правда, сейчас глубокая ночь. Но Google Pagespeed Insights всё же показывает, что у вас для картинок стоит слишком малое время кэша в браузере на клиентах. Поставьте время кэширования хотя бы несколько дней и google даст сайту «зеленую» оценку.

Что касается 502-й ошибки — это «bad gateway». Её генерирует веб-сервер nginx, который у вас стоит перед Apache. Она означает, что этот самый апач не успевает отвечать на запросы. Это устаревшая схема — nginx+apache, которая имеет мало смысла. Дело в том, что вебсервер nginx очень быстрый и производительный. Он может выдерживать колоссальные нагрузки в десятки тысяч запросов в секунду. Но nginx обрабатывает только html, он не умеет выполнять php-скрипты. Поэтому позади него устанавливают апач, который по сравнению с ним очень медленный но имеет модули для обработки php. Кэширующие плагины помогают тем, что они сохраняют результат выполнения скриптов, на какое-то время в виде статичного HTML. Это хорошее решение для обычных страниц, которые видят пользователи, но админку кэшировать нельзя, поскольку там сплошная динамика. Поэтому она всегда обрабатывается апачем. Соответственно, когда он слишком нагруже, то возникает 502 ошибка.

Другими словами, у вас «шасси» наибыстрейшее, но «двигатель» его не может разогнать и «чихает» 🙂

К счастью, это всё решаемо. Нужно просто убрать апач, заменив его на альтернативный обработчик php-fpm (fastcgi). В связке с nginx он работает в разы, а иногда и на порядок быстрее. При этом используя в 2-5 раз меньше ресурсов сервера, как памяти, так и процессора. 502 ошибка при этом вряд ли будет появляться, даже если у вас возрастёт посещаемость, админка тоже будет всегда работать быстро.

Кроме того, у вас установлен nginx версии 0.8.4. Это очень старая версия от июня 2009 года. Текущая версия 1.8-1.9. А этот вебсервер развивается очень быстро. За эти годы сменилось несколько десятков версий, исправлены баги, добавлены функции, он сейчас совсем другой. Судите сами: http://nginx.org/ru/CHANGES.ru . Его нужно обновлять.

Shtirlitz

Привет. Тоже ломал пару дней голову, что за супер-нагрузка пошла на сайт, не помогали фильтры, блоки, Cloudflare. Тут неожиданно вышел на инфу, что в новой версии WP есть завязка на некую вирт.директорию wp-json и поисковики шлют своих ботов индексировать нечто виртуальное, в общем погуглишь — увидишь и проблему и решение.

Вверху страницы есть даже упоминание этого json, но без конкретики, так что делаю посыл к этому.

Ольга

Интересно бы узнать, как Андрей решил вопрос с ботами и взломщиками, которые набирали некорректные адреса страниц и принуждали сервер генерировать 404? У меня такая же ситуация сейчас и не только это, еще есть какие-то запросы к несуществующим файлам. В техподдержке моего хостинга рекомендуют установить на сайт какое-нибудь расширение, повышающее безопасность, либо обрабатывающее неким образом запросы к несуществующим страницам сайта. Но для меня это темный лес...

Андрей

Ольга, моя почта arumbis@gmail.com. Постараюсь помочь.

Владимир

Здравствуйте, вы упоминали в статье про строки кода в коде сайта, но ни слова, как убирали это:

<link rel="alternate" type="application/json+oembed" ...

<link rel="alternate" type="text/xml+oembed" ...

Буду благодарен, если добавите в статью...

Дмитрий

Владимир: Здравствуйте! Посмотрите тут писал вроде про это: Как убрать служебные ссылки с WP-JSON из исходного кода страниц вашего блога на WordPress

Владимир

Спасибо, Дмитрий, позднее через интернет попал на эту страницу 🙂

Артур

Просто нужен был плагин disable-json-api.1.3 . И все. Смайлы не причем тут. Сам тестирую vds сижу. Кстати, интересно сколько посещаемость может быть на 1 озу , процессор 2 на 2,7?

Андрей

Спасибо! Код попробовал и замерил результаты до... и после. Было — 120ср в сутки стало 36 ср. в сутки. Снижение нагрузки налицо! Сайт летает.

W&P

Еще в настройках плагина WP Fastest Cache v 0.8.8.8 есть галочка «Отключить эмодзи — Убирает CSS и JavaScript, необходимые для поддержки эмодзи».

Ваш комментарий или отзыв