doubtpoint Опубликовано 11 ноября, 2013 · Жалоба Посмотрел исходники драйвера ixgbe hw.ixgbe.max_interrupt_rate при включенном Adaptive Interrupt Moderation менять смысла нету(он автоматически подстраивается в зависимости от средней длинны пакета) hw.ixgbe.enable_aim=0 # Adaptive Interrupt Moderation deffault on=1 hw.ixgbe.max_interrupt_rate=16000 # def 4000000/238=31250 , but change by AIM Что делать с process_limit? Поставил hw.ixgbe.rx_process_limit=512 # How many packets rxeof tries to clean at a time, def=256 hw.ixgbe.tx_process_limit=512 # How many packets txeof tries to clean at a time, def=256 vmstat -i interrupt total rate irq23: ehci0 ehci1 103301 2 cpu0:timer 46912014 1125 irq264: hdac0 7 0 irq265: ix0:que 0 562101496 13488 irq266: ix0:que 1 567068299 13607 irq267: ix0:que 2 562928227 13508 irq268: ix0:que 3 554755297 13312 irq269: ix0:que 4 554120804 13297 irq270: ix0:que 5 559014158 13414 irq271: ix0:que 6 557604869 13380 irq272: ix0:que 7 567407087 13616 irq273: ix0:que 8 555491257 13330 irq274: ix0:que 9 563959280 13533 irq275: ix0:que 10 561547259 13475 irq276: ix0:que 11 553546013 13283 irq277: ix0:link 2 0 irq291: hdac1 81 0 irq295: re0 1213 0 irq296: ahci1 44516 1 cpu1:timer 46895598 1125 cpu10:timer 46896461 1125 cpu6:timer 46896427 1125 cpu5:timer 46895860 1125 cpu8:timer 46893043 1125 cpu2:timer 46896052 1125 cpu11:timer 46896186 1125 cpu4:timer 46897746 1125 cpu7:timer 46896216 1125 cpu3:timer 46896173 1125 cpu9:timer 46896212 1125 Total 7282461154 174756 Буду смотреть за результатом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 11 ноября, 2013 · Жалоба Что делать с process_limit? Понемногу увеличивать :) "Сколько пакетов rxeof будет забирать из буфера карты за раз (читай, за одно прерывание)". Безбожно задирать нельзя, иначе пакеты будут дропаться в ядре, нужно подбирать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 12 ноября, 2013 (изменено) · Жалоба Не очень помогло 12 root -92 - 0K 864K CPU0 0 671:36 60.35% intr{irq265: ix0:que } 12 root -92 - 0K 864K WAIT 1 664:48 55.47% intr{irq266: ix0:que } 12 root -92 - 0K 864K WAIT 3 665:32 55.37% intr{irq268: ix0:que } 12 root -92 - 0K 864K CPU5 5 667:41 54.88% intr{irq270: ix0:que } 12 root -92 - 0K 864K CPU9 9 618:01 53.27% intr{irq274: ix0:que } 12 root -92 - 0K 864K CPU4 4 669:15 52.78% intr{irq269: ix0:que } 12 root -92 - 0K 864K WAIT 6 673:54 52.69% intr{irq271: ix0:que } 12 root -92 - 0K 864K WAIT 2 666:51 51.07% intr{irq267: ix0:que } 12 root -92 - 0K 864K WAIT 10 610:15 51.07% intr{irq275: ix0:que } 12 root -92 - 0K 864K WAIT 7 653:40 50.78% intr{irq272: ix0:que } 12 root -92 - 0K 864K WAIT 11 635:20 46.78% intr{irq276: ix0:que } 12 root -92 - 0K 864K WAIT 8 616:00 46.09% intr{irq273: ix0:que } 11839 root 52 -15 1499M 1397M select 7 456:42 45.65% ipcad{ipcad} 11 root 155 ki31 0K 192K RUN 8 27.1H 41.26% idle{idle: cpu8} 11 root 155 ki31 0K 192K CPU11 11 26.7H 38.96% idle{idle: cpu11} 11 root 155 ki31 0K 192K CPU10 10 27.2H 37.16% idle{idle: cpu10} 11 root 155 ki31 0K 192K CPU9 9 27.0H 37.16% idle{idle: cpu9} 11 root 155 ki31 0K 192K CPU2 2 26.3H 37.16% idle{idle: cpu2} 11 root 155 ki31 0K 192K CPU5 5 26.3H 36.18% idle{idle: cpu5} 11 root 155 ki31 0K 192K CPU7 7 26.5H 35.35% idle{idle: cpu7} 11 root 155 ki31 0K 192K RUN 1 26.4H 35.25% idle{idle: cpu1} 11 root 155 ki31 0K 192K CPU6 6 26.2H 34.57% idle{idle: cpu6} 11 root 155 ki31 0K 192K RUN 4 26.3H 34.28% idle{idle: cpu4} 11 root 155 ki31 0K 192K CPU3 3 26.3H 33.89% idle{idle: cpu3} 11 root 155 ki31 0K 192K RUN 0 26.2H 32.57% idle{idle: cpu0} 0 root -92 0 0K 576K - 7 22:23 20.36% kernel{ix0 que} 0 root -92 0 0K 576K - 5 20:04 14.99% kernel{ix0 que} 0 root -92 0 0K 576K - 3 23:11 13.48% kernel{ix0 que} 0 root -92 0 0K 576K - 5 19:55 13.28% kernel{ix0 que} 0 root -92 0 0K 576K - 9 18:47 10.50% kernel{ix0 que} 0 root -92 0 0K 576K - 2 16:50 9.86% kernel{ix0 que} 0 root -92 0 0K 576K - 9 21:35 9.67% kernel{ix0 que} 0 root -92 0 0K 576K - 4 17:55 7.86% kernel{ix0 que} 0 root -92 0 0K 576K - 2 25:54 7.57% kernel{ix0 que} 0 root -92 0 0K 576K - 9 22:06 6.79% kernel{ix0 que} 0 root -92 0 0K 576K - 10 15:38 4.20% kernel{ix0 que} 0 root -92 0 0K 576K - 7 17:21 3.96% kernel{ix0 que} 936 root 20 0 389M 373M select 0 30:30 0.29% bgpd 11788 bind 20 0 235M 153M uwait 10 17:49 0.20% named{named} 11788 bind 20 0 235M 153M uwait 7 17:48 0.20% named{named} 11788 bind 20 0 235M 153M uwait 1 17:48 0.20% named{named} 11788 bind 20 0 235M 153M uwait 7 17:48 0.20% named{named} 11788 bind 20 0 235M 153M uwait 1 17:49 0.10% named{named} 11788 bind 20 0 235M 153M uwait 0 17:48 0.10% named{named} 11788 bind 20 0 235M 153M uwait 3 17:48 0.10% named{named} 11788 bind 20 0 235M 153M uwait 3 17:48 0.10% named{named} 11788 bind 20 0 235M 153M uwait 9 17:47 0.10% named{named} 11788 bind 20 0 235M 153M kqread 8 10:52 0.10% named{named} 0 root -16 0 0K 576K sched 2 260.4H 0.00% kernel{swapper} 0 root -92 0 0K 576K - 3 20:24 0.00% kernel{dummynet} interrupt total rate irq23: ehci0 ehci1 300330 2 cpu0:timer 157614474 1125 irq264: hdac0 7 0 irq265: ix0:que 0 1794476601 12813 irq266: ix0:que 1 1806190444 12896 irq267: ix0:que 2 1812416439 12941 irq268: ix0:que 3 1791970637 12795 irq269: ix0:que 4 1789198773 12775 irq270: ix0:que 5 1816328292 12969 irq271: ix0:que 6 1810298005 12926 irq272: ix0:que 7 1797882860 12837 irq273: ix0:que 8 1810791997 12929 irq274: ix0:que 9 1811791780 12936 irq275: ix0:que 10 1798961794 12845 irq276: ix0:que 11 1824577558 13028 irq277: ix0:link 2 0 irq291: hdac1 81 0 irq295: re0 4076 0 irq296: ahci1 178380 1 cpu1:timer 156836532 1119 cpu10:timer 156970710 1120 cpu6:timer 156768198 1119 cpu5:timer 156953520 1120 cpu8:timer 157011874 1121 cpu2:timer 156832962 1119 cpu11:timer 156978075 1120 cpu4:timer 156706093 1118 cpu7:timer 156884892 1120 cpu3:timer 156851412 1119 cpu9:timer 157002085 1121 Total 23548778883 168145 Изменено 12 ноября, 2013 пользователем doubtpoint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 12 ноября, 2013 · Жалоба Во сколько потоков очереди разгребаете? Ну и лучше весь sysctl net.isr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 ноября, 2013 · Жалоба ipcad? каким методом собирает трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 12 ноября, 2013 · Жалоба покажите netstat -Q Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 13 ноября, 2013 (изменено) · Жалоба Очереди разгребаем 12 потоками для i7-4930K и 8 потоками i7-4770K (имелось ввиду hw.ixgbe.num_queues). sysctl net.isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 2048 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 17 8906340497 0 0 13381293 8919701748 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 81 0 0 0 2966559 2966559 0 0 arp 0 0 152676 0 0 0 152676 0 0 ether 0 0 17812983236 0 0 0 17812983236 0 0 ip6 0 0 4 0 0 0 4 ipcad отключали - результат нулевой. Изменено 13 ноября, 2013 пользователем doubtpoint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 14 ноября, 2013 · Жалоба Очереди разгребаем 12 потоками для i7-4930K и 8 потоками i7-4770K (имелось ввиду hw.ixgbe.num_queues). Может в этом проблема? Реальных то ядер там всего 6 и 4 соответственно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 14 ноября, 2013 · Жалоба loader.conf: net.isr.maxthreads выставить равным hw.ncpu net.isr.defaultqlimit выставить равным hw.ixgbe.rx_process_limit/hw.ixgbe.tx_process_limit Теория в жж dadv под тегом freebsd :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 14 ноября, 2013 · Жалоба И, все-таки, мне кажется не там копаете. ИМХО, рост kernel не связан на прямую с isr и irq. А больше с побочными действиями типа классификации по 512 натам... Чисто мое ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 ноября, 2013 · Жалоба Лишние виртуальные (НТ) потоки там только кеш вымывают. При вымывании кеша поток стопорится до получения данных, это ожидание считается операционкой как работа. net.isr.maxthreads можно хоть 1024 ставить, оно автоматом уменьшится до реального количества процов, чем я обычно и пользуюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 17 ноября, 2013 · Жалоба net.isr.maxthreads=8 вроде дало эффект, но не более 10% :-( Пробовал в исходниках подправить /usr/src/sys/netinet/libalias/alias_local.h #define LINK_TABLE_OUT_SIZE 8123 #define LINK_TABLE_IN_SIZE 16411 Но тоже эффекта нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 17 ноября, 2013 · Жалоба А может поставить второй сервер под НАТ и забить на лишние 10-20% процессора ? Денег всего-то < $1,5К на >3Гб трафика. Окупается за 10 часов работы под такой нагрузкой :) Зато будет хороший запас на пережевать всякие ДДОС в худшем случае + резерв на случай выхода из строя одного из серверов. В этом случае на второй развернуть весь трафик дело 5 мин, он уж часик-другой отработает под двойной нагрузкой, даже если с небольшими потерями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 17 ноября, 2013 · Жалоба Размер исходящей очереди, сиречь net.route.netisr_maxqlen? vmstat -i/-z, netstat -Q/-m начали по-другому выглядеть или всё так же? net.inet.ip.dummynet.io_fast включать пробовали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
windows_NT Опубликовано 17 ноября, 2013 · Жалоба Вся тема, прямо как анекдот. Министр сельского хозяйства жалуется Михаилу Горбачеву: «Куры дохнут». Михал Сергеич: «Я знаю! Нужно выложить вокруг птицефабрики круг белым гравием, и они дохнуть перестанут». Через какое-то время министр докладывает, что куры по-прежнему дохнут. Горбачев: «Рисуем квадрат!» Потом треугольник. Проходит время, министр Горбачева избегает. Тот не выдержал, сам его вызвал. Оказалось— все куры подохли. «Жаль,— говорит Горбачев,— столько задумок еще было!» Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 17 ноября, 2013 · Жалоба Размер исходящей очереди, сиречь net.route.netisr_maxqlen? vmstat -i/-z, netstat -Q/-m начали по-другому выглядеть или всё так же? net.inet.ip.dummynet.io_fast включать пробовали? vmstat -i Все по прежнему. vmstat -z не очень понимаю куда смотреть? vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 90, 12, 90, 0, 0 UMA Zones: 1408, 0, 90, 0, 90, 0, 0 UMA Slabs: 568, 0, 14756, 7, 16934, 0, 0 UMA RCntSlabs: 568, 0, 19187, 35, 21658, 0, 0 UMA Hash: 256, 0, 0, 0, 4, 0, 0 16 Bucket: 152, 0, 76, 124, 199, 0, 0 32 Bucket: 280, 0, 228, 38, 350, 0, 0 64 Bucket: 536, 0, 131, 93, 313, 200, 0 128 Bucket: 1048, 0, 12250, 2, 42706,45369, 0 VM OBJECT: 232, 0, 44347, 6165, 527768, 0, 0 MAP: 232, 0, 8, 24, 8, 0, 0 KMAP ENTRY: 120, 148056, 165, 1726, 462029, 0, 0 MAP ENTRY: 120, 0, 1072, 1377, 1359131, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 328, 15, 328, 0, 0 16: 16, 0, 2935, 929, 537407, 0, 0 32: 32, 0, 3125, 1016, 1100847, 0, 0 64: 64, 0, 3761, 1223, 1373383, 0, 0 128: 128, 0, 658210, 1436692,1454483953, 0, 0 256: 256, 0, 7946, 2209,397437218, 0, 0 512: 512, 0, 830, 1431, 230830, 0, 0 1024: 1024, 0, 64, 236, 30035, 0, 0 2048: 2048, 0, 65, 249, 5031, 0, 0 4096: 4096, 0, 454, 405, 28878, 0, 0 Files: 80, 0, 85, 725, 1495165, 0, 0 rl_entry: 40, 0, 218, 538, 218, 0, 0 TURNSTILE: 136, 0, 490, 150, 490, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1192, 0, 44, 202, 24476, 0, 0 THREAD: 1160, 0, 338, 151, 1249, 0, 0 SLEEPQUEUE: 80, 0, 490, 148, 490, 0, 0 VMSPACE: 392, 0, 29, 291, 24461, 0, 0 cpuset: 72, 0, 109, 91, 125, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 32790, 2538,78978735258, 0, 0 mbuf: 256, 0, 6, 3066,158855449862, 0, 0 mbuf_cluster: 2048, 262144, 35328, 1254, 49152, 0, 0 mbuf_jumbo_page: 4096, 131072, 0, 896,64927365, 0, 0 mbuf_jumbo_9k: 9216, 65536, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 32768, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 5985, 523822, 0, 0 ttyinq: 160, 0, 240, 240, 615, 0, 0 ttyoutq: 256, 0, 126, 174, 322, 0, 0 ata_request: 328, 0, 0, 420, 174604, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 78803, 4037, 1730938, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 S VFS Cache: 108, 0, 55376, 34318, 1613829, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 24676, 764, 166689, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 280, 3328864, 0, 0 NCLNODE: 568, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 1906, 398, 5594, 0, 0 Mountpoints: 824, 0, 5, 3, 5, 0, 0 pipe: 728, 0, 3, 207, 11825, 0, 0 ksiginfo: 112, 0, 239, 751, 8800, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 0, 319, 7820, 0, 0 socket: 680, 262146, 27, 273, 659313, 0, 0 ipq: 56, 8253, 0, 189, 198, 0, 0 udp_inpcb: 392, 262150, 10, 300, 643290, 0, 0 udpcb: 16, 262248, 10, 1334, 643290, 0, 0 tcp_inpcb: 392, 262150, 6, 244, 7543, 0, 0 tcpcb: 976, 262144, 6, 190, 7543, 0, 0 tcptw: 72, 27800, 0, 450, 1743, 0, 0 syncache: 152, 15375, 0, 250, 2169, 0, 0 hostcache: 136, 15372, 2, 166, 6, 0, 0 tcpreass: 40, 16464, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 202, 1, 0, 0 sctp_ep: 1384, 262144, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 5, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400032, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 262150, 0, 120, 4016, 0, 0 unpcb: 240, 262144, 10, 294, 4457, 0, 0 rtentry: 200, 0, 21, 93, 21, 0, 0 IPFW dynamic rule: 120, 4123, 0, 0, 0, 0, 0 selfd: 56, 0, 571, 1445,3222002715, 0, 0 SWAPMETA: 288, 493493, 0, 0, 0, 0, 0 FFS inode: 168, 0, 78772, 4806, 1730854, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 78772, 4793, 1730854, 0, 0 Предпоследняя колонка только здесь не равна нулю 64 Bucket: 536, 0, 131, 93, 313, 200, 0 128 Bucket: 1048, 0, 12250, 2, 42706,45369, 0 Так это и на веб сервере у нас... netstat -Q Configuration: Setting Current Limit Thread count 8 8 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 2048 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 0 11826540525 0 0 0 11826540525 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 1 0 0 0 9 9 0 0 arp 0 0 305167 0 0 0 305167 0 0 ether 0 0 23653692628 0 0 0 23653692628 0 0 ip6 0 0 0 0 0 0 0 1 1 ip 0 0 11684475606 0 0 0 11684475606 1 1 igmp 0 0 0 0 0 0 0 1 1 rtsock 0 0 0 0 0 0 0 1 1 arp 0 0 820 0 0 0 820 1 1 ether 0 0 23368954670 0 0 0 23368954670 1 1 ip6 0 0 0 0 0 0 0 2 2 ip 0 0 11728762447 0 0 0 11728762447 2 2 igmp 0 0 0 0 0 0 0 2 2 rtsock 0 0 0 0 0 0 0 2 2 arp 0 0 883 0 0 0 883 2 2 ether 0 0 23457527571 0 0 0 23457527571 2 2 ip6 0 0 0 0 0 0 0 3 3 ip 0 0 11735031350 0 0 0 11735031350 3 3 igmp 0 0 0 0 0 0 0 3 3 rtsock 0 0 0 0 0 0 0 3 3 arp 0 0 731 0 0 0 731 3 3 ether 0 0 23470063373 0 0 0 23470063373 3 3 ip6 0 0 0 0 0 0 0 4 4 ip 0 0 11803336979 0 0 0 11803336979 4 4 igmp 0 0 0 0 0 0 0 4 4 rtsock 0 0 0 0 0 0 0 4 4 arp 0 0 782 0 0 0 782 4 4 ether 0 0 23606674237 0 0 0 23606674237 4 4 ip6 0 0 0 0 0 0 0 5 5 ip 0 0 11708365654 0 0 0 11708365654 5 5 igmp 0 0 0 0 0 0 0 5 5 rtsock 0 0 0 0 0 0 0 5 5 arp 0 0 834 0 0 0 834 5 5 ether 0 0 23416734707 0 0 0 23416734707 5 5 ip6 0 0 0 0 0 0 0 6 6 ip 0 0 11867721184 0 0 0 11867721184 6 6 igmp 0 0 0 0 0 0 0 6 6 rtsock 0 0 0 0 0 0 0 6 6 arp 0 0 832 0 0 0 832 6 6 ether 0 0 23735443337 0 0 0 23735443337 6 6 ip6 0 0 0 0 0 0 0 7 7 ip 0 4 11932615991 0 0 13596778 11946195867 7 7 igmp 0 0 0 0 0 0 0 7 7 rtsock 0 0 0 0 0 0 0 7 7 arp 0 0 845 0 0 0 845 7 7 ether 0 0 23865233221 0 0 0 23865233221 7 7 ip6 0 1 0 0 0 1392 1392 netstat -m 32819/5581/38400 mbufs in use (current/cache/total) 32811/3035/35846/262144 mbuf clusters in use (current/cache/total/max) 32811/3029 mbuf+clusters out of packet secondary zone in use (current/cache) 0/403/403/243835 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/72247 9k jumbo clusters in use (current/cache/total/max) 0/0/0/40639 16k jumbo clusters in use (current/cache/total/max) 73837K/9077K/82914K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 17 ноября, 2013 · Жалоба Вся тема, прямо как анекдот. Ну да, результата ноль, но если других советов нету, то и это что-то. Огромное спасибо, тем кто, что спрашивает и советует. Это хоть наводит на различные мысли, да и умнее делает. А тазик еще один поставить(а вернее еще 3) самое простое решение и относительно не дорогое - уже принято. Только сейчас нету 10Г портов свободных, вот ждем оборудование... Другой принципиальный способ решения "проблемы кур" это перейти на pf nat или ng_nat, но не охото так кардинально менять... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 ноября, 2013 · Жалоба Threads bound to CPUs disabled в ловадере: net.isr.bindthreads=1 Вся тема, прямо как анекдот. Трольте в др месте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 18 ноября, 2013 · Жалоба Другой принципиальный способ решения "проблемы кур" это перейти на pf nat или ng_nat, но не охото так кардинально менять... В такой схеме вам потребуется 500+ нод ng_nat, я это эксплуатировал, тоже честно говоря не фонтан. Лучший для вас выход, на мой взгляд, Linux. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 18 ноября, 2013 · Жалоба а какую можно ждать производительность от Linux в задаче НАТ на 128-512 внешних ? на том же i7-3770 или выше. 5 Гб трафика пережует? а 6 ? если нет, то наверное нет большого смысла ради дополнительных 1-1,5Гбит переходить на менее знакомую систему. Проще горизонтально отмасштабировать, легче в сопровождении. Или так, какое нужно железо чтобы отнатить от 5 до 7 гбит/с на Linux ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 18 ноября, 2013 · Жалоба а какую можно ждать производительность от Linux в задаче НАТ на 128-512 внешних ? У меня было 1.2Гига на E8400 при утилизации 15-20% при пуле в 512 внешних. Я не уверен, что там полноценно считается утилизация ядерного контекста, но никаких признаков перегруза не было. FreeBSD с 512 нод ng_nat давала 40-50% утилизации суммарно по isr+ng_queue. Что сможет переживать 5-7Гбит... Я думаю i7 сможет, у товарищей из темы про софтороутеры с каким-то модулем ната такое вроде получалось :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 18 ноября, 2013 · Жалоба в ловадере: net.isr.bindthreads=1 Поставил, но что, то все равно не то: procstat -at | grep netisr 12 100011 intr swi1: netisr 0 0 28 wait - 12 100102 intr swi1: netisr 1 0 28 wait - 12 100103 intr swi1: netisr 2 0 28 wait - 12 100104 intr swi1: netisr 3 0 28 wait - 12 100105 intr swi1: netisr 4 0 28 wait - 12 100106 intr swi1: netisr 5 0 28 wait - 12 100107 intr swi1: netisr 6 0 28 wait - [b] 12 100108 intr swi1: netisr 7 7 28 wait -[/b] Тлько 10018 выполняется на 7 процессоре. Причем им вообще запрещено выполнятся на 0 procstat -at | awk '/swi1: netisr/ {print $5, $6, "current_cpu_id=", $7; system("cpuset -g -t " $2);}' netisr 0 current_cpu_id= 0 tid 100011 mask: 0 netisr 1 current_cpu_id= 0 tid 100102 mask: 1 netisr 2 current_cpu_id= 0 tid 100103 mask: 2 netisr 3 current_cpu_id= 0 tid 100104 mask: 3 netisr 4 current_cpu_id= 0 tid 100105 mask: 4 netisr 5 current_cpu_id= 0 tid 100106 mask: 5 netisr 6 current_cpu_id= 0 tid 100107 mask: 6 netisr 7 current_cpu_id= 7 tid 100108 mask: 7 Вручную выставляя ядро тоже не меняет. Причем только 7 поток имеет отличные от нуля Queued netstat -Q Configuration: Setting Current Limit Thread count 8 8 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs enabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 2048 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 0 2531612950 0 0 0 2531612950 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 1 0 0 0 9 9 0 0 arp 0 0 75997 0 0 0 75997 0 0 ether 0 0 5063378561 0 0 0 5063378561 0 0 ip6 0 0 0 0 0 0 0 1 1 ip 0 0 2477295338 0 0 0 2477295338 1 1 igmp 0 0 0 0 0 0 0 1 1 rtsock 0 0 0 0 0 0 0 1 1 arp 0 0 95 0 0 0 95 1 1 ether 0 0 4954590570 0 0 0 4954590570 1 1 ip6 0 0 0 0 0 0 0 2 2 ip 0 0 2437120519 0 0 0 2437120519 2 2 igmp 0 0 0 0 0 0 0 2 2 rtsock 0 0 0 0 0 0 0 2 2 arp 0 0 123 0 0 0 123 2 2 ether 0 0 4874241624 0 0 0 4874241624 2 2 ip6 0 0 0 0 0 0 0 3 3 ip 0 0 2467764616 0 0 0 2467764616 3 3 igmp 0 0 0 0 0 0 0 3 3 rtsock 0 0 0 0 0 0 0 3 3 arp 0 0 108 0 0 0 108 3 3 ether 0 0 4935529376 0 0 0 4935529376 3 3 ip6 0 0 0 0 0 0 0 4 4 ip 0 0 2524492203 0 0 0 2524492203 4 4 igmp 0 0 0 0 0 0 0 4 4 rtsock 0 0 0 0 0 0 0 4 4 arp 0 0 85 0 0 0 85 4 4 ether 0 0 5048984560 0 0 0 5048984560 4 4 ip6 0 0 0 0 0 0 0 5 5 ip 0 0 2530961875 0 0 0 2530961875 5 5 igmp 0 0 0 0 0 0 0 5 5 rtsock 0 0 0 0 0 0 0 5 5 arp 0 0 79 0 0 0 79 5 5 ether 0 0 5061924155 0 0 0 5061924155 5 5 ip6 0 0 0 0 0 0 0 6 6 ip 0 0 2495672449 0 0 0 2495672449 6 6 igmp 0 0 0 0 0 0 0 6 6 rtsock 0 0 0 0 0 0 0 6 6 arp 0 0 113 0 0 0 113 6 6 ether 0 0 4991344934 0 0 0 4991344934 6 6 ip6 0 0 0 0 0 0 0 7 7 ip 0 5 2498656358 0 0 3828234 2502484483 7 7 igmp 0 0 0 0 0 0 0 7 7 rtsock 0 0 0 0 0 0 0 7 7 arp 0 0 135 0 0 0 135 7 7 ether 0 0 4997312880 0 0 0 4997312880 7 7 ip6 0 0 0 0 0 0 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
windows_NT Опубликовано 18 ноября, 2013 · Жалоба doubtpoint Почему бы вам не заменить комп, на mikrotik CCR1036-8G-2S+EM. Его цена примерно на уровне с хорошим компом, ~$1200. Работает хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 ноября, 2013 · Жалоба Работает хорошо. Ну не считая того что порты отсыхают и + куча прочих подземных стуков, и на 5 гбитах реального трафика завернется в трубочку... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 19 ноября, 2013 · Жалоба doubtpoint Почему бы вам не заменить комп, на mikrotik CCR1036-8G-2S+EM. Его цена примерно на уровне с хорошим компом, ~$1200. Я интересовался данным вопросом. Цена его хоть и сравнима с компом, но и производительность тоже. А если с freeBSD у меня есть шанс решить все мои проблемы, то с проблемами микротика я попаду в тупик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
