Wordpress большая нагрузка на сервер. Высокая нагрузка WordPress на CPU — процессор, сервер и хостинг. Выявляем причину повышения нагрузки на хостинг

Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!

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

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

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

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

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

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

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово 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 редакторе, а не в визуальном) добавил этот самый код, который удалил из шапки всех страниц:

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

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

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

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

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

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

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

посмотреть еще ролики можно перейдя на ");">

Вам может быть интересно

Пропало левое меню в админке WordPress после обновления Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка

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

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

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

Для начала вам нужно будет получить доступ по FTP к файлам вашей темы оформления. Они находятся в папке:

/wp-content/themes/название_вашей_темы_оформления

Начнем с уже упомянутого выше — HEADER . Думаю, что с Файлзилой вы уже знакомы и доступ по ФТП к хосту для вас не в новинку. Если нет, то вверху есть окно поиска и достаточно будет ввести туда слово «файлзила» или «нотепад», чтобы получить самую полную информацию по этим двум архиполезным программам.

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

queries in seconds.

В результате после загрузки страницы, в самом низу (в области подвала), вы увидите, сколько при этом было сделано обращений к БД:

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

посмотреть еще ролики можно перейдя на ");">

Вам может быть интересно

Пропало левое меню в админке WordPress после обновления
Создаем для блога на WordPress кнопки добавления в социальные сети и закладки (без плагинов и скриптов)
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации Смайлики в WordPress - какие коды смайлов вставлять, а так же плагин Qip Smiles (красивые смайлики для комментариев) Как автоматически добавить атрибут Alt в теги Img вашего блога на WordPress (там, где их нет)
Hyper Cache - включаем плагин кэширования в Вордпресс для оптимизации WP блога и снижения его нагрузки на сервер хостинга

Из этой статьи вы узнаете как значительно ускорить сайт на 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 и добавьте следующую строку:

define("WP_CACHE", true);

Важно: убедитесь, что Memcached для выбранной версии PHP включён корректно, иначе добавление этой строки вызовет ошибку!

загрузите batcache.php в директорию /wp-content/plugins.

Вот и всё! Теперь можете открыть 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 вашего сервера. Он прост в установке и работает «из коробки».

Перевод: Антон Ларгин (Русоникс)
Оригинал.

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

Такой поворот событий для меня не был неожиданностью и возможную причину знал заранее. После запроса логов у хостера догадки подтвердились. Ко всем сайтам на аккаунте подбирались пароли к админке WordPress.

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

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

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

Как уменьшить нагрузку на сервер с WordPress?

Самые вкусные файлы для взломщиков wp-login.php и wp-config.php. Для уменьшения нагрузки на сервер им необходимо уделить особое внимание, а для защиты админки следует присмотреться к следующим способам.

Первый способ. Закрыть полный доступ к wp-login.php для всех IP адресов, кроме вашего. Для защиты достаточно внести изменения в файл.htaccess. То есть доступ к админке будет разрешен только вам, у остальных будет выкидываться ошибка.

Этот очень простой способ для меня не самый удобный. Дело в том, что при подключении к интернету мне дается новый IP и для входа в админку сайта требуется сначала зайти в админку хостинга, внести мой новый IP в.htaccess и только потом перейти на блог.

Второй способ. Спрятать файл wp-login.php. Этот способ оказался для меня идеальным.

1. Переименовываем название файла wp-login.php в, например, 45jkdsf234.php . Искать файл нужно в корне сайта, корректировать либо через админку хостинга либо через .

2. Заменяем все встречающиеся слова wp-login.php на переименованные, в моем примере на 45jkdsf234.php . Изменения нужно внести в старый файл wp-login.php , который сейчас называется 45jkdsf234.php и в wp-includes/general-template.php .

Теперь вход в админку будет осуществляться не по адресу ваш-сайт/wp-login.php , а по адресу ваш-сайт/45jkdsf234.php .

3. Добавить в.htaccess перед # END WordPress такой код:

В результате у меня получился такой.htaccess:

Третий способ . Использовать плагин Login LockDown, который предотвращает попытки подбора пароля. Установка плагина банальная, поставил и забыл. По умолчанию имеется 3 попытки войти в админку в течение 5 минут, при неудачных попытках происходит блокировка по IP на 1 час.

Мне очень не хотелось ставить Login LockDown, обычно я подбираю пароль к админке раза с 5-го. Но что сделаешь, придется тренировать память, лучше так, чем постоянные взломы.

Вот так выглядит график нагрузки до и после подбора пароля:

Период взлома отчетливо виден по резким скачкам графика.

Что не помешает сделать вебмастеру для снижения нагрузки WordPress на сервер

По максимуму обезопасить админку позволит следование базовым правилам по соблюдению безопасности:

На админку стоит поставить сложный пароль;
Поменять логин admin на другое название;
В FTP-клиентах не хранить пароли и логины;
Регулярно делать back up файлов вордпресс и базы данных mysql. Про создание автоматической резервной копии базы .

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

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

На самое сладкое видео с заманчивым названием.

Почти все мои сайты работают на самописных движках, но до недавнего времени один из них все еще сидел на столь распространенном сейчас wordpress. Дело в том, что изначально wordpress был установлен из-за удобства освоения админки человеком ведущим этот сайт (не мной). Но после выхода линейки версий 2.8 я понял, что это уже не дело…

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

Я испробовал на локали большинство готовых блоговых движков и пришел к неутешительному выводу:
ни один из них (!) даже при наличии импорта из wordpress, не мог предоставить той же структуры ЧПУ (и уж тем более в автоматическом, интуитивном режиме), а это значит при переходе -> 301 редирект и непонятно какая реакция со стороны ПС в плане существующих позиций.

В итоге получилось как всегда: посмотрел сорцы wordpress, импортнул данные из существующей БД, написал небольшое подобие CMS.

Нагрузка: на MySQL снизилась в среднем в 10 раз, на проц — в 2 раза. Думается мне, что здесь есть еще где развернуться в плане оптимизации, но согласитесь даже это уже показательный результат!

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

15 Комментариев

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

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

Всегда в сети говорили, что ВП лёгкий, и я верил, хоть и использую по жизни Drupal. Потом в сентябре у меня появился заказчик, с желанием «Съехать с этого глючного ВП нах на друпал». Оказалось следующее:
1. Сайт крутился на VPS 500Mhz и 384 рамы
2. Посещаемость около 1000 хитов в сутки.
3. Включены все мыслимые и немыслимые кеши.
Вся эта система стабильно раз в сутки падала, в остальное время безбожно тормозила. Начался суровый и кропотливый процесс переезда на друпал, в итоге:
1. Все материалы перетянули.
2. Где урлы устраивали, оставили их, где не устраивали, сделали новые урлы, на старые 301 редирект.
3. Переехали абсолютно без потерь. С той же функциональностью, а в некоторых местах даже больше.
Сейчас загрузка сервера по процессору в самые жесткие моменты, когда приходит Гоша и Яша не превышает 30 процентов, с отключенным кешированием.
Так что, подумайте о друпале, не так он хренов, как все говорят.
Вот пациент - surlaterre.ru

Ничего против Друпала не имею, хорошая система. Основная моя претензия - в современных движках нет простой системы переезда с другой CMS с сохранением старой системы ЧПУ.

Если взять тот же переезд с ВП, то существующий модуль переносит вместе с ВП-шными урлами, но я переносил своим модулем, у меня несколько иначе было всё

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

В общем могу сказать: «Ничего не переносимого нет», если тема интересна, то велком в аську/почту/скайп. Контакты на моём сайте

Не знаю как у вас был настроен WordPress, сервак и кеши. Но у меня на обслуживании стоят сайты на WP у которых на виртуалках посещалка 4000 в сутки и ни каких проблем. Есть сайты с посещалкой на 10 000 в стуки, но на приватах. Там нагрузка не превышает 10% в пиках. Так что WP рулит еще как!

Я сейчас осваиваю MovableType. Эта CMS несмотря на необычность (используется perl, генерит статические html), очень легкая и достаточно функциональная. Быстрее WP в разы.

MovableType хорош, но информации на русском о нем все же мало.

Я лично вообще не могу разобраться какая там эта нагрузка. У меня крупных проектов WP ни когда не было и проверить я это сам не могу. А где бы я ни почитал, дак ни чего не поймешь одни говорят wp-рулит, другие говорят что фигня движок. А вообще какая все таки нагрузка и и какую wp может выдержать я ни где не встречал. Остается один вопрос почему тогда wp по зоне ru находится на лидирующих позициях?Может из-за своей простоты?

Печать

Также интересно:

Dark Sector: Прохождение Глава VIII: Неестественная история

Что делать если на компе нету диска D?

Как откатить или удалить проблемное обновление Windows Откат к предыдущей сборке windows 10

Рекомендуем почитать:

2023-08-11 00:02:15

Оператор для работы с наборами UNION Объединение запросов union

2023-08-11 00:02:15

IBM создала самый мощный в мире компьютер Топ 10 самых мощных компьютеров в мире

2023-08-10 00:03:18

Мы знаем далеко не все: какие социальные сети существуют в интернете Путешествия и отдых

В продолжение темы:

Windows

Компьютеры с процессором intel i5 Конфигурация тестовых стендов

Часть вторая : "Важнейшие характеристики каждого семейства процессоров Intel Core i3/i5/i7. Какие из этих чипов представляют особый интерес" Введение Сначала мы приведём...

Новые статьи