zzzit, Volumetric Attacks: Attempt to consume the bandwidth either within the target network/service , or between the target network/service and the rest of the Internet. These attacks are simply about causing congestion.
Т.е. если на твой IP прилетает тонна трафа, всё равно где-то есть общая точка отказа - фильтрующее горлышко. Собственно, зависит именно от того, где именно происходит фильтрация.
600 подключений с _одного_ IP это заведомо не легитимный трафик. Можно было 600*10 организовать, в том и дело. Собственно, почему дальше и смотреть не стал: я серьезными DDoS не занимаюсь, а от школьников защищаться вполне себе научился. На самом деле, можно найти какую-нибудь тяжелую страничку (для генерации) и запросить её 600 раз... Будет не особо приятно.
zzzit, Учите матчасть, что такое атака Denial Of Service. Я вчера тот самый сайт, с которого началось про датагруп, держал в оффлайне с одного (!) ноутбука с мобильным (!) подключением. Т.е. кто-то там ездил по ушам? Так же и датагруп ездит по ушам, 500 Гбит это теоретически возможная, но не используемая мощность, до неё нужно дорасти - да, такая вот штука.
И вообще, если к вашему сайту идёт запрос из китая через Вашего провайдера, то как вы его сможете не принять через внешний аплинк? Хватит ересь нести, честное слово.
izmir, 600 sockets - это я, да.
Т.е. на некоторых задачах можно наблюдать и LA 300-400 и при этом система не остановится и не помрёт, например, если мы сделаем make kernel -j100 - получим LA ~80 (ну не сможет оно в 100 потоков обрабатывать, ибо некоторые вещи должны быть выполнены последовательно) и дикий расход памяти (30-60 Gb), но при этом система не упадёт и не остановит выполнение задач. А вот если это веб-сервер, клиент может просто не дождаться ответа странички и закрыть вкладку браузера (более 3 секунд - финита ля комедия), а в логах этого зафиксировано не будет - система завершит возложенную на неё задачу. Но нагрузка не постоянная во времени штука и может так получаться, что вот сейчас клиенты смотрели странички с задержкой в 1 секунду, LA подрос, а потом посещаемость снизилась и всё продолжает работать в штатном режиме без последствий, пока пик посещаемости не станет слишком сильным.---------- Добавлено 23.09.2015 в 21:19 ----------
Если затык только по одному из ресурсов.
Я говорю у пропускной способности памяти. Оно просто не забито до отказа. Проц забит, а память не совсем, т.е. 1 от проца, 0.25 от памяти, 0.5 от диска к примеру.---------- Добавлено 23.09.2015 в 21:21 ----------
Пиковая нагрузка держится 3-4 часа, дальше - спад.---------- Добавлено 23.09.2015 в 21:23 ----------Опять же, откуда берётся замечательная 4-ка? 1 - собственно, сам процессор + 1 - ввод-вывод в память +1 ввод-вывод на диск +1 ввод-вывод в сеть, выше - почти гарантированные проблемы.
Переформулирую ответ, более упрощенно:
У Вас сайт с посещаемостью 100 человек в час. LA при этом = 1. Посещаемость выросла, стало 130 человек в час LA=1.15 - выросло число потоков, они обрабатываются медленнее, но примемлемо для клиентов. Т.е. через час человек уйдет в любом случае, на его место придёт новый, количество обрабатываемых процессов неизменно, но это не означает, что они все не успевают выполняться (!), так как для их выполнения используются разные ресурсы (один процесс жрёт CPU, второй - диск, третий - сеть, в итоге LA=3, хотя процессор загружен только одним процессом). НО, если LA поднимется выше какого-то значения, когда ресурсы системы будут утилизированы полностью, произойдет лавинообразный скачок и сервер рухнет в отказ в обслуживании.
Не обязательно. У вас же там не только апач, а еще другие сервисы. Прошелся по хабре. Лично как я понимаю - для сглаживания используется экспоненциальная функция (с целью не бить тревогу при кратковременных пиках). По поводу I/O противоречия со своими словами не вижу, т.к. часть процессов может ожидать какой-то другой процесс, выполняющий I/O и откровенно простаивать. Например, апач не выкидывает 503 сразу же - у него есть очередь на это, т.е. клиент может и подождать высвобождения потомка.
Вообще, как показано в статейке на хабре со ссылкой на исходники ядра - процессы учитываются только RUNNING и UNINTERRUPTABLE - т.е. те процессы, которые не ожидают сами ресурсов или не выполняются - в расчете не учитываются. По моему опыту LA=5 на ядро положит систему до непотребного состояния в большинстве случаев, если нагружают процессы со средним приоритетом.
Вообще же, лично я склонен учитывать не только дисковую подсистему как ввод-вывод в данном контексте, но и оперативную память, правда она влияет на загрузку SYSTEM.
Тот же веб-сервер, обрабатывая в 2 раза больше кликов не будет нагружать систему в 2 раза больше по той причине, что все необходимые процессы уже запущены и апач не будет прибивать старый процесс и форкать новый, а использует уже существующий. Не будет повторных обращений к дискам/ОЗУ, т.к. все данные содержатся в кэше процессора или не будет дергать диск, т.к. данные уже закешированы в ОЗУ. На практике, LA больше 1 на ядро означает замедление работы каждого отдельного потока, но не означает понижение производительности системы и не означает отказ в обслуживании. И увеличение посещаемости в 2 раза не означает, что будет использоваться ресурсов в 2 раза больше.
Таким образом мы приходим к выводу, что LOAD AVERAGE это, скорее, не показатель нагрузки/каких-то проблем, а показатель _оптимальности_ использования системы, т.к. большее число потоков лишь замедляет выполнение вычислительных задач, но не означает отказ в обслуживании.
Работающих. Про ожидающих выполнения я наврал, именно работающих, выполняющихся в текущую единицу времени. Не знаю, как настроен Ваш веб-сервер, но вообще при компиляции в 4 потока LA=4 с копейками. Сколько потоков - столько и LA. Отказы в обслуживании клиенты не получают, т.к. либо увеличивается время обработки запроса, либо растёт очередь процессов, но система не запускает дополнительные потоки ввиду настройки. Где-то читал, что нормальная LA - 4 на одно ядро процессора. Отдельно еще смотрится на I/O, т.к. LA может быть почти нулевым (это нагрузка на процессор), а I/O уже может не вывозить.
Да, это, конечно, всё выглядит здорово, но на практике всегда есть узкое горлышко, в каждом случае оно своё. Есть развитость инфраструктуры в целом, и учитывать её можно только по каким-то косвенным признакам. Можно озадачиться соответствующими расчетами, можно много и долго спорить, но применительно к данному случаю я хоть и упростил, но оно на самом деле так. Украина - не Европа и развитость инфраструктуры там ниже... На несколько порядков. Таки дела. Вообще, суммарная мощность аплинков и мощность аплинков любого в отдельности - разные вещи... Я говорил о самом мощном прове в стране, если уж он не тянет - тогда ой...
Load Average - число процессов, ожидающих выполнения в единицу времени. Т.е. число работающих процессов _одновременно_. Веб-сервер обрабатывает гораздо больше одного запроса в секунду.
