vasaf Posted September 8, 2014 · Report post Приветствую всех! Помогите разобраться с проблемой или подскажите где еще можно посмотреть, т.к. поиск в инете и на НАГе не привел ни к какому результату. Стоит фря 9.1 и используется в качестве НАТа (ng_nat) для части трафика, а для остального просто как сквозной шлюз, плюс VLANы. Характер трафика: интернет, торренты, и т.п. В часы пик стал просидать Интернет, при этом на внешнем интерфейсе igb0: netstat -w 1 -hd -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls drops 63k 346 0 42M 53k 0 30M 0 0 52k 0 0 38M 47k 0 30M 0 0 50k 0 0 34M 46k 0 27M 0 0 49k 785 0 34M 46k 0 25M 0 0 48k 0 0 35M 44k 0 29M 0 0 51k 476 0 31M 48k 0 25M 0 0 51k 111 0 36M 48k 0 28M 0 0 47k 0 0 34M 43k 0 26M 0 0 50k 0 0 33M 47k 0 30M 0 0 49k 860 0 28M 45k 0 26M 0 0 Сетевая igb0 встроенная в материнку. Ничего критичного по всем стандартным проверкам нет (подробности ниже). Стояли штатные дрова для igb от freebsd, сейчас стоят последние от Интел 2.4.2 - дало прирост в производительности на 10%. Нагрузка низкая для такой машины: CPU: Intel® Xeon® CPU E5645 @ 2.40GHz, 48GB RAM (да много, другой машины на момент необходимости запуска сервера не было). Плиз хелп, уже не знаю куда смотреть. uname -a FreeBSD test.mai.ru 9.1-RELEASE FreeBSD 9.1-RELEASE igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO> ether 00:25:90:94:f1:a8 inet 172.16.222.2 netmask 0xfffffffc broadcast 172.16.222.3 inet6 fe80::225:90ff:fe94:f1a8%igb0 prefixlen 64 scopeid 0x1 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active ifconfig_igb0="inet 172.16.222.2 netmask 255.255.255.252 -rxcsum -tso -mediaopt flowcontrol" ipfw для НАТа: ipfw list 01100 netgraph tablearg ip from table(1) to any 01150 netgraph tablearg ip from any to table(11) 01190 netgraph tablearg ip from table(65) to any 01200 netgraph tablearg ip from table(63) to any 01240 netgraph tablearg ip from any to table(75) 01250 netgraph tablearg ip from any to table(73) 01300 netgraph tablearg ip from table(64) to any 01350 netgraph tablearg ip from any to table(74) 01400 netgraph tablearg ip from table(83) to any 01450 netgraph tablearg ip from any to table(93) 65534 allow ip from any to any НАТ разбит на множество инстансов для распределения нагрузки, хотя натится немного. Инстансы сделаны по виду: /usr/sbin/ngctl > /dev/null -f- <<-SEQ mkpeer ipfw: nat $1 in name ipfw:$1 nat$1 connect ipfw: nat$1: ${NUM} out msg nat$1: setaliasaddr $2 SEQ /etc/sysctl.conf dev.igb.0.rx_processing_limit=2048 dev.igb.1.rx_processing_limit=2048 net.route.netisr_maxqlen=4096 net.inet.ip.intr_queue_maxlen=4096 kern.ipc.nmbclusters=200000 net.inet.ip.intr_queue_maxlen=4096 net.graph.recvspace=102400 net.graph.maxdgram=102400 dev.igb.0.fc=0 #disable flowcontrol dev.igb.1.fc=0 #disable flowcontrol net.inet.ip.check_interface=1 # verify packet arrives on correct interface (default 0) net.inet.ip.process_options=0 # ignore IP options in the incoming packets (default 1) kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 net.inet.ip.redirect=0 /boot/loader.conf hw.igb.max_interrupt_rate=24000 #default 8000 hw.igb.rxd=4096 hw.igb.txd=4096 kern.maxusers=2048 net.graph.maxdata=8192 net.graph.maxalloc=8192 if_tap_load="YES" if_bridge_load="YES" if_igb_load="YES" vmstat -i | grep igb0 irq256: igb0:que 0 28650012 7762 irq257: igb0:que 1 28530310 7729 irq258: igb0:que 2 28400597 7694 irq259: igb0:que 3 29165974 7901 irq260: igb0:que 4 29100412 7884 irq261: igb0:que 5 2605845 705 irq262: igb0:que 6 29120640 7889 irq263: igb0:que 7 29365331 7955 irq264: igb0:link 2 0 netstat -m 106599/27171/133770 mbufs in use (current/cache/total) 106560/22598/129158/200000 mbuf clusters in use (current/cache/total/max) 106560/22592 mbuf+clusters out of packet secondary zone in use (current/cache) 0/190/190/66048 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/33024 9k jumbo clusters in use (current/cache/total/max) 0/0/0/16512 16k jumbo clusters in use (current/cache/total/max) 240159K/52748K/292908K 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 vmstat -z | head -1 ; vmstat -z | grep -i mbuf ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_packet: 256, 0, 104913, 24239,367105938, 0, 0 mbuf: 256, 0, 1, 4617,362963355, 0, 0 mbuf_cluster: 2048, 200000, 129152, 6, 129152, 0, 0 mbuf_jumbo_page: 4096, 66048, 0, 190, 194, 0, 0 mbuf_jumbo_9k: 9216, 33024, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 16512, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 top -nCHSIzs1 last pid: 7577; load averages: 25.82, 25.94, 25.70 up 0+01:03:39 22:40:59 241 processes: 53 running, 116 sleeping, 72 waiting Mem: 17M Active, 15M Inact, 1333M Wired, 15M Buf, 45G Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 13 root -16 - 0K 384K RUN 5 2:37 33.79% ng_queue{ng_queue1} 13 root -16 - 0K 384K RUN 5 2:41 29.05% ng_queue{ng_queue0} 12 root -92 - 0K 1200K CPU4 4 6:45 12.89% intr{irq260: igb0:que} 12 root -92 - 0K 1200K WAIT 2 4:46 8.50% intr{irq258: igb0:que} 12 root -92 - 0K 1200K CPU0 0 4:32 7.86% intr{irq256: igb0:que} 12 root -92 - 0K 1200K WAIT 7 4:38 7.76% intr{irq263: igb0:que} 12 root -92 - 0K 1200K WAIT 3 4:35 7.47% intr{irq259: igb0:que} 12 root -92 - 0K 1200K WAIT 6 4:31 7.47% intr{irq262: igb0:que} 12 root -92 - 0K 1200K WAIT 1 4:29 6.88% intr{irq257: igb0:que} 12 root -92 - 0K 1200K WAIT 14 3:30 5.86% intr{irq271: igb1:que} 12 root -92 - 0K 1200K WAIT 12 3:16 4.79% intr{irq269: igb1:que} 12 root -92 - 0K 1200K WAIT 15 3:13 4.59% intr{irq272: igb1:que} 12 root -92 - 0K 1200K WAIT 13 2:45 3.76% intr{irq270: igb1:que} 13 root -16 - 0K 384K RUN 5 2:41 3.37% ng_queue{ng_queue23} 12 root -92 - 0K 1200K WAIT 11 2:13 2.98% intr{irq268: igb1:que} 12 root -92 - 0K 1200K WAIT 10 2:02 2.88% intr{irq267: igb1:que} 12 root -92 - 0K 1200K WAIT 9 2:11 2.49% intr{irq266: igb1:que} 12 root -92 - 0K 1200K CPU8 8 2:05 2.49% intr{irq265: igb1:que} sysctl dev.igb.0.mac_stats. | grep -v ': 0' dev.igb.0.mac_stats.missed_packets: 567716 dev.igb.0.mac_stats.recv_no_buff: 1205 dev.igb.0.mac_stats.xon_txd: 1182 dev.igb.0.mac_stats.xoff_txd: 562735 dev.igb.0.mac_stats.total_pkts_recvd: 233500210 dev.igb.0.mac_stats.good_pkts_recvd: 232932087 dev.igb.0.mac_stats.bcast_pkts_recvd: 248 dev.igb.0.mac_stats.rx_frames_64: 10052840 dev.igb.0.mac_stats.rx_frames_65_127: 105874741 dev.igb.0.mac_stats.rx_frames_128_255: 11367809 dev.igb.0.mac_stats.rx_frames_256_511: 4397227 dev.igb.0.mac_stats.rx_frames_512_1023: 5548619 dev.igb.0.mac_stats.rx_frames_1024_1522: 95690851 dev.igb.0.mac_stats.good_octets_recvd: 152793023638 dev.igb.0.mac_stats.good_octets_txd: 56387091800 dev.igb.0.mac_stats.total_pkts_txd: 212002938 dev.igb.0.mac_stats.good_pkts_txd: 211439021 dev.igb.0.mac_stats.bcast_pkts_txd: 172 dev.igb.0.mac_stats.tx_frames_64: 39240299 dev.igb.0.mac_stats.tx_frames_65_127: 122839366 dev.igb.0.mac_stats.tx_frames_128_255: 12688322 dev.igb.0.mac_stats.tx_frames_256_511: 6557300 dev.igb.0.mac_stats.tx_frames_512_1023: 3136984 dev.igb.0.mac_stats.tx_frames_1024_1522: 26976750 netstat -ni -I igb0 Name Mtu Network Address Ipkts [b]Ierrs[/b] Idrop Opkts Oerrs Coll igb0 1500 <Link#1> 00:25:90:94:f1:a8 236425911 [b]577830[/b] 0 216645297 0 0 igb0 1500 172.16.222.0/ 172.16.222.2 14 - - 1176622 - - igb0 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - - netstat -s -p udp udp: 3331 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 2 with no checksum 3141 dropped due to no socket 70 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 120 delivered 135708 datagrams output 0 times multicast source filter matched netstat -s -p tcp tcp: 2811 packets sent 2568 data packets (509281 bytes) 3 data packets (1145 bytes) retransmitted 1 data packet unnecessarily retransmitted 0 resends initiated by MTU discovery 207 ack-only packets (106 delayed) 0 URG only packets 0 window probe packets 0 window update packets 33 control packets 2792 packets received 1950 acks (for 509002 bytes) 25 duplicate acks 0 acks for unsent data 1109 packets (86570 bytes) received in-sequence 1 completely duplicate packet (23 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 37 connection accepts 0 bad connection attempts 0 listen queue overflows 3 ignored RSTs in the windows 37 connections established (including accepts) 76 connections closed (including 3 drops) 30 connections updated cached RTT on close 30 connections updated cached RTT variance on close 2 connections updated cached ssthresh on close 0 embryonic connections dropped 1824 segments updated rtt (of 1821 attempts) 7 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 50 correct ACK header predictions 483 correct data packet header predictions 60 syncache entries added 13 retransmitted 1 dupsyn 0 dropped 37 completed 0 bucket overflow 0 cache overflow 20 reset 3 stale 0 aborted 0 badack 0 unreach 0 zone failures 60 cookies sent 0 cookies received 4 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 3 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window netstat -s -p ip ip: 532539447 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 13371 packets for this host 1536 packets for unknown/unsupported protocol 387246005 packets forwarded (0 packets fast forwarded) 613305 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 1385263 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 9 datagrams with bad address in header Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DVM-Avgoor Posted September 8, 2014 · Report post 1) 9.1 - старая шарманка, переходите на 10.0-STABLE. 2) ng_nat не всегда самое удачное решение, особенно сейчас, когда ipfw сам все может. Используйте ipfw nat, чтобы не страдать от ng_queue на одном ядре. 3) без этого тюнинга в sysctl.conf (кроме netgraph, с ним все логично) заметно хуже работает? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vasaf Posted September 8, 2014 · Report post Спасибо за ответ. 1. опа, перейдем завтра на 10.0 2. попробуем реализовать ipfw nat, но мне кажется это не поможет. К тому же, при ng_nat тот же ng_queue создается по каждому на одно ядро и работают они на разных ядрах, или я ошибаюсь?: top -SHzn all | grep ng_queue 13 root -16 - 0K 384K sleep 5 0:31 3.37% ng_queue{ng_queue17} 13 root -16 - 0K 384K sleep 5 0:31 3.17% ng_queue{ng_queue8} 13 root -16 - 0K 384K sleep 5 0:29 3.17% ng_queue{ng_queue15} 13 root -16 - 0K 384K RUN 5 0:38 3.08% ng_queue{ng_queue3} 13 root -16 - 0K 384K sleep 5 0:36 2.88% ng_queue{ng_queue9} 13 root -16 - 0K 384K sleep 5 0:35 2.88% ng_queue{ng_queue6} 13 root -16 - 0K 384K sleep 5 0:34 2.88% ng_queue{ng_queue4} 13 root -16 - 0K 384K sleep 5 0:30 2.88% ng_queue{ng_queue5} 13 root -16 - 0K 384K sleep 5 0:28 2.88% ng_queue{ng_queue0} 13 root -16 - 0K 384K sleep 5 0:26 2.88% ng_queue{ng_queue1} 13 root -16 - 0K 384K sleep 5 0:35 2.78% ng_queue{ng_queue12} 13 root -16 - 0K 384K RUN 5 0:33 2.78% ng_queue{ng_queue20} 13 root -16 - 0K 384K sleep 5 0:32 2.78% ng_queue{ng_queue11} 13 root -16 - 0K 384K sleep 5 0:31 2.78% ng_queue{ng_queue13} 13 root -16 - 0K 384K sleep 5 0:32 2.69% ng_queue{ng_queue14} 13 root -16 - 0K 384K sleep 5 0:28 2.59% ng_queue{ng_queue19} 13 root -16 - 0K 384K sleep 5 0:37 2.49% ng_queue{ng_queue7} 13 root -16 - 0K 384K sleep 5 0:32 2.49% ng_queue{ng_queue2} 13 root -16 - 0K 384K sleep 5 0:30 2.49% ng_queue{ng_queue16} 13 root -16 - 0K 384K sleep 5 0:31 2.39% ng_queue{ng_queue21} 13 root -16 - 0K 384K sleep 5 0:30 2.39% ng_queue{ng_queue10} 13 root -16 - 0K 384K CPU5 5 0:28 2.39% ng_queue{ng_queue23} 13 root -16 - 0K 384K sleep 5 0:29 2.29% ng_queue{ng_queue22} 13 root -16 - 0K 384K sleep 5 0:25 2.29% ng_queue{ng_queue18} 3. Разница почти никакой, скорее всего даже нет разницы. Постепенно пришел к этим параметрам проверяя все, что может как-то влиять на входящий трафик. А теперь еще пару зацепок появилось: 1. Час назад начались жуткие лаги и ошибки на входе были 1к-1,5к. В онлайн не поиграться вообще. Причем лагал не только трафик, проходящий через нат, но и сквозной трафик. Отключил полностью ng_nat и оставил в фаерволе только allow all from any to any - проходящий трафик сразу пошел без проблем. 2. Подождал 30 минут примерно и обратно врубил нат, и вот уже 10 минут как ошибок нет вообще, так при этом еще и трафик вырос: netstat -w 1 -hd -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls drops 56k 0 0 49M 44k 0 17M 0 0 57k 0 0 47M 46k 0 17M 0 0 57k 0 0 49M 44k 0 18M 0 0 54k 0 0 47M 43k 0 18M 0 0 58k 0 0 48M 45k 0 17M 0 0 58k 0 0 50M 45k 0 16M 0 0 56k 0 0 47M 45k 0 17M 0 0 60k 0 0 47M 48k 0 17M 0 0 56k 0 0 49M 45k 0 17M 0 0 54k 0 0 45M 44k 0 18M 0 0 60k 0 0 52M 48k 0 18M 0 0 58k 0 0 49M 47k 0 21M 0 0 57k 0 0 50M 45k 0 18M 0 0 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
polmax Posted September 9, 2014 (edited) · Report post Стоит фря 9.1 Для начала надо обновится хотя бы до 9.3 стебла, в 9.1 очень много проблем было именно с нетграфом Ещё как вариант проверьте кабель. Edited September 9, 2014 by polmax Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DVM-Avgoor Posted September 9, 2014 · Report post 2. попробуем реализовать ipfw nat, но мне кажется это не поможет. К тому же, при ng_nat тот же ng_queue создается по каждому на одно ядро и работают они на разных ядрах, или я ошибаюсь?: У вас в топе видно, как оно работает. Т.е. вы можете четко видеть, что у вас работают по-сути все ng_queue на 6-ом ядре. Вот такая петрушка. Вам однозначно на ipfw nat. 3. Разница почти никакой, скорее всего даже нет разницы. Постепенно пришел к этим параметрам проверяя все, что может как-то влиять на входящий трафик. Я к тому веду, что вы когда 10-ку поставите, не торопитесь это же самое "тюнить". Многие параметры без тонкой оценки могут и хуже сделать, пробуйте в дефолте. Да, еще у ipfw nat надо сделать много инстансов, в одном инстансе оно не будет никак параллелиться. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vasaf Posted September 9, 2014 (edited) · Report post Итак, предварительный итог: 1. Обновлений не делал никаких. 2. Проблема повторилась снова. Я понял что это из-за ната, т.к. стоило выключить часть инстансов ната (подозрительных, от местных некоторых сетей), как все стало хорошо. Может дело в количестве созданных алиасов для каждого инстанса - хз. Вот выдержка из самых нагруженных: nat506 showtotal: Sep 9 23:08:56 test kernel: total: 8547 Sep 9 23:08:56 test kernel: icmp=5, udp=1346, tcp=3091, sctp=0, pptp=0, Sep 9 23:08:56 test kernel: proto=0, frag_id=4105, frag_ptr=0, sock=0 nat513 showtotal: Sep 9 23:08:58 test kernel: total: 29989 Sep 9 23:08:58 test kernel: icmp=3, udp=5546, tcp=24439, sctp=0, pptp=0, Sep 9 23:08:58 test kernel: proto=0, frag_id=1, frag_ptr=0, sock=0 nat519 showtotal: Sep 9 20:34:40 test kernel: total: 18307 Sep 9 20:34:40 test kernel: icmp=1, udp=5865, tcp=8780, sctp=0, pptp=0, Sep 9 20:34:40 test kernel: proto=0, frag_id=3661, frag_ptr=0, sock=0 nat527 showtotal: Sep 9 23:09:04 test kernel: total: 34404 Sep 9 23:09:04 test kernel: icmp=1, udp=13112, tcp=20069, sctp=0, pptp=0, Sep 9 23:09:04 test kernel: proto=0, frag_id=1222, frag_ptr=0, sock=0 nat528 showtotal: Sep 9 20:34:43 test kernel: total: 14536 Sep 9 20:34:43 test kernel: icmp=1, udp=5083, tcp=8671, sctp=0, pptp=0, Sep 9 20:34:43 test kernel: proto=0, frag_id=781, frag_ptr=0, sock=0 nat529 showtotal: Sep 9 23:09:05 test kernel: total: 22115 Sep 9 23:09:05 test kernel: icmp=1, udp=9031, tcp=13075, sctp=0, pptp=0, Sep 9 23:09:05 test kernel: proto=0, frag_id=8, frag_ptr=0, sock=0 Переделал эти инстансы на ipfw nat видом: ipfw nat tablearg ip from table(83) to any out xmit igb0 ipfw nat tablearg ip from any to table(93) in recv igb0 , где table(83) - серые адреса с уникальным табличным аргументом, а table(93) - белые с соответствующими табличными аргументами. Короче, на каждую небольшую подсеть свой инстанс. Впрочем так и было сделано для ng_nat. Насколько это эффективно, может будет сказать только завтра вечером. Отпишусь. Edited September 9, 2014 by vasaf Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted September 9, 2014 · Report post В лоадере: # NetISR net.isr.maxthreads="1024" # Use at most this many CPUs for netisr processing net.isr.bindthreads="1" # Bind netisr threads to CPUs. net.isr.defaultqlimit="16384" # Default netisr per-protocol, per-CPU queue limit if not set by protocol net.isr.maxqlimit="16384" # Maximum netisr per-protocol, per-CPU queue depth. # NetGraph #net.graph.threads="0" # Number of queue processing threads // 0 = auto, num CPUs net.graph.maxalloc="65535" # Maximum number of non-data queue items to allocate / limit the damage of a leak net.graph.maxdata="65535" # Maximum number of data queue items to allocate / limit the damage of a DoS в сисцтл: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=4096 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero # ng_socket net.graph.maxdgram=128000 # Maximum outgoing Netgraph datagram size / really max datagram size net.graph.recvspace=128000 # Maximum space for incoming Netgraph datagrams / если у меня что то меньше чем у вас - у меня потребности просто никакие, не уменьшайте. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vasaf Posted September 17, 2014 · Report post Всем спасибо за советы. На будущее приму во внимание. В итоге после последних изменений (замена части пула ната ng_nat на ipfw nat) прошла неделя. Подобных проблем замечено не было. Фря не обновлялась. sysctl.conf и loader.conf не менялись. netstat -w 1 -hd -I igb0 показывал выше 105k пакетов на вход и 500-600мбит/с трафика максимальное количество записей в одном инстансе ipfw nat - 22600 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted September 19, 2014 · Report post Вывод? Недостаточный тюнинг Нетграфа. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DVM-Avgoor Posted September 20, 2014 · Report post Там нечего тюнить кроме буферов, так что ТС все правильно сделал уйдя на ipfw nat. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
