Привет. После попыток взломать один из моих сайтов, об этом я писал в статье , все было как-то спокойно, нагрузка на хостинг стала нормальной и проблем не было. Но в один прекрасный момент, захожу я в панель 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, так же большое спасибо.
Почти все мои сайты работают на самописных движках, но до недавнего времени один из них все еще сидел на столь распространенном сейчас 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 находится на лидирующих позициях?Может из-за своей простоты?
В этом месяце неожиданно нарисовалась очередная проблема с сайтом. Совсем недавно , а сейчас увеличилась нагрузка на сервер хостинга 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. Про создание автоматической резервной копии базы .
Если после проведения всех работ нагрузка на сервер остается по-прежнему повышенной и не связана со взломом, значит нужно оптимизировать код веб-проекта или искать вредоносный скрипт.
В следующий раз расскажу о сказочном способе максимального ускорения загрузки блога, так что подписывайтесь на обновления в форме ниже под статьей и получите всё сладкое самыми первыми.
На самое сладкое видео с заманчивым названием.
Привет, привет. Зачастую блоггеры и веб-мастера сталкиваются с такой проблемой, что рано или поздно их проекты начинают жутко тормозить. Значительно повышается нагрузка на 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-адресов, которые я сумел собрать за некоторое время. Именно их и нужно будет заблокировать.
