Перейти к содержимому
Калькуляторы

FreeBSD 9.1 Ошибки на входе в igb0. igb0 input errors

Приветствую всех!

Помогите разобраться с проблемой или подскажите где еще можно посмотреть, т.к. поиск в инете и на НАГе не привел ни к какому результату.

Стоит фря 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

Поделиться сообщением


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

1) 9.1 - старая шарманка, переходите на 10.0-STABLE.

2) ng_nat не всегда самое удачное решение, особенно сейчас, когда ipfw сам все может. Используйте ipfw nat, чтобы не страдать от ng_queue на одном ядре.

3) без этого тюнинга в sysctl.conf (кроме netgraph, с ним все логично) заметно хуже работает?

Поделиться сообщением


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

Спасибо за ответ.

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

Поделиться сообщением


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

Стоит фря 9.1

Для начала надо обновится хотя бы до 9.3 стебла, в 9.1 очень много проблем было именно с нетграфом

 

Ещё как вариант проверьте кабель.

Изменено пользователем polmax

Поделиться сообщением


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

2. попробуем реализовать ipfw nat, но мне кажется это не поможет. К тому же, при ng_nat тот же ng_queue создается по каждому на одно ядро и работают они на разных ядрах, или я ошибаюсь?:

 

 

У вас в топе видно, как оно работает. Т.е. вы можете четко видеть, что у вас работают по-сути все ng_queue на 6-ом ядре. Вот такая петрушка. Вам однозначно на ipfw nat.

 

3. Разница почти никакой, скорее всего даже нет разницы. Постепенно пришел к этим параметрам проверяя все, что может как-то влиять на входящий трафик.

 

Я к тому веду, что вы когда 10-ку поставите, не торопитесь это же самое "тюнить". Многие параметры без тонкой оценки могут и хуже сделать, пробуйте в дефолте.

Да, еще у ipfw nat надо сделать много инстансов, в одном инстансе оно не будет никак параллелиться.

Поделиться сообщением


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

Итак, предварительный итог:

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.

 

Насколько это эффективно, может будет сказать только завтра вечером. Отпишусь.

Изменено пользователем vasaf

Поделиться сообщением


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

В лоадере:

# 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 /

 

 

если у меня что то меньше чем у вас - у меня потребности просто никакие, не уменьшайте.

Поделиться сообщением


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

Всем спасибо за советы. На будущее приму во внимание.

 

В итоге после последних изменений (замена части пула ната ng_nat на ipfw nat) прошла неделя. Подобных проблем замечено не было. Фря не обновлялась. sysctl.conf и loader.conf не менялись.

 

netstat -w 1 -hd -I igb0

показывал выше 105k пакетов на вход и 500-600мбит/с трафика

 

максимальное количество записей в одном инстансе ipfw nat - 22600

Поделиться сообщением


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

Вывод?

Недостаточный тюнинг Нетграфа.

Поделиться сообщением


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

Там нечего тюнить кроме буферов, так что ТС все правильно сделал уйдя на ipfw nat.

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.