niakrisn

1 — Каждый процесс апача потребляет 4Гб виртуальной памяти — это очень плохо, а потребляет её скорее всего какой-нибудь opCacher типа xcache или apc или что-то подобное, не поленитесь изменить настройки на более разумные.
2 — Высокий показатель system usage говорит о том, что львиную часть CPU цыклов тратит ядро (в Вашем слючае это 88.4%), следовательно это может быть любая логика работающая в ядре будь то драйвер/пакетный фильтр/дисковая подсистема/сетевая подсистема/etc.

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

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

Простейший вариант это добавить директиву debug_connection BOT_IP; в контекст events и посмотреть отладочный лог.

Может быть потому, что $ban равен 11?

if ($http_user_agent = 'Mozilla\/5\.0 \(Windows\; U\; Windows NT 6\.1\; en\-US\)') {
        set $ban $ban$add;
}

Тут не нужно экранировать.

Всем спасибо, решение подсказали выше.
Предварительно обратился к поисковику и нашел только такой вот этот вариант, он показался слишком сложным, поэтому и задал вопрос.

У меня тут товарищ мучился, только поднял виртуалку и по привычке пингует яндекс…
Ковырял настройки пока я не сказал, что яша лежит.

Точняк, запинговали досмерти :)

Что-то факап как-то тихо проходит)

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

Но в реальности означает немного другое и конкретные цифры сказать трудно, все относительно.

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

Проблемы с производительностью обычно делятся на следующие:
— Проблемы с системой ввода-вывода (сетевая подсистема, дисковая подсистема и в т.ч. сам http-сервер, etc.)
— Проблемы с архитектурой приложения.

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

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

Очень часто заливают всякие shell'ки, поэтому особое внимание в приложении следует уделить именно тем местам где происходит upload контента на сервер.

У VMware сейчас одна копия ESXi халявная, но с некоторыми ограничениями. Вроде не более 4vCPU на виртуалку.

Если задача в том, чтобы php отправить на backend, а статику отдать с диска, то поможет try_files:

location / {
try_files $uri $uri/ @php;
}

location @php {
...
}