mlevel Опубликовано 21 февраля, 2011 (изменено) · Жалоба привет. есть бордер, занимаеться он 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. Изменено 21 февраля, 2011 пользователем mlevel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cmhungry Опубликовано 21 февраля, 2011 · Жалоба попробуйте вятту Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Info-lan Опубликовано 21 февраля, 2011 · Жалоба Все зависит от того что написано в NAT(pf) + файрвол ipfw. В принципе если правила пооптимизировать наверное можно выжать по 500 in + 500 out на каждом интерфейсе на данном железе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
X-RaY™ Опубликовано 21 февраля, 2011 · Жалоба Не совсем в тему, но все же. Не рассматриваете вариант апгрейда, с учетом продажи этого сервера, выйдет в 500-600уе(i7) и прожует до 1.5-2 гига. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 февраля, 2011 (изменено) · Жалоба Возможно, что узким местом является pf, который не масштабируется на SMP. Надо либо прибить его к определенному процессору, либо отказаться от него и использовать ipfw kernel NAT (libalias). Проц стоит заменить на какой-нибудь из десктопных, у которого больше ядер и частоты. Еще вижу кучу ненужного на роутере тюнинга сокетных буферов и TCP, но не вижу net.inet.ip.intr_queue_maxlen = 1024. Еще можно увеличить *_int_delay, *_abs_int_delay. Изменено 22 февраля, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 22 февраля, 2011 · Жалоба irq256: em0 610681168 15185irq257: em1 724979183 18027 ето у Вас счетчики переполнились, или действительно столько прерываний? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 22 февраля, 2011 · Жалоба не вижу net.inet.ip.intr_queue_maxlen = 1024. Думаю, что для этого сначала надо всё же проверить net.inet.ip.intr_queue_drops. Если он в нулях, то смысла увеличивать net.inet.ip.intr_queue_maxlen, насколько мне известно, нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 22 февраля, 2011 · Жалоба господи кто додумался BGP и NAT повесить на одну машину? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 22 февраля, 2011 · Жалоба Думаю, что для этого сначала надо всё же проверить 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 практически ничего больше нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 февраля, 2011 (изменено) · Жалоба Думаю, что для этого сначала надо всё же проверить 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 пакетов) Изменено 22 февраля, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 22 февраля, 2011 · Жалоба photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 22 февраля, 2011 (изменено) · Жалоба photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?! По умолчанию intr_queue_maxlen вообще 10, поэтому совет "уменьшить до 100" связан с подгонкой размера этой очереди к предполагаемому размеру приемных буферов сетевух. На дешевых десктопных сетевухах он может быть около 100 пакетов. Ненулевые значения net.inet.ip.intr_queue_drops означают переполнение очереди. Поскольку она там не переполняется даже при дефолтной длине 10, я делаю вывод, что ее нужно увеличить, как и задержки для interrupt mitigation. Изменено 22 февраля, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 22 февраля, 2011 · Жалоба просто не пользовался янндеховыми драйверами, тама должна где-то быть статистика от карточек, sysctl dev.em ? А то, судя по картинке, у Вас еще остается айдл спу, а трафик получается больше не лезет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 22 февраля, 2011 · Жалоба Свободного проца остается до 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 22 февраля, 2011 · Жалоба нечего не понятно :) надоспршивать народ з яндех драйверами хотя, зачем ему флов-контрол? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 22 февраля, 2011 · Жалоба вообще то и до дров Яндекса он также себя вел.. они мне не помогли.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 22 февраля, 2011 · Жалоба photon, уверен? jab в своё время как раз наоборот, рекомендовал его уменьшать. И что тогда означает net.inet.ip.intr_queue_drops, как не то, что переполнения очереди?! Не выдирайте из контекста, я рекомендовал уменьшать с 4096 при мелкой нагрузке. вообще то и до дров Яндекса он также себя вел.. они мне не помогли.. C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 22 февраля, 2011 · Жалоба C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают. а почему? как сделать лучше? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 22 февраля, 2011 · Жалоба Что там делает POLLING в ядре, и нахрена тогда тюнинг таймаутов в dev.em ? C pfnat'ом дрова яндекса на двух ядрах не помогут, а только помешают.а почему? как сделать лучше? Потому что на каждую очередь он постоянно лопатит таблицу states. Выкинуть дрова яндекса, выкинуть поллинг из ядра. Задрать таймауты в dev.em. Поставить optimization aggressive в pf. Выкинуть ipfw, перевести таблицы в pf. Дальше уже по показаниям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 23 февраля, 2011 · Жалоба а, там еще и полинг :) а так интересно, куда "лишние" пакеты то пропадают? цпу айдл есть, дропов нет, где они? vmstat -z | grep -v 0$ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 23 февраля, 2011 (изменено) · Жалоба Вот только запугивать людей не надо раньше времени. Ядро можно не пересобирать. Чтобы полинг заработал, его надо специально включить на каждом интерфейсе с помощью ifconfig. Если он не включен, все обрабатывается прерываниями. Изменено 23 февраля, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 23 февраля, 2011 · Жалоба Вот только запугивать людей не надо раньше времени. Ядро можно не пересобирать. Чтобы полинг заработал, его надо специально включить на каждом интерфейсе с помощью ifconfig. Если он не включен, все обрабатывается прерываниями. Не буду спорить, по восьмеркам c поллингом у меня информации маловато, а rtfsить лень. Но на всех старых системах простое включение поллинга в ядре ломало нафик все таймауты dev.em. Это просто проверить, нужно засечь под нагрузкой cpu load при дефолтных таймаутах dev.em, а потом при 1000/3000. Разница должна быть заметна на глаз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 23 февраля, 2011 (изменено) · Жалоба Блин, треш какой-то с тюнингом, чем больше понимаю, тем больше понимаю, что нихрена не понимаю. Вот у меня сейчас так, например: #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 Изменено 23 февраля, 2011 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 23 февраля, 2011 · Жалоба cpuset ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 23 февраля, 2011 · Жалоба 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...