Перейти до

Нужен совет. разница в загрузке сетевых карт.


Рекомендованные сообщения

Собственно нужен совет почему так. Сервер доступа

 

nas1# uname -a
FreeBSD nas1.freebit.net.ua 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon Feb 28 16:44:20 EET 2011	 root@:/usr/obj/usr/src/sys/GW1  amd64

 

top

 

last pid: 37271;  load averages:  4.50,  4.09,  4.04	up 8+22:04:20  20:49:07
93 processes:  10 running, 64 sleeping, 19 waiting
CPU 0:  0.0% user,  0.0% nice, 86.9% system,  0.0% interrupt, 13.1% idle
CPU 1:  1.1% user,  0.0% nice, 71.9% system,  2.2% interrupt, 24.7% idle
CPU 2:  0.0% user,  0.0% nice, 88.0% system,  0.4% interrupt, 11.6% idle
CPU 3:  0.0% user,  0.0% nice, 98.9% system,  0.0% interrupt,  1.1% idle
Mem: 97M Active, 222M Inact, 387M Wired, 496K Cache, 213M Buf, 1269M Free
Swap: 4096M Total, 4096M Free
 PID USERNAME PRI NICE   SIZE	RES STATE  C   TIME   WCPU COMMAND
  31 root	  43	-	 0K	16K CPU1   3  76.0H 100.00% em1_rx0_0
  32 root	  43	-	 0K	16K CPU3   3  75.9H 100.00% em1_rx0_1
  52 root	 -68	-	 0K	16K CPU0   0  57.3H 79.20% dummynet
  28 root	  43	-	 0K	16K RUN	2  28.8H 35.06% em0_rx0_1
  27 root	  43	-	 0K	16K RUN	2  28.7H 34.08% em0_rx0_0
  13 root	 171 ki31	 0K	16K RUN	1 141.8H 19.87% idle: cpu1
  14 root	 171 ki31	 0K	16K RUN	0 137.2H 14.99% idle: cpu0
  11 root	 171 ki31	 0K	16K RUN	3 148.7H  9.57% idle: cpu3
  12 root	 171 ki31	 0K	16K RUN	2 148.2H  9.28% idle: cpu2
  25 root	  16	-	 0K	16K WAIT   2  86:10  0.49% swi16: em0_tx
  29 root	  16	-	 0K	16K WAIT   2  68:41  0.20% swi16: em1_tx
  15 root	 -32	-	 0K	16K WAIT   2  44:03  0.00% swi4: clock sio

 

netstat

 

nas1# netstat -w 1 -I em1
		input		  (em1)		   output
  packets  errs	  bytes	packets  errs	  bytes colls
 40666	 0   44254186	  32107	 0   14221668	 0
 49197	 0   55682789	  37641	 0   16396562	 0
 44485	 0   48322297	  36170	 0   16606659	 0
 45383	 0   50147857	  35391	 0   15767698	 0
 45216	 0   50519446	  35909	 0   16312963	 0
 40484	 0   43262800	  32715	 0   15026413	 0
 48581	 0   53982411	  37243	 0   16785994	 0
 45070	 0   49937292	  34785	 0   14310229	 0
 44536	 0   48234034	  35932	 0   15545967	 0
 39957	 0   44142618	  30854	 0   14000010	 0
 47833	 0   53703541	  36880	 0   16720709	 0
 40925	 0   44266040	  33159	 0   15606619	 0
 40695	 0   43765070	  33473	 0   16464586	 0
Terminated

 

 

не могу понять почему такая разница в загрузке между em0 и em1

Нагрузка может как резко возрасти и держаться 10-20 минут и так же резко упасть, а может держаться несколько часов. Зависимости от трафика - нет, от количества нат-сессий - нет.

Ссылка на сообщение
Поделиться на других сайтах

Это нормальная нагрузка dummynet?

Происходит тоже самое, загрузка обоих ядер, примерно по 20%.

В какой то момент становится 100%, при это основное съедает em0 em1 и думминет.

Количество сессий не увеличивается, а трафик наоборот проседает где то в двое.

Через 5-10 минут становится нормально. Замечал только вечером.

Ссылка на сообщение
Поделиться на других сайтах

Это нормальная нагрузка dummynet?

 

в час пик примерно варьируется от 75% до 85% загрузка ядра дамминетом

Ссылка на сообщение
Поделиться на других сайтах

Разная загрузка ядер сетевками нормальна, в конце концов на определенных интерфейсах делается NAT и висят шейперы. Хотя и при чистой маршрутизации загрузка не будет одинакова, для одного интерфейса трафик будет входящим, для другого соответственно исходящим, тут даже большая таблица маршрутизации будет нагрузку давать.

Use linux.

Ссылка на сообщение
Поделиться на других сайтах

хочу понять из-за чего нагрузка прыгает, потому как ни от кол-ва трафика, ни от кол-ва нат-сессий зависимости не выявлено

Ссылка на сообщение
Поделиться на других сайтах
netstat по em0 покажи и pciconf -lv по em0/1 и строчки из /var/run/dmesg.boot

 

nas1# cat /var/run/dmesg.boot | grep em0
em0: <Intel(R) PRO/1000 Network Connection 7.0.5.Yandex[$Revision: 1.36.2.18 $]> port 0xb880-0xb89f mem 0xfe880000-0xfe89ffff,0xfe860000-0xfe87ffff irq 16 at device 0.0 on pci2
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:15:17:dd:ae:aa

 

nas1# cat /var/run/dmesg.boot | grep em1
em1: <Intel(R) PRO/1000 Network Connection 7.0.5.Yandex[$Revision: 1.36.2.18 $]> port 0xbc00-0xbc1f mem 0xfe8e0000-0xfe8fffff,0xfe8c0000-0xfe8dffff irq 17 at device 0.1 on pci2
em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:15:17:dd:ae:ab

Ссылка на сообщение
Поделиться на других сайтах
nas1# netstat -rn -w 1 -I em0
	    input		  (em0)		   output
  packets  errs	  bytes    packets  errs	  bytes colls
 25213	 0   12586606	  28658	 0   29978624	 0
 23660	 0   11539790	  26694	 0   27633029	 0
 25347	 0   12529685	  29450	 0   30304285	 0
 23951	 0   11767550	  27367	 0   29334973	 0
 25036	 0   11867269	  28971	 0   30350787	 0
 23865	 0   11434590	  27306	 0   28303030	 0
^C
nas1# netstat -rn -w 1 -I em1
	    input		  (em1)		   output
  packets  errs	  bytes    packets  errs	  bytes colls
 31890    13   33789866	  24868	 0   11741858	 0
 28751   202   29007400	  25854	 0   10833367	 0
 29152	 0   30046458	  24894	 0   11865775	 0
 27887   230   26777592	  25047	 0   11932990	 0
 26262   243   25698303	  23609	 0   11588575	 0
 27260    24   26345664	  24899	 0   12537882	 0
 27922   161   26952451	  25179	 0   13356213	 0
 24545   128   23895555	  22204	 0   11552069	 0
 25897   200   24306051	  23347	 0   11608749	 0
 30283	 0   31397391	  25752	 0   12096021	 0
 27373   144   28623039	  23409	 0   10844988	 0
 27382   212   26848753	  23184	 0   11546985	 0
 24484   186   23841766	  22264	 0   11142167	 0
 27718    47   26607481	  24297	 0   12500195	 0
 25328   203   25256775	  22316	 0   11244390	 0
 24403   116   22586359	  22705	 0   11538911	 0
 28069    12   28240113	  23536	 0   12128392	 0
^C

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

вот например, трафик выше в 2 раза, чем в предыдущем посте и ошибок нет и проц не в полке

 

nas1# netstat -w 1 -I em1
		input		  (em1)		   output
  packets  errs	  bytes	packets  errs	  bytes colls
 59802	 0   72918188	  42736	 0   18974758	 0
 61571	 0   76002203	  44453	 0   19092951	 0
 62014	 0   75636636	  44854	 0   20267569	 0
 60708	 0   73416718	  44983	 0   20528601	 0
 60875	 0   74149548	  43955	 0   20401444	 0
 60068	 0   73001785	  44094	 0   19860044	 0
 60335	 0   73124348	  44340	 0   21097461	 0
 60703	 0   73737900	  44420	 0   21588056	 0
 64609	 0   79927131	  45567	 0   20159777	 0
 61488	 0   75486273	  44046	 0   19358085	 0
 59906	 0   72033963	  44480	 0   20843751	 0
 59741	 0   71656498	  44121	 0   20837278	 0
 58641	 0   70958537	  43127	 0   20489312	 0
 58996	 0   70933299	  42814	 0   20520084	 0
 57186	 0   68102695	  43352	 0   21746162	 0
 56474	 0   67608306	  43089	 0   20597239	 0
 59276	 0   72138554	  41996	 0   18682065	 0
 59778	 0   72792095	  44026	 0   20206665	 0
 58491	 0   69932101	  43735	 0   20752907	 0
 60523	 0   72716295	  44789	 0   21573183	 0
		input		  (em1)		   output
  packets  errs	  bytes	packets  errs	  bytes colls
 64960	 0   80198737	  45717	 0   19758408	 0
 61997	 0   74747395	  44421	 0   20775572	 0
 60781	 0   73382372	  44538	 0   20225025	 0
 62918	 0   76244719	  45109	 0   20557795	 0
 60836	 0   73836576	  43714	 0   19957047	 0
 58504	 0   70250673	  43763	 0   20401480	 0
 62406	 0   76054425	  45005	 0   20467699	 0
 61954	 0   75217337	  44550	 0   19859601	 0
 61242	 0   74365524	  44144	 0   20116830	 0
 60215	 0   72347370	  44010	 0   21035600	 0
 59714	 0   71729017	  44003	 0   20550829	 0
 62656	 0   76426607	  44693	 0   18928326	 0
 60657	 0   73197970	  44495	 0   20108330	 0
 60403	 0   72674341	  43845	 0   20394198	 0
 59074	 0   70828441	  44590	 0   21634079	 0
 57724	 0   70451735	  41327	 0   17355994	 0
^C

Ссылка на сообщение
Поделиться на других сайтах

Нет. Имелось ввиду следующее (давно это было :) ):

Есть БГП. За ним сервер с НАТом.

На этот сервер заруливается блок внешних адресов.

Эти самые адреса используются для nat source-hash, то-есть физически их не было ни на одном ифейсе.

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

Быстрый досмотр показал наличие огромного кол-ва АРП пакетов для вот этих самых непривязанных адресов.

Решилось привязкой КАЖДОГО такого белого адреса на внешний ифейс с маской /32.

 

п.с. Ну это так - лирика )

Уже увидел по ситуации, что на наш случай не похоже.

Ссылка на сообщение
Поделиться на других сайтах

Нет. Имелось ввиду следующее (давно это было :) ):

Есть БГП. За ним сервер с НАТом.

На этот сервер заруливается блок внешних адресов.

Эти самые адреса используются для nat source-hash, то-есть физически их не было ни на одном ифейсе.

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

Быстрый досмотр показал наличие огромного кол-ва АРП пакетов для вот этих самых непривязанных адресов.

Решилось привязкой КАЖДОГО такого белого адреса на внешний ифейс с маской /32.

 

п.с. Ну это так - лирика )

Уже увидел по ситуации, что на наш случай не похоже.

 

нет, точно не такая ситуация, что-то нагружается машинку, не молниеносно, но как-то неравномерно, не могу выявить зависимости.

Может быть pps за 60к и трафика под 700 мегабит и процессор загружен на 70%, а может быть pps 30к и трафика около 300 мегабит, а процессор загружен на 100%, причем загружены только 2 ядра, по топу видно. По нату тоже зависимости не выявлено, может быть 200к нат сессий и процессор максимум 40-50%, а может быть 150к нат сессий, а проц в полке, опять же по top, 2 ядра на 100% заняты прерываниями внешней сетевой.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

на внешную сетевую стоит поставить intel с чипом 82576 ( у карты 4 очереди на вход и 4 очереди на выход на каждый езернет порт) а у предидуших моделей чипов всего 2-4 очереди против 8ми в этой модели.

 

Соотвественно с таким колличеством очередей вы сможете равномерно распределить их между ядрами и получить желаемый эффект.

Уже неоднократно с этим сталкивались.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від 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 та перевірю...
       

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від 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);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від 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 без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...
×
×
  • Створити нове...