- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет
Помогите разобраться
Есть сайт на wordpress с посещаемостью около 20 000 человек в день.
Сайт на VPS (Gentoo Linux 4×1000 МГц и 2048 оперативной).
Сайт уже 3 года работает без каких-либо изменений в настройках на VPS сервере, никаких проблем не было, выдерживал нагрузку и 40 и 60 тысяч в день. Для снижения нагрузки на wordpress поставлен плагин Hyper Cache.
С недавних пор начали появляться ошибки к примеру
Вот что ответил хостер:
resource held maxheld barrier limit failcnt
kmemsize 22657075 33556099 33554432 33554432 3027
privvmpages 502096 530560 524288 524288 22975435
numtcpsock 107 1000 1000 1000 326451
tcpsndbuf 1055240 8839584 8388608 12582912 433392194
Столбец failcnt здесь - число неудачных попыток выделить ресурсы для процессов.
Причиной превышения может быть как разовое увеличение нагрузки (например индексирование поисковиками или пиковая посещаемость), так и общая перегруженность Вашего VPS.
Для решения данной ситуации следует оптимизировать работу скриптов или сменить тарифный план на более высокий из текущей тарифной линейки VPS.
Пиковой нагрузки на сайт не было, раньше нагрузки вообще было больше, никаких действий с сайтом вообще не производилось, кроме разве что обновления версии вордпресс до последней
Прошу помощи знающих людей.
Спасибо
Сравните ваши лимиты с другими хостерами, например тарифы ихц на vps, и их лимиты. Тариф с 1Гб памяти там имеет большие лимиты, чем вы.
Смнить хостера с большими лимитами, это конечно решение
Но хотелось бы найти суть проблемы, так как лимиты хостера не менялись, а нагрузка снижалась.
В логах ошибки следующего типа:
Причем что характерно за последние несколько дней ошибка
повторилась почти 2000 раз, а за все 3 предыдущих года возникала раз 50 не больше.
Тебе ответили: "разовое увеличение нагрузки (например индексирование поисковиками".
Проверь, может разные боты (не только гул и яндекс) присосались к сайту, и сосут его кровь.
А вообще, не вижу проблем чуток доплатить и увеличить параметры vps (cpu+mem)
Причина в хостере, он оверселлит, меняйте его на незажравшегося.
Но хотелось бы найти суть проблемы, так как лимиты хостера не менялись
Вы проверяли их раньше? Они обозначены на сайте или в договоре? Лучше спросите поддержку, почему у других хостеров OpenVZ с 512Mb имеет большие лимиты, чем ваш с 2Гб.
Причина в хостере, он оверселлит, меняйте его на незажравшегося.
Если текущие лимиты не ошибка, то это самое правильное решение.
кроме разве что обновления версии вордпресс до последней
вы сами ответили на свой вопрос :)
вордпресс уже не торт...
Будет ли решением увеличить память в php.ini с 128 до 512?
Раньше не проверял, но сейчас обозначены в приложении к договору, с 2013 года не менялись.
вы сами ответили на свой вопрос :)
вордпресс уже не торт...
Тоже есть такая вероятность, но ошибки стали возникать не сразу после обновления.
А как это сделать?😕
Вроде нашли проблему. В custom_log более 65 000 собщений
за сутки, то есть брутфорсят через xmlrpc.php, уязвимость 2014 года в вордпрессе, отсюда и нагрузка, сейчас отключил
Да, уязвимость Wordpress и Drupal
Анализ логов тем же grep и Вы бы сами все поняли.
Данной уязвимостью очень легко воспользоваться, так как эксплоиты в общем доступе уже давно.
Вроде нашли проблему. В custom_log более 65 000 собщений
за сутки, то есть брутфорсят через xmlrpc.php, уязвимость 2014 года в вордпрессе, отсюда и нагрузка, сейчас отключил
Ну вот, теперь будешь знать, что если нагрузка выросла, а кол-во посетителей нет, то нужно мониторить access_log