Рейтинг:0

Огромная загрузка ЦП при большом количестве TCP-соединений

флаг tr

При большом количестве TCP-подключений одно ядро ​​ЦП всегда будет загружаться до 100%. После этого вся виртуальная машина начнет отставать, и произойдет очевидная потеря пакетов.

Есть ли способ решить эту проблему, заставить TCP-соединения использовать меньше ЦП или даже ограничить его скорость?

ПРИМЕЧАНИЕ. Ограничение скорости через iptables не работает. Пробовал следующее:

iptables -A INPUT -i eth0 -m state --state NEW -p tcp -m limit --limit 30/min --dport 25565 -j ACCEPT

iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 25565 -j DROP

Обратите внимание, что даже удаление порта с помощью iptables -A INPUT -p tcp --dport 25565 -j DROP не будет работать.

Под htop я не вижу, какой процесс использует ЦП, поэтому я предполагаю, что это что-то с ядром. Некоторые хостинг-провайдеры, такие как OVH, решили эту проблему, но у многих других это происходит. Каковы мои варианты?

С уважением

Doug Smythies avatar
флаг gn
Вы столкнулись с DDOS-атакой (распределенный отказ в обслуживании)? Дайте нам больше деталей. Для чего вы используете порт 25565? Сервер майнкрафт? Были ли ваши правила тестирования iptables применены в правильном месте по отношению к другим вашим правилам, чтобы быть эффективными? Используйте `sudo iptables -xvnL`, чтобы посмотреть, сколько пакетов прошло по вашим тестовым путям. Какая версия убунты?
OpenSource avatar
флаг tr
Предполагаемым использованием действительно будет обратный прокси-сервер MC, однако во время тестирования порт был открыт с Ubuntu 20.04, и под ним не работала служба (хотя результат тот же, даже если он закрыт через IPTables). Единственное правило, которое я применил во время тестирования, было: iptables -A INPUT -p tcp --dport 25565 -j DROP. Даже если этот порт полностью закрыт, большое количество подключений заставляет виртуальную машину использовать 100% ЦП. Контрольный показатель в основном представляет собой бот-атаку с 20 тыс. CPS, поскольку мы планируем развернуть обратный прокси-сервер на этом порту, что означает, что он должен обрабатывать много CPS. Однако, даже если ничего не развернуто
OpenSource avatar
флаг tr
Он просто начнет лагать и использовать 100% одного ядра процессора.
OpenSource avatar
флаг tr
https://hastebin.com/soneqonivo.apache
OpenSource avatar
флаг tr
Я использовал его только один раз, так как тестировал его раньше, но надеюсь, что этого будет достаточно. Я вижу 11040 ACCEPT и 746778220 DROP.
Doug Smythies avatar
флаг gn
Пакеты имеют соответствующие номера 186/12488841 ACCEPT/DROP. Ваше приложение довольно экстремально.
waltinator avatar
флаг it
Проводной или беспроводной? Ваш MTU (`ip l | grep $(ip r | awk '/default/ {print $5}' ) | awk '{print $2, $4, $5}'`) слишком велик? MTU беспроводной сети должен быть 1492 (8-байтовый заголовок PPPOE), в противном случае вы получите фрагментацию и повторную сборку пакетов, которые могут съесть процессор.
Doug Smythies avatar
флаг gn
@waltinator: это полностью SYN-пакеты по 60 байт каждый. Я не думаю, что фрагментация пакета SYN возможна.
Рейтинг:2
флаг gn

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

Я провел следующий эксперимент:

Серверный компьютер 1: используйте hping3 для генерации пакетов SYN со скоростью 28 870 пакетов в секунду (получено экспериментально и считается достаточно близким к тому, что вы делаете) для порта 25565 на серверном компьютере 2. Используемая команда:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 s19

Где «s19» — это серверный компьютер 2, а «u20» имеет накладные расходы и фактически дает 28 870 пакетов в секунду вместо 50 000.

Серверный компьютер 2: имеет одно правило DROP iptables. Также был запущен Turbostat для наблюдения за нагрузкой на питание и процессор. Эти команды были запущены:

doug@s19:~/tmp$ sudo iptables -xvnL ; спать 10 ; судо iptables-xvnL
Цепочка INPUT (политика ACCEPT 0 пакетов, 0 байтов)
    pkts bytes target prot opt ​​in out source target
 2293479 91739160 DROP TCP -- br0 * 0.0.0.0/0 0.0.0.0/0 состояние NEW TCP dpt: 25565

Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка OUTPUT (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target
Цепочка INPUT (политика ACCEPT 0 пакетов, 0 байтов)
    pkts bytes target prot opt ​​in out source target
 2582175 103287000 DROP TCP -- br0 * 0.0.0.0/0 0.0.0.0/0 состояние NEW TCP dpt: 25565

Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка OUTPUT (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target

Итак, 2582175 - 2293479 = 288 696 пакетов за 10 секунд или 28 870 пакетов в секунду. Примечание. У меня меньше байтов на пакет, чем у вас, 40, тогда как у вас, кажется, 60.

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Busy% Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
0,61 4800 196262 38 17,91 17,25 0,00 0,89
0,61 4800 196844 38 17,95 17,29 0,00 0,89
0,60 4800 197409 39 18,01 17,35 0,00 0,89

Незначительная загрузка ЦП, но используется примерно на 16 ватт больше, чем в режиме ожидания (в простое = 1,5 Вт).

Настольный компьютер 1: Виртуальная машина qemu/kvm 20.04, работающая в качестве гостя на сервере 2.

Команда server computer 1 hping3 становится следующей:

$ sudo /usr/sbin/hping3 -p 25565 --syn --interval u20 192.168.111.19

И результаты таковы:

doug@desk-ff:~$ sudo iptables -xvnL ; спать 100 ; судо iptables-xvnL
Цепочка INPUT (политика ACCEPT 117 пакетов, 9384 байта)
    pkts bytes target prot opt ​​in out source target
 2086906 83476240 DROP TCP -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 состояние NEW TCP dpt: 25565

Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка OUTPUT (политика ACCEPT 73 пакета, 9116 байт)
    pkts bytes target prot opt ​​in out source target
Цепочка INPUT (политика ACCEPT 144 пакета, 12151 байт)
    pkts bytes target prot opt ​​in out source target
 4970267 198810680 DROP TCP -- enp1s0 * 0.0.0.0/0 0.0.0.0/0 состояние NEW TCP dpt: 25565

Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт)
    pkts bytes target prot opt ​​in out source target

Цепочка OUTPUT (политика ACCEPT 77 пакетов, 9996 байт)
    pkts bytes target prot opt ​​in out source target

Итак, 4970267 - 2086906 = 288 361 пакет за 100 секунд или 28 834 в секунду.

и на главном компьютере:

$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,RAMWatt,GFXWatt,CorWatt --interval 6
Busy% Bzy_MHz IRQ PkgTmp PkgWatt CorWatt GFXWatt RAMWatt
9,61 4800 207685 58 31,19 30,53 0,00 0,89
9,64 4800 211088 58 31,14 30,48 0,00 0,89
9,44 4800 202499 59 30,72 30,07 0,00 0,89

У меня 12 ЦП, поэтому загрузка 1 ЦП превышает 100%. Или через топ:

топ - 11:58:16 вверх 10 дней, 18:57, 2 пользователя, средняя загрузка: 1.00, 0.99, 0.81
Задания: всего 239, 1 бег, 238 сон, 0 остановлено, 0 зомби
%Cpu0: 0,3 мкс, 0,0 си, 0,0 ни, 99,7 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu1 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu2 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu3 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu4 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu5 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu6 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu7 : 0,0 мкс, 0,0 си, 0,0 ни, 100,0 ид, 0,0 ва, 0,0 привет, 0,0 си, 0,0 ст
%Cpu8: 0,0 мкс, 0,0 си, 0,0 ни, 98,3 ид, 0,0 ва, 0,0 привет, 1,7 си, 0,0 ст
%Cpu9: 0,0 мкс, 3,1 си, 0,0 ни, 95,6 ид, 0,0 ва, 0,0 привет, 1,4 си, 0,0 ст
%Cpu10: 8,3 мкс, 90,3 си, 0,0 пн, 0,0 ид, 0,0 ва, 0,0 привет, 1,3 си, 0,0 ст
%Cpu11 : 0,0 мкс, 0,0 си, 0,0 ни, 98,3 ид, 0,0 ва, 0,0 привет, 1,7 си, 0,0 ст

Итак, да, то, что вы делаете это на виртуальной машине, похоже, потребляет гораздо больше ресурсов ЦП.Один из вариантов — не делать этого на виртуальной машине. Или назначьте виртуальной машине больше виртуальных процессоров. Мне удалось достичь 118 283 пакетов в секунду (опция интервала u1 для hping3), при этом общая загрузка ЦП на хосте увеличилась всего на пару процентов.

РЕДАКТИРОВАТЬ: Использование хост-процессора в сравнении с пакетами в секунду для виртуальной машины довольно интересно с ответом типа ступенчатой ​​функции между 5000 и 6000 pps (напомним, что 8,33% - это 100% 1 ЦП для этого хоста с 12 ЦП):

введите описание изображения здесь

Ответить или комментировать

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