Значительно выросла нагрузка на сервер

InstantCMS 2.X

Как снизить нагрузку?

#1 1 июля 2024 в 23:44

На сайте установлено дополнение «Защита и наблюдение перегрузок» — instantcms.ru/addons/loadaverage.html

Сайт существует 10 месяцев, в сентябре будет год. В последние месяцы наблюдаю значительно выросшие перегрузки. Честно говорю, что не разбираюсь в этом. Но хочется как то снизить эти показатели. Мне непонятно что именно нагружает VPS — сайт на котором установлен этот компонент или возможно какие то другие сайты / скрипты — которые установлены на этом же VPS на других сайтах. Может кто то знает как вычислить что именно нагружает систему? Или хотя бы какой сайт… Буду благодарен за любые мнения и помощь если возможно.

Основные параметры VPS такие:

VPS-NVMe
Количество процессоров: 3 Шт.
Оперативная память: 4 Гб
Дисковое пространство: 60 Гб

Изображение

#2 2 июля 2024 в 08:26

Судя по всему это нагрузка на весь сервер хостера, а не на ваш сайт. Хостер добавляет туда новых клиентов, нагрузка растет.

Чтобы видеть только свою нагрузку, надо брать vps с виртуализацией kvm.

#3 2 июля 2024 в 12:59

У меня vps с виртуализацией kvm. Помимо сайта на instantcms установлено еще 8 сайтов на других cms и фреймворке HLEB. Эти 8 сайтов с нулевой посещаемостью, можно сказать проекты в зачаточном состоянии… Есть ли возможность узнать какие сайты / скрипты грузят систему? Или они все нагружают? Где что можно посмотреть?

#4 2 июля 2024 в 21:17

Задайте это вопрос провайдеру, может они помогут определить направление. Если провайдер качественный, то вероятнее всего помогут.

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

#5 15 апреля 2026 в 08:44

Похожая проблема
Только поставил систему на хостинг (больше ничего нет) и подозрительная нагрузка идет.
Для отслеживания установил «Рабочая нагрузка на сервер» и вот что показывает отчет.
Причем каждые несколько секунд
Что может так грузить?

[2026-04-15 01:50:15.996] [Info] Фиксация факта критичной загрузки системы
{
    «load_average»: 90.7,
    «REQUEST_METHOD»: «GET»,
    «REMOTE_ADDR»: «178.128.20.61»,
    «REQUEST_URI»: "\/wp-admin\/plugins.php",
    «HTTP_USER_AGENT»: «Mozilla\/5.0 (Windows NT 11.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/119.0.0.0 Safari\/537.36»
}
Изображение

#6 15 апреля 2026 в 13:37

Что может так грузить?

Capitan

так тут очевидно. боты ищут список плагинов wordpress. Забаньте ip 178.128.20.61

#7 15 апреля 2026 в 16:52

Забаньте ip 178.128.20.61

Zau4man

Не очень пойму как и где забанить этот ip. Есть только «Запрещенные IP-адреса для регистрации» и с этого адреса ведь не пытаются зарегистрироваться

#8 15 апреля 2026 в 18:09
Забаньте ip 178.128.20.61 Zau4man Не очень пойму как и где забанить этот ip. Есть только «Запрещенные IP-адреса для регистрации» и с этого адреса ведь не пытаются зарегистрироваться
Capitan

fail2ban

#9 15 апреля 2026 в 20:16

htaccess

#10 16 апреля 2026 в 02:20

htaccess

pupsik

 от нагрузки не спасет, это уже конечная

#11 16 апреля 2026 в 07:15

Забаньте ip 178.128.20.61

Zau4man

Хм… если все идут на:

«REQUEST_URI»: "\/wp-admin\/plugins.php",

Capitan

Так может в htaccess поставить, что то типа редиректа с этой страницы на 404 или ещё куда подальше… пусть идут))

И да... 

Надо понаблюдать… может это само рассосется через какое то время… и на одну ли страницу… и один ли бот и т.д.

Может и делать ничего не надо)

#12 16 апреля 2026 в 07:39

Добавьте в .htaccess в самое начало строки типа

  1. Order Allow,Deny
  2. Deny from 178.128.20.61
  3. Allow from all

и больше с этого ip ворваться не получится на сайт. Строки

  1. Deny from 178.128.20.61
  2. Deny from 178.128.20.66
  3. Deny from 99.128.20.61

можно повторять, добавляя новые ip 

#13 16 апреля 2026 в 11:17

htaccess

pupsik

 от нагрузки не спасет, это уже конечная

kalikimaka

Не вводите людей людей в заблуждение. Сначала работает сервер, затем CMS(PHP). Если пресекать запрос на этапе сервера — это уже успех. А htaccess это директивы для сервера. 

#14 16 апреля 2026 в 11:58
htaccess pupsik  от нагрузки не спасет, это уже конечная kalikimaka Не вводите людей людей в заблуждение. Сначала работает сервер, затем CMS(PHP).
IamB

htaccess это уровень директории, никто в заблуждение никого не вводит. Очевидно, что к серверу все равно будет обращение, до директории.

я говорю про уровень до директории

от атак по http протоколу не поможет

#15 16 апреля 2026 в 16:52

Очевидно

kalikimaka

очевидно что это не конечная. Нагрузка на подключение к серверу и выполнение всего кода 404 страницы отличается в разы, если не на порядки. Такой правкой в корневом htaccess мы отсекаем, наверно, 99% нагрузки, которую ранее создавал долбящийся бот. Это отличное решение для начала.

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

Похожее в блогах

🍪Мы используем файлы cookie для работы сайта. Читать подробнее.