Jump to content

FreeBSD hi loading CPU


Recommended Posts

Было похожее давно, решилось блокировкой портов 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 трафик.

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

Edited by L1ght
Link to post
Share on other sites
  • Replies 249
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

2 KaYot    

Загалом про "сервер падає від пінгу", дуже нагадало  

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

Posted Images

Посмотрите в сторону 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.

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

 

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

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

 

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

Link to post
Share on other sites

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

 

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

deny_in - мастхев

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

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

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

Edited by major12
Link to post
Share on other sites

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

 

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

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

 

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

 

 

My NAT box dies when session count is near 45k

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

Link to post
Share on other sites

 

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

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

 

znimok_ekrana_z_20140523_01_37_15.png

 

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

Link to post
Share on other sites

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

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

 

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

 

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

:blink:

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

Link to post
Share on other sites

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

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

 

У мене

#define LINK_TABLE_OUT_SIZE        40009
#define LINK_TABLE_IN_SIZE         40009
 

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

Link to post
Share on other sites

 

Кількість слотів в 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

 

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

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

Edited by nightfly
Link to post
Share on other sites

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

 

/* 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М сесій, навіщо чистити.

Link to post
Share on other sites

 

 

Кількість слотів в 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 */

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

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

Link to post
Share on other sites

 

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

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

 

 

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

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

Link to post
Share on other sites

 

 

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

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

 

 

Точно точно.

 

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

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

 

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

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

Ефективно !

 

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

Link to post
Share on other sites

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

sos.zip

Edited by BARVIT
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • By a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • By mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • By FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • By rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan2="vlan 2 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan2_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я внес это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...

×
×
  • Create New...