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

FreeBSD бордер - вижать максимум

привет.

есть бордер, занимаеться он BGP(default route) и NAT(pf) + файрвол ipfw (30 правил типа allow, deny).

Надо прокачать 500 Мбит трафика, но не получаеться никак.

 

система:

[border:/]# uname -a
FreeBSD border.example.com 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #7: Mon Feb 21 03:19:43 UTC 2011     root@border.example.com:/usr/obj/usr/src/sys/BORDER  i386

[b]процессор:[/b]
[border:/]# cat /var/run/dmesg.boot | grep -i cpu
CPU: Intel(R) Xeon(R) CPU            3040  @ 1.86GHz (1869.54-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs

 

RAM: 1Gb

 

сетевухи:

[border:/]# pciconf -lv
em0@pci0:3:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)'
    class      = network
    subclass   = ethernet
em1@pci0:3:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)'
    class      = network
    subclass   = ethernet

em0 - внутренняя, em1 - внешняя.

 

такая картина:

[border:/]# top -SPH
last pid: 40796;  load averages:  1.97,  2.10,  2.19                                                                                            up 0+11:09:40  22:23:14
128 processes: 7 running, 98 sleeping, 23 waiting
CPU 0:  0.0% user,  0.0% nice, 72.2% system,  1.5% interrupt, 26.3% idle
CPU 1:  0.0% user,  0.0% nice, 72.4% system,  1.5% interrupt, 26.1% idle
Mem: 27M Active, 136M Inact, 231M Wired, 40K Cache, 111M Buf, 599M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
    0 root     104    0     0K   112K CPU1    1 265:23 39.65% {em1_rx0_1}
    0 root      76    0     0K   112K RUN     0 264:54 37.70% {em1_rx0_0}
    0 root      71    0     0K   112K RUN     0 229:21 33.25% {em0_rx0_0}
    0 root      71    0     0K   112K RUN     0 229:43 32.52% {em0_rx0_1}
   10 root     171 ki31     0K    16K RUN     1 157:01 30.22% {idle: cpu1}
   10 root     171 ki31     0K    16K RUN     0 138:35 28.81% {idle: cpu0}
   11 root      16    -     0K   184K WAIT    1  11:37  0.68% {swi16: em0_tx}
   11 root      16    -     0K   184K WAIT    1  10:05  0.63% {swi16: em1_tx}
    7 root      45    -     0K     8K pftm    0   7:50  0.54% pfpurge
   11 root     -32    -     0K   184K WAIT    0   4:56  0.00% {swi4: clock}

[border:/]# netstat -hw1
            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
       77K     0     0        55M        77K     0        55M     0
       78K     0     0        56M        77K     0        56M     0
       74K     0     0        53M        73K     0        53M     0
       75K     0     0        53M        74K     0        53M     0

 

[border:/]# vmstat -i
interrupt                          total       rate
irq1: atkbd0                        1433          0
irq4: uart0                         3150          0
irq6: fdc0                             8          0
irq14: ata0                           35          0
irq19: uhci1+                     197489          4
cpu0: timer                     80311390       1997
irq256: em0                    610681168      15185
irq257: em1                    724979183      18027
cpu1: timer                     80311275       1996
Total                         1496485131      37211

[b]тюнинг:[/b]
[border:/]# cat /etc/sysctl.conf
net.inet.ip.fw.one_pass=1
kern.corefile=/tmp/%U.%N.%P.core
net.inet.tcp.msl=7500
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=0
net.inet.icmp.icmplim=250
kern.ipc.somaxconn=16384
net.inet.ip.redirect=0
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=0
net.inet.ip.fastforwarding=1
net.inet.ip.dummynet.io_fast=1

kern.ipc.nmbclusters=262144
net.inet.ip.dummynet.hash_size=32768
net.inet.tcp.delayed_ack=0
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.maxtcptw=40960
kern.ipc.maxsockbuf=384000  
kern.ipc.maxsockets=262144

dev.em.0.tx_int_delay=100
dev.em.0.rx_int_delay=100
dev.em.1.rx_int_delay=100
dev.em.1.tx_int_delay=100

dev.em.0.rx_abs_int_delay=600
dev.em.0.tx_abs_int_delay=600
dev.em.1.tx_abs_int_delay=600
dev.em.1.rx_abs_int_delay=600

net.inet.ip.fw.dyn_max=65535
net.inet.tcp.recvspace=65535
net.inet.tcp.recvspace=65535
net.inet.ip.ttl=128
net.inet.ip.fw.dyn_buckets=2048
net.inet.ip.fw.dyn_syn_lifetime=10
net.inet.ip.fw.dyn_ack_lifetime=120

net.inet.tcp.sack.enable=0
net.inet.tcp.drop_synfin=1
net.inet.tcp.nolocaltimewait=1
net.inet.ip.rtmaxcache=1024
net.local.stream.recvspace=32768
net.local.stream.sendspace=32768

 

/boot/loader.conf - не трогал.

 

ядро:

#options        AUDIT                   # Security event auditing
#options        MAC                     # TrustedBSD MAC Framework
#options        FLOWTABLE               # per-cpu routing cache
#options        KDTRACE_HOOKS           # Kernel DTrace hooks
#options        INCLUDE_CONFIG_FILE     # Include this file in kernel

# Personalization
options         KVA_PAGES=512
options         DEVICE_POLLING
options         HZ=2000

device          pf
device          pflog
device          pfsync
device          carp
device          lagg

device          if_bridge

options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

options         SC_DISABLE_REBOOT
options         SC_HISTORY_SIZE=10000

options         IPFIREWALL
options         IPFIREWALL_VERBOSE      # enable logging to syslogd(8)
options         IPFIREWALL_VERBOSE_LIMIT=100    # limit verbosity
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPFIREWALL_FORWARD
options         IPDIVERT
options         DUMMYNET

options         IPFIREWALL_NAT
options         LIBALIAS

 

что еще сделать, чтобы выжать на такой машине 500Мбит, или мне хочеться странного?

P.S. стоят последние драйвера от Yandex.

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

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


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

Все зависит от того что написано в NAT(pf) + файрвол ipfw.

В принципе если правила пооптимизировать наверное можно выжать по 500 in + 500 out на каждом интерфейсе на данном железе.

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


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

Не совсем в тему, но все же. Не рассматриваете вариант апгрейда, с учетом продажи этого сервера, выйдет в 500-600уе(i7) и прожует до 1.5-2 гига.

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


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

Возможно, что узким местом является pf, который не масштабируется на SMP. Надо либо прибить его к определенному процессору, либо отказаться от него и использовать ipfw kernel NAT (libalias). Проц стоит заменить на какой-нибудь из десктопных, у которого больше ядер и частоты. Еще вижу кучу ненужного на роутере тюнинга сокетных буферов и TCP, но не вижу net.inet.ip.intr_queue_maxlen = 1024. Еще можно увеличить *_int_delay, *_abs_int_delay.

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

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


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

irq256: em0 610681168 15185

irq257: em1 724979183 18027

ето у Вас счетчики переполнились, или действительно столько прерываний?

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


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

не вижу net.inet.ip.intr_queue_maxlen = 1024.

Думаю, что для этого сначала надо всё же проверить net.inet.ip.intr_queue_drops. Если он в нулях, то смысла увеличивать net.inet.ip.intr_queue_maxlen, насколько мне известно, нет.

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


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

господи кто додумался BGP и NAT повесить на одну машину?

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


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

Думаю, что для этого сначала надо всё же проверить net.inet.ip.intr_queue_drops. Если он в нулях, то смысла увеличивать net.inet.ip.intr_queue_maxlen, насколько мне известно, нет.

net.inet.ip.intr_queue_drops: 0

 

господи кто додумался BGP и NAT повесить на одну машину?
BGP только default route, ему много ресурсов не надо.

 

ето у Вас счетчики переполнились, или действительно столько прерываний?
получаеться что действительно столько прерываний. ребут бил не задолго до этого.

 

Думал про ipfw kernel nat, но там больно неудобно делаеться round-robin.

В PF кроме :

nat on $ext_if from <int_net> to any -> $external source-hash

практически ничего больше нет.

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


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

Думаю, что для этого сначала надо всё же проверить net.inet.ip.intr_queue_drops. Если он в нулях, то смысла увеличивать net.inet.ip.intr_queue_maxlen, насколько мне известно, нет.

net.inet.ip.intr_queue_drops: 0

Так потому и 0, что прерывания часто дергаются, и очередь не заполняется. Чтобы уменьшить число прерываний в секунду, надо увеличить задежки для interrupt mitigation и длину intr_queue_maxlen. Длина примерно должна соответствовать размеру приемного буфера у сетевух (в серверных моделях обычно что-то около 1024 пакетов)
Изменено пользователем photon

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


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

photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?!

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


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

photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?!

По умолчанию intr_queue_maxlen вообще 10, поэтому совет "уменьшить до 100" связан с подгонкой размера этой очереди к предполагаемому размеру приемных буферов сетевух. На дешевых десктопных сетевухах он может быть около 100 пакетов. Ненулевые значения net.inet.ip.intr_queue_drops означают переполнение очереди. Поскольку она там не переполняется даже при дефолтной длине 10, я делаю вывод, что ее нужно увеличить, как и задержки для interrupt mitigation.

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

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


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

просто не пользовался янндеховыми драйверами, тама должна где-то быть статистика от карточек, sysctl dev.em ?

А то, судя по картинке, у Вас еще остается айдл спу, а трафик получается больше не лезет?

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


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

Свободного проца остается до 20%, а трафик не лезет ни вкакую.

 

dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5.Yandex[$Revision: 1.36.2.17.2.18 $]
dev.em.0.%driver: em
dev.em.0.%location: slot=0 function=0
dev.em.0.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000
dev.em.0.%parent: pci3
dev.em.0.nvm: -1
dev.em.0.tx_cleanup_threshold: 512
dev.em.0.max0_gprc: 60493
dev.em.0.max0_gptc: 65235
dev.em.0.max0_gorc: 4153635711
dev.em.0.max0_gotc: 4002910423
dev.em.0.max1_gprc: 60493
dev.em.0.max1_gptc: 65235
dev.em.0.max1_gorc: 4153635711
dev.em.0.max1_gotc: 4002910423
dev.em.0.max2_gprc: 60493
dev.em.0.max2_gptc: 65235
dev.em.0.max2_gorc: 4153635711
dev.em.0.max2_gotc: 4002910423
dev.em.0.max3_gprc: 60493
dev.em.0.max3_gptc: 65235
dev.em.0.max3_gorc: 4153635711
dev.em.0.max3_gotc: 4002910423
dev.em.0.max4_gprc: 60493
dev.em.0.max4_gptc: 65235
dev.em.0.max4_gorc: 4153635711
dev.em.0.max4_gotc: 4002910423
dev.em.0.link_irq: 0
dev.em.0.mbuf_alloc_fail: 0
dev.em.0.cluster_alloc_fail: 0
dev.em.0.dropped: 0
dev.em.0.tx_dma_fail: 0
dev.em.0.fc_high_water: 30720
dev.em.0.fc_low_water: 29220
dev.em.0.mac_stats.excess_coll: 0
dev.em.0.mac_stats.symbol_errors: 0
dev.em.0.mac_stats.sequence_errors: 0
dev.em.0.mac_stats.defer_count: 1542
dev.em.0.mac_stats.missed_packets: 0
dev.em.0.mac_stats.recv_no_buff: 0
dev.em.0.mac_stats.recv_errs: 0
dev.em.0.mac_stats.crc_errs: 0
dev.em.0.mac_stats.alignment_errs: 0
dev.em.0.mac_stats.coll_ext_errs: 0
dev.em.0.mac_stats.rx_overruns: 0
dev.em.0.mac_stats.watchdog_timeouts: 0
dev.em.0.mac_stats.xon_recvd: 1571
dev.em.0.mac_stats.xon_txd: 54
dev.em.0.mac_stats.xoff_recvd: 1571
dev.em.0.mac_stats.xoff_txd: 54
dev.em.0.mac_stats.total_pkts_recvd: 536588517
dev.em.0.mac_stats.good_pkts_recvd: 536585373
dev.em.0.mac_stats.bcast_pkts_recvd: 472
dev.em.0.mac_stats.mcast_pkts_recvd: 191
dev.em.0.mac_stats.rx_frames_64: 166623088
dev.em.0.mac_stats.rx_frames_65_127: 158952364
dev.em.0.mac_stats.rx_frames_128_255: 20056959
dev.em.0.mac_stats.rx_frames_256_511: 8807104
dev.em.0.mac_stats.rx_frames_512_1023: 15767562
dev.em.0.mac_stats.rx_frames_1024_1522: 166378295
dev.em.0.mac_stats.good_octets_recvd: 284216947910
dev.em.0.mac_stats.good_octest_txd: 619176742674
dev.em.0.mac_stats.total_pkts_txd: 612948123
dev.em.0.mac_stats.good_pkts_txd: 612948012
dev.em.0.mac_stats.bcast_pkts_txd: 733
dev.em.0.mac_stats.mcast_pkts_txd: 0
dev.em.0.mac_stats.tx_frames_64: 54846219
dev.em.0.mac_stats.tx_frames_65_127: 100648507
dev.em.0.mac_stats.tx_frames_128_255: 28048166
dev.em.0.mac_stats.tx_frames_256_511: 17082220
dev.em.0.mac_stats.tx_frames_512_1023: 19723242
dev.em.0.mac_stats.tx_frames_1024_1522: 392599662
dev.em.0.mac_stats.tso_txd: 17
dev.em.0.mac_stats.tso_ctx_fail: 0
dev.em.0.interrupts.asserts: 0
dev.em.0.interrupts.rx_pkt_timer: 0
dev.em.0.interrupts.rx_abs_timer: 0
dev.em.0.interrupts.tx_pkt_timer: 0
dev.em.0.interrupts.tx_abs_timer: 0
dev.em.0.interrupts.tx_queue_empty: 0
dev.em.0.interrupts.tx_queue_min_thresh: 0
dev.em.0.interrupts.rx_desc_min_thresh: 0
dev.em.0.interrupts.rx_overrun: 0
dev.em.0.host.breaker_tx_pkt: 0
dev.em.0.host.host_tx_pkt_discard: 0
dev.em.0.host.rx_pkt: 0
dev.em.0.host.breaker_rx_pkts: 0
dev.em.0.host.breaker_rx_pkt_drop: 0
dev.em.0.host.tx_good_pkt: 0
dev.em.0.host.breaker_tx_pkt_drop: 0
dev.em.0.host.rx_good_bytes: 0
dev.em.0.host.tx_good_bytes: 0
dev.em.0.host.length_errors: 0
dev.em.0.host.serdes_violation_pkt: 0
dev.em.0.host.header_redir_missed: 0
dev.em.0.rx_int_delay: 600
dev.em.0.tx_int_delay: 600
dev.em.0.rx_abs_int_delay: 600
dev.em.0.tx_abs_int_delay: 600
dev.em.0.rx_kthread_priority: 127
dev.em.0.rx_kthreads: 2
dev.em.0.rx_kth_bind: 123456
dev.em.0.rx_irq: 0
dev.em.0.tx_irq: 0
dev.em.0.br_drops: 0

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


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

нечего не понятно :) надоспршивать народ з яндех драйверами

 

хотя, зачем ему флов-контрол?

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


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

вообще то и до дров Яндекса он также себя вел.. они мне не помогли..

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


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

photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?!

Не выдирайте из контекста, я рекомендовал уменьшать с 4096 при мелкой нагрузке.

 

вообще то и до дров Яндекса он также себя вел.. они мне не помогли..

C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают.

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


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

C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают.

а почему? как сделать лучше?

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


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

 

Что там делает POLLING в ядре, и нахрена тогда тюнинг таймаутов в dev.em ?

 

C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают.
а почему? как сделать лучше?

Потому что на каждую очередь он постоянно лопатит таблицу states.

 

Выкинуть дрова яндекса, выкинуть поллинг из ядра. Задрать таймауты в dev.em. Поставить optimization aggressive в pf. Выкинуть ipfw, перевести таблицы в pf. Дальше уже по показаниям.

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


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

а, там еще и полинг :)

 

а так интересно, куда "лишние" пакеты то пропадают? цпу айдл есть, дропов нет, где они?

 

vmstat -z | grep -v 0$

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


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

Вот только запугивать людей не надо раньше времени. Ядро можно не пересобирать. Чтобы полинг заработал, его надо специально включить на каждом интерфейсе с помощью ifconfig. Если он не включен, все обрабатывается прерываниями.

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

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


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

Вот только запугивать людей не надо раньше времени. Ядро можно не пересобирать. Чтобы полинг заработал, его надо специально включить на каждом интерфейсе с помощью ifconfig. Если он не включен, все обрабатывается прерываниями.

Не буду спорить, по восьмеркам c поллингом у меня информации маловато, а rtfsить лень. Но на всех старых системах простое включение поллинга в ядре ломало нафик все таймауты dev.em.

Это просто проверить, нужно засечь под нагрузкой cpu load при дефолтных таймаутах dev.em, а потом при 1000/3000. Разница должна быть заметна на глаз.

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


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

Блин, треш какой-то с тюнингом, чем больше понимаю, тем больше понимаю, что нихрена не понимаю.

Вот у меня сейчас так, например:

#top -aSCHIP

last pid: 27709;  load averages:  3.06,  2.71,  2.65                                                  up 126+04:29:41 16:30:11
105 processes: 10 running, 79 sleeping, 16 waiting
CPU 0:  0.0% user,  0.0% nice, 25.0% system,  2.8% interrupt, 72.2% idle
CPU 1:  0.0% user,  0.0% nice, 38.9% system,  1.4% interrupt, 59.7% idle
CPU 2:  0.0% user,  0.0% nice, 75.0% system,  1.4% interrupt, 23.6% idle
CPU 3:  0.0% user,  0.0% nice, 77.8% system,  0.0% interrupt, 22.2% idle
Mem: 181M Active, 1221M Inact, 505M Wired, 51M Cache, 199M Buf, 43M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   25 root           43    -     0K     8K CPU0    0 609.0H 69.87% [em0_rx0_0]
   12 root          171 ki31     0K     8K RUN     1 1880.5 66.06% [idle: cpu1]
   13 root          171 ki31     0K     8K RUN     0 1654.6 59.38% [idle: cpu0]
   26 root           43    -     0K     8K CPU3    3 606.5H 55.18% [em0_rx0_1]
   29 root           43    -     0K     8K CPU2    2 576.6H 51.66% [em1_rx0_0]
   30 root           43    -     0K     8K WAIT    3 576.0H 51.07% [em1_rx0_1]
   11 root          171 ki31     0K     8K RUN     2 3003.2 19.09% [idle: cpu2]
   10 root          171 ki31     0K     8K RUN     3 3003.1 18.36% [idle: cpu3]
   27 root           16    -     0K     8K RUN     3  33.8H  2.29% [swi16: em1_tx]
   23 root           16    -     0K     8K RUN     2  34.8H  1.86% [swi16: em0_tx]
   37 root            8    -     0K     8K pftm    0  32.2H  1.86% [pfpurge]
   15 root          -32    -     0K     8K WAIT    0  58.8H  1.66% [swi4: clock]

 

C таким трафиком:

# netstat -I em0 -idh 1
            input          (em0)           output
   packets  errs      bytes    packets  errs      bytes colls drops
       56K     0        45M        49K     0        34M     0     0
       54K     0        43M        48K     0        33M     0     0
       54K     0        43M        48K     0        35M     0     0
       56K     0        43M        49K     0        34M     0     0
       55K     0        42M        51K     0        35M     0     0
       56K     0        44M        48K     0        33M     0     0
^C

 

И такими настройками:

kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=4096
kern.polling.user_frac=25
net.inet.ip.fastforwarding=1
net.inet.ip.redirect=0
net.inet.tcp.delayed_ack=0
net.inet.tcp.drop_synfin=1
net.inet.tcp.recvspace=65228
net.inet.tcp.sendspace=65228
net.inet.tcp.syncookies=1
net.inet.udp.maxdgram=57344
net.inet.udp.recvspace=65228
net.inet.ip.stealth=1
dev.em.1.rx_kthreads=2
dev.em.1.rx_kthreads=2
dev.em.0.rx_int_delay=900
dev.em.1.rx_int_delay=900
dev.em.0.tx_int_delay=900
dev.em.1.tx_int_delay=900
dev.em.0.rx_abs_int_delay=1800
dev.em.1.rx_abs_int_delay=1800
dev.em.0.tx_abs_int_delay=1800
dev.em.1.tx_abs_int_delay=1800
kern.timecounter.hardware=HPET
net.inet.ip.dummynet.expire=0
kern.ipc.nmbclusters=262144
net.inet.ip.process_options=0
net.raw.sendspace=64000
net.raw.recvspace=64000

 

И все "игры" с net.isr и queue_maxlen, откровенно говоря, влияют чисто гомеопатически.

 

 

Ну да, на сервере ipfw (незначительный, всё лень переписать) и pf, а также ng_netflow на интерфейсах. Блин, всё. А нагрузка - в полку получается.

 

pfctl -si

root@Bastinda:/usr/home/dyr (268) pfctl -si
Status: Enabled for 25 days 22:29:51          Debug: Urgent

State Table                          Total             Rate
  current entries                   373699
  searches                    827358197308       369193.0/s
  inserts                      24842902660        11085.7/s
  removals                     24842716921        11085.6/s
Counters
  match                        25536011672        11395.0/s
  bad-offset                             0            0.0/s
  fragment                          190735            0.1/s
  short                             152951            0.1/s
  normalize                         513174            0.2/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                         207162            0.1/s
  proto-cksum                      8293026            3.7/s
  state-mismatch                  34725386           15.5/s
  state-insert                          56            0.0/s
  state-limit                            0            0.0/s
  src-limit                        8775223            3.9/s
  synproxy                               0            0.0/s

 

set limit { states 600000, frags 100000, src-nodes 60000 }
set state-policy if-bound
set optimization normal
set ruleset-optimization profile
set block-policy drop
set fingerprints "/etc/pf.os"
set skip on sk0
scrub in all max-mss 1440
binat-anchor "binat"
load anchor "binat" from "/etc/pf.anchor.binat"
nat on $ext_if from <allow-nat> to any -> <dst_nat1> static-port sticky-address #round-robin
binat on $ext_if from 10.78.78.2 to any -> 93.92.199.252
nat on $ext_if from 10.78.78.0/24 to any -> $dst_nat2 static-port source-hash
pass in all
pass out all
table <spamers> persist
pass in quick on $int_if proto tcp from <allowed-spammers> to any port smtp flags S/SAFR keep state
pass in on $int_if proto tcp from any to any port smtp flags S/SAFR keep state \
                (max-src-conn 15, max-src-conn-rate 15/30, overload <spamers> flush global)
block return-icmp (host-prohib) log quick proto tcp from <spamers> to any port smtp
table <icmp_flooders> persist
pass in inet proto icmp all icmp-type {echoreq, unreach} keep state \
        (max-src-conn 15, max-src-states 15, overload <icmp_flooders> flush global)
block return-icmp (host-prohib) log quick proto icmp from <icmp_flooders> to any
table <dns_flooders> persist
pass in on $int_if inet proto udp from any to any port 53 keep state \
        (max-src-conn 5, max-src-conn-rate 10/10, overload <dns_flooders> flush global)
block return-icmp (host-prohib) log quick proto udp from <dns_flooders> to any port 53

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

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


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

Dyr

 

set limit { states 600000, frags 100000, src-nodes 60000 }

set state-policy if-bound

set optimization normal

 

pfctl -s memory ?

 

Есть вероятность что после set optimization не все Ваши лимиты выживут. И таки поставьте агресив. попроще может стать немного.

 

vmstat -i?

 

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


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

Join the conversation

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

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

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

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

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

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

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