FreeBSD hi loading CPU

[l1ght]

Было похожее давно, решилось блокировкой портов 6881-6889 на вход с внешки. От кучи левых DHT-соединений у ipfw nat сносило крышу, проц перегружен прерываниями, всплеск LA до 200 и падение сервера.

Что говорит "ipfw nat show" в спокойное время и перед падением сервера?

Если дело в количестве трансляций ната, то ещё можно потюнить таймауты libalias в исходниках, чтобы записи быстрее отстреливались, а не висели сутки.

У меня вообще стоит правило

ipfw add 65534 deny ip from any to any

Через внешку разрешены разве что 80 и 53, и ещё пара портов на вход, но никак не 6881-6889. На выход тоже только пара правил по определенным айпи.

У меня даже icmp не разрешено из вне.

Тут разве что делать ограничение от абонов по срц-дст айпи, что бы не было одновременных конектов овер 10000+

А ещё хорошо, как-то убить utp трафик.

Вообще замечательно было б.

Відредаговано 22 травня, 2014 L1ght

[muff]

Посмотрите в сторону nat global.

Возможно нагрузка растет вследствии того, что ломятся на ваш внешний айпишник, НАТ не находит в таблице трансляций записи и создает новое входжение...

Из man ipfw:

     global  Looks up translation state in all configured nat instances.  If
             an entry is found, packet is aliased according to that entry.  If
             no entry was found in any of the instances, packet is passed
             unchanged, and no new entry will be created.  See section
             MULTIPLE INSTANCES in natd(8) for more information.

[l1ght]

Правило запрещает всё. Разрешено на вход только пару портов и то они слушаются сервисами!

Дальше влючен blackhole для udp и tcp.

[nightfly]

Правило запрещает всё. Разрешено на вход только пару портов и то они слушаются сервисами!

Дальше влючен blackhole для udp и tcp.

это тоже пофиг. deny_in для начала ткните и посмотрите на результат.

[major12]

І у мене таке було  

 

Загалом це некоректна робота  LibAlias + якийсь потужний юзер торренту або вірус.

Я навіть невеликий пост про це написав, але ненашою мовою - major12.net

 

До фрібсд-шної баги вже патч є. Отже позбільшувати хеш-таблички ну і 10к сесій на айпішку тяне без проблем.

[DemonidZe]

о интересно на патч глянуть бы.

[major12]

Добра людина з яндексу пофіксила

http://www.freebsd.org/cgi/query-pr.cgi?pr=189655

[major12]

Загалом по опціях kernel NAT

 

log - помагає при дебагу, дає статистику

deny_in - мастхев

unreg_only - іноді потрібне

не використовувати same_ports

і не використовувати global - бо буде шукати по всіх нат інстансах, а у мене їх наприклад 200+

Відредаговано 22 травня, 2014 major12

[nightfly]

І у мене таке було

 

Загалом це некоректна робота  LibAlias + якийсь потужний юзер торренту або вірус.

Я навіть невеликий пост про це написав, але ненашою мовою - major12.net

 

До фрібсд-шної баги вже патч є. Отже позбільшувати хеш-таблички ну і 10к сесій на айпішку тяне без проблем.

 

 

My NAT box dies when session count is near 45k

сурйозно шолі?

[major12]

Ага пошук у списочку в 45к елементів при 20-30 kpps грузить 1 ядро на 100%. Далі стає сумно.

За що я платив гроші інтелу !

[nightfly]

 

Ага пошук у списочку в 45к елементів при 20-30 kpps грузить 1 ядро на 100%. Далі стає сумно.

біс вас знає, чо ви всі такі якісь нещасливі

 

 

до 80-100kpps при півмульйоні трансляцій взагалі не бачу якихось драматичних проблем.

[l1ght]

Ну итог такой, вырублю нетфлоу на mpd5.

На наты deny in включить, + фиксы от nightfly.

[major12]

Певне пост погано прочитали.

При поганій хеш функції і "поганих" вхідних значеннях, хеш таблиця вироджується в простий список. А пошук по ньому сильно неефективний.

 

При нормальному ж розподілі, сесії будуть розділятись рівномірно по таблиці і халепа наступить при 40к елементів * 4к слотів у таблиці (дефолт) = при 160 М сесій на одну айпішку (інстанс нату).

[l1ght]

Ок, а что мешает скомпилить ядро с ROUTETABLES=3\4\5\10?

Если в таблицу больше не лезет, а вроде libalias именно этими таблицами пользуется.

[major12]

Ок, а что мешает скомпилить ядро с ROUTETABLES=3\4\5\10?

Если в таблицу больше не лезет, а вроде libalias именно этими таблицами пользуется.

Вибачте, але це брєд 

[nightfly]

 

Если в таблицу больше не лезет, а вроде libalias именно этими таблицами пользуется.

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

[major12]

Кількість слотів в LibAlias тюнінгується правкою

/usr/src/sys/netinet/libalias/alias_local.h

 

У мене

#define LINK_TABLE_OUT_SIZE        40009
#define LINK_TABLE_IN_SIZE         40009
 

Ну і звичайно перекомпіляція ядра.

[nightfly]

 

Кількість слотів в LibAlias тюнінгується правкою

/usr/src/sys/netinet/libalias/alias_local.h

по логіці мало би давити pps

 

 

Ну і звичайно перекомпіляція ядра.

ну та можна й просто libalias.ko модулем перегрузити на ходу

 

Зараз граюсь з редефайнами таймінгів /usr/src/sys/netinet/libalias/alias_db.c

 

#define UDP_EXPIRE_TIME

#define TCP_EXPIRE_DEAD

#define TCP_EXPIRE_INITIAL

#define TCP_EXPIRE_CONNECTED

 

є сильна підозра, що воно просто не встигає таблички чистити тай все.

Короче кажучи, чекаю ЧНН в піддослідних жертв.

Відредаговано 22 травня, 2014 nightfly

[nightfly]

до-речі, у випадку крутіння LINK_TABLE_* варто ще доганяти під них ALIAS_CLEANUP_INTERVAL_SECS.

[major12]

Тоді вже краще глянути на

 

/* Parameters used for cleanup of expired links */
/* NOTE: ALIAS_CLEANUP_INTERVAL_SECS must be less then LINK_TABLE_OUT_SIZE */
#define ALIAS_CLEANUP_INTERVAL_SECS  64
#define ALIAS_CLEANUP_MAX_SPOKES     (LINK_TABLE_OUT_SIZE/5)
 

А таймаути tcp/udp я би не чіпав.

Хоча той же лінукс розділяє UDP на UNREPLIED і ESTABLISHED що ніби трохи правильніше.

 

При нормальному розподілі воно ітак витягне 160М сесій, навіщо чистити.

[nightfly]

 

/* NOTE: ALIAS_CLEANUP_INTERVAL_SECS must be less then LINK_TABLE_OUT_SIZE */

на те як-би й натякав.

 

 

А таймаути tcp/udp я би не чіпав.

пф-ф-ф - no pain, no gain.

[major12]

 

 

Кількість слотів в LibAlias тюнінгується правкою

/usr/src/sys/netinet/libalias/alias_local.h

по логіці мало би давити pps

pps не задавиш. Прийшло 100к пакетів і піти має 100к. І так наприклад кожну 1 секунду.

От коли не вистачить проца - тоді ппс і просяде.

 

А от оперативки такий тюнінг розміру табличок, в 10 раз більше зжере

 

 

/* NOTE: ALIAS_CLEANUP_INTERVAL_SECS must be less then LINK_TABLE_OUT_SIZE */

на те як-би й натякав.

Старий я вже, не встигаю тайпати

[nightfly]

 

pps не задавиш. Прийшло 100к пакетів і піти має 100к. І так наприклад кожну 1 секунду.

нісагласєн - більша таблиця / повільніший пошук по хешах. Дешевше чистити рєзче.

 

 

А от оперативки такий тюнінг розміру табличок, в 10 раз більше зжере

значить симметрично треба крутити усілякі нмбкластерс

[major12]

 

 

pps не задавиш. Прийшло 100к пакетів і піти має 100к. І так наприклад кожну 1 секунду.

нісагласєн - більша таблиця / повільніший пошук по хешах. Дешевше чистити рєзче.

 

 

Точно точно.

 

Більша хеш таблиця == швидший пошук, за рахунок меншої кількості елементів в 1 слоті.

По таблиці пошук не йде. Там 1 раз виконується функція яка визначає номер слоту (фактично індекс у масиві). А далі звертання до М[0] чи до M[100500] відбувається за той самий час.

 

В маленькій таблиці в 1 слот попаде 10 елементів і треба буде ще пошукати в списку з 10 елементів.

В великій таблиці в 1 слот попаде 1-2 елементи. Якщо 1 елемент, то берем його зразу. Якщо 2 - то або вгадали або перескакуємо на наступний елемент списку і берем його.

Ефективно !

 

Платимо оперативкою, купуємо швидкодію.

[BARVIT]

Может кот посмотрит, снимал WireShark-ом с внешнего интерфейса. 3 файла, 1 - во время падения, 2 - перезагрузка и снова падение. 3 - перезагрузка и все заработало.

sos.zip

Відредаговано 23 травня, 2014 BARVIT