Превышение лимита CPU - снижаем нагрузку на хостинг. Высокая нагрузка WordPress на CPU — процессор, сервер и хостинг

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

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

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

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

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

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

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

1
Мысли хорошие, но они есть у всех. Хотелось бы прочитать вазможное решение проблем с разгрузкой БД изменяя параметры движка
2
Основное направление в существенной оптимизации wordpress - кеширование на стороне сервера. Почитать это вы, я думаю, сможете в других многочисленных блогах. У меня же сейчас нет ни одного сайта, построенного на wordpress, и соответственно я не могу описать решение проблем с оптимизацией.
3
Всегда в сети говорили, что ВП лёгкий, и я верил, хоть и использую по жизни Drupal. Потом в сентябре у меня появился заказчик, с желанием «Съехать с этого глючного ВП нах на друпал». Оказалось следующее:
1. Сайт крутился на VPS 500Mhz и 384 рамы
2. Посещаемость около 1000 хитов в сутки.
3. Включены все мыслимые и немыслимые кеши.
Вся эта система стабильно раз в сутки падала, в остальное время безбожно тормозила. Начался суровый и кропотливый процесс переезда на друпал, в итоге:
1. Все материалы перетянули.
2. Где урлы устраивали, оставили их, где не устраивали, сделали новые урлы, на старые 301 редирект.
3. Переехали абсолютно без потерь. С той же функциональностью, а в некоторых местах даже больше.
Сейчас загрузка сервера по процессору в самые жесткие моменты, когда приходит Гоша и Яша не превышает 30 процентов, с отключенным кешированием.
Так что, подумайте о друпале, не так он хренов, как все говорят.
Вот пациент - surlaterre.ru
4
Ничего против Друпала не имею, хорошая система. Основная моя претензия - в современных движках нет простой системы переезда с другой CMS с сохранением старой системы ЧПУ.
5
Если взять тот же переезд с ВП, то существующий модуль переносит вместе с ВП-шными урлами, но я переносил своим модулем, у меня несколько иначе было всё
6
Если тот или другой модуль сумеет перенести любой вид адреса, который можно создать с помощью стандартных средств Wordpress - честь и хвала ему, +1 к друпалу, но когда я искал подобное среди движков ничего не нашел или находил, но реализовано было далеко не все.
7
В общем могу сказать: «Ничего не переносимого нет», если тема интересна, то велком в аську/почту/скайп. Контакты на моём сайте
8
Не знаю как у вас был настроен WordPress, сервак и кеши. Но у меня на обслуживании стоят сайты на WP у которых на виртуалках посещалка 4000 в сутки и ни каких проблем. Есть сайты с посещалкой на 10 000 в стуки, но на приватах. Там нагрузка не превышает 10% в пиках. Так что WP рулит еще как!
9
Я сейчас осваиваю MovableType. Эта CMS несмотря на необычность (используется perl, генерит статические html), очень легкая и достаточно функциональная. Быстрее WP в разы.
10
MovableType хорош, но информации на русском о нем все же мало.
11
Я лично вообще не могу разобраться какая там эта нагрузка. У меня крупных проектов WP ни когда не было и проверить я это сам не могу. А где бы я ни почитал, дак ни чего не поймешь одни говорят wp-рулит, другие говорят что фигня движок. А вообще какая все таки нагрузка и и какую wp может выдержать я ни где не встречал. Остается один вопрос почему тогда wp по зоне ru находится на лидирующих позициях?Может из-за своей простоты?

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

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

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

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

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

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

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

; charset=" />

Нет, удалять его, конечно же, не надо, но вот немного видоизменить, убрав не нужные обращения к БД, можно:

Ну вот, два запроса в минус — пустячок, а приятно. Дальше — больше. Что еще можно заменить или удалить в HEADER? Давайте перечислим:

Удалить строку с информацией о номере установленной версии WordPress . Она не несет никакой полезной нагрузки и, более того, является опасной, т.к. некоторые варианты взлома применимы только к определенным версиям, а из этой строки как раз очень удобно узнавать текущую версию вашего движка. Выглядит эта строка обычно так: " />
Заменить URL до вашего файла таблицы стилей CSS в вашей текущей теме оформления на статический. В коде это строка: " type="text/css" media="screen" />

WP Tuner устанавливается на WordPress стандартным способом, а именно:

распакуйте архив, используя ftp-менеджер подключитесь к вашему блогу и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере хостинга
войдите в админку и выберете вкладку «Плагины»- «Inactive»
найдите строку с плагином WP Tuner и активируйте его

Если при установке плагина WP Tuner у вас возникли какие-либо затруднения, то можете обратиться к материалам статьи, про решение возможных проблем с установкой плагинов. Теперь можно зайти в админку и ознакомиться с настройками этого расширения (из левого меню выбрать Параметры -> WP Tuner.

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

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

Обычные посетители блога, естественно, этого безобразия, внесенного WP Tuner, видеть не будут, только администратор, т.е. вы.

Но посмотреть число запросов к базе в WordPress можно и не прибегая к услугам плагинов . Для этого нужно получить доступ к файлам вашего блога по FTP и открыть на редактирование, например, файл:

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

и где-нибудь в его содержимое нужно вставить следующую конструкцию (место вставки будет определять область вывода числа запросов к БД в футере):

queries in seconds.

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

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

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

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

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

Привет. После попыток взломать один из моих сайтов, об этом я писал в статье , все было как-то спокойно, нагрузка на хостинг стала нормальной и проблем не было. Но в один прекрасный момент, захожу я в панель ihc.ru и открыл вкладку «Нагрузка» что бы посмотреть как там обстоят дела, и честно говоря офигел немного. Нагрузка на CPU уже превысила допустимую, и это было только утро.

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

Я сразу подумал, что сейчас хостинг отключит мои сайты. У меня в этой панеле, только один посещаемый сайт, примерно 10000 просмотров страниц в сутки, это не мало, для виртуального хостинга за 400 рублей в месяц. Но всегда нагрузка была примерно на середине, если допустимо на CPU 120, то у меня было 70.

Сел я писать в поддержку ihc письмо, объяснил ситуацию. Ответ пришел очень быстро, впрочем как и всегда. Написали, что за разовое увеличение нагрузки никто сайт отключать не будет, хууу, успокоили. Так же указали на сайт, который создает большую нагрузку и указали один IP адрес, который ведет себя очень странно и делает очень много запросов к сайту. Так же посоветовали проанализировать файл логов домен_access.log .

Тот IP адрес, который они указали, я сразу же заблокировал в файле .htaccess в корне сайта. Просто добавив строчку deny from **.***.***.** . И стал ждать, что на этом все закончиться и нагрузка на хостинг упадет.

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

На следующий день, вчера, нагрузка CPU на хостинг увеличилась еще больше при допустимых 120 было 300. И я решил, что нужно все таки разбираться в этих логах, и начал просматривать файл домен_access.log, который выкачал по FTP с хостинга. Большой такой файл, открыв его блокнотом, что-то там понять было сложно. Тут мне пригодился мой любимый Notepad++, там все отображалось с новой строчки, короче все как положено.

Долго я смотрел этот файл, там отображается IP адрес, время запроса, тип запроса и т. д. Посмотрел и закрыл. Сегодня утром проснулся, пошел смотреть что там с нагрузкой, она уже превышала допустимую. Решил, что нужно разбираться. Снова открыл лог сервера и начал внимательно его смотреть. Заметил несколько IP, с которых даже ночью очень активно шли запросы на сайт. Причем, за секунду могло быть более 10 запросов, к одной и той же странице сайта. И таких запросов было очень много. Все IP, которые мне показались странными я заблокировал в.htaccess.

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

После блокировки тех IP нагрузка вроде устаканилась. Ночью, когда IP еще не были заблокированы, нагрузка была заметна, а вот уже сегодня днем вроде все нормально.

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

Что касается самого хостига ihc.ru в этом деле, то мне кажется, что они молодцы. Во первых, сайт с десятью тысячами просмотров в сутки на виртуальном хостиге за 400 рублей в месяц, мне кажется, что это круто. За помощь в решении проблем с нагрузкой и поиском этих IP, так же большое спасибо.

Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?

Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 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 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.

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

Прошел период примерно в 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 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:

Надеюсь эта статья Вам пригодиться и поможет. Если возникнут вопросы пишите в комментариях или в личку.