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

ex-transfer

Пользователи
  • Публикации

    45
  • Зарегистрирован

  • Посещение

Все публикации пользователя ex-transfer


  1. Пробовал, резултата 0 (т.е. zero) Ошибки как были, так и остались. Процессоры не разгружались и думминет всё равно жрал 0й проц! Сервер работал так: шли ошибки, но сервер худо-бедно молотил трафик. Потом он начинал генерировать какой-то сумасшедший трафик, и сетевушки переставали работать, на любой ping отвечал network is down Вот что в этот момент было на графике pps интерфейса:
  2. Правила такого вида: ### 10Mbit/s ipfw pipe 84 config queue 87 bw 10485760bit/s mask dst-ip 0xffffffff gred 0.002/50/100/0.1 ipfw pipe 74 config queue 87 bw 10485760bit/s mask src-ip 0xffffffff gred 0.002/50/100/0.1 # === 10 Mbit ipfw add 18100 pipe tablearg ip from any to "table(84)" out xmit vlan700 ipfw add 18100 pipe tablearg ip from "table(74)" to any in recv vlan700 ipfw table 84 add xx.xx.xx.xx/26 84 # !!! GLOBAL IPoE 10 Mbit !!! ipfw table 74 add xx.xx.xx.xx/26 74 # !!! GLOBAL IPoE 10 Mbit !!! Vlan700 в данной схеме - интерфейс к юзерским NAS. Таких правил около 20 (примерно 20 скоростей для тарифов)
  3. Я выше писАл: не вариант. Что-то с правилами может?
  4. Поиск уже перерыл вдоль и поперёк! Тем, где настраивают 82599 не так уж и много. Обновиться до какого релиза? Вчера до последнего пытался понять почему такое происходит - не понял. Почему-то при нагрузке в 100Kpps процессоры грузятся под 50% , а процесс dummynet jn;bhftn 90-100% 0-го ядра!!! Вытащил плату, поставил старые 82572EI. На тех же настройках 500-550 Мбит и 125kpps без потерь на интерфейсах, процессоры загружены под 60%, но процесс dummynet все равно пытается отожрать в пиках до 30% от 0-го ядра! Может у меня в правилах ipfw какая -нибудь ошибка?
  5. Вот картина top -SHP во время зависания (сетевушка bge0 для управления таки работала) last pid: 63745; load averages: 4.05, 3.97, 3.86 up 0+05:43:42 20:28:43 154 processes: 19 running, 97 sleeping, 38 waiting CPU 0: 0.0% user, 0.0% nice, 28.2% system, 61.7% interrupt, 10.1% idle CPU 1: 0.0% user, 0.0% nice, 50.0% system, 4.8% interrupt, 45.2% idle CPU 2: 0.0% user, 0.0% nice, 25.7% system, 56.1% interrupt, 18.2% idle CPU 3: 0.0% user, 0.0% nice, 34.2% system, 28.3% interrupt, 37.4% idle CPU 4: 0.0% user, 0.0% nice, 25.0% system, 59.0% interrupt, 16.0% idle CPU 5: 0.0% user, 0.0% nice, 18.1% system, 66.5% interrupt, 15.4% idle CPU 6: 0.0% user, 0.0% nice, 19.7% system, 57.4% interrupt, 22.9% idle CPU 7: 0.0% user, 0.0% nice, 21.4% system, 52.9% interrupt, 25.7% idle Mem: 25M Active, 12M Inact, 153M Wired, 1392K Cache, 32M Buf, 1783M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -68 - 0K 688K RUN 5 79:46 69.19% {irq270: ix1:que } 12 root -68 - 0K 688K RUN 0 68:00 62.55% {irq265: ix1:que } 12 root -68 - 0K 688K CPU7 7 71:24 59.67% {irq272: ix1:que } 12 root -68 - 0K 688K WAIT 6 68:39 58.59% {irq271: ix1:que } 12 root -68 - 0K 688K CPU4 4 70:01 55.96% {irq269: ix1:que } 12 root -68 - 0K 688K CPU2 2 66:05 52.39% {irq267: ix1:que } 11 root 171 ki31 0K 128K RUN 1 232:52 45.51% {idle: cpu1} 11 root 171 ki31 0K 128K RUN 3 234:07 41.06% {idle: cpu3} 0 root -68 0 0K 416K - 1 35:18 30.91% {ix1 que} 0 root -68 0 0K 416K RUN 3 37:21 30.81% {ix1 que} 0 root -68 0 0K 416K CPU0 4 35:00 30.76% {ix1 que} 0 root -68 0 0K 416K CPU6 3 33:33 30.18% {ix1 que} 0 root -68 0 0K 416K RUN 6 30:09 29.74% {ix1 que} 0 root -68 0 0K 416K RUN 5 33:49 29.69% {ix1 que} 11 root 171 ki31 0K 128K RUN 7 221:25 23.10% {idle: cpu7} 11 root 171 ki31 0K 128K RUN 6 221:14 22.85% {idle: cpu6} 11 root 171 ki31 0K 128K RUN 2 219:13 20.41% {idle: cpu2} 12 root -68 - 0K 688K WAIT 3 39:40 19.29% {irq268: ix1:que } 11 root 171 ki31 0K 128K RUN 5 210:02 17.72% {idle: cpu5} 0 root -68 0 0K 416K - 0 16:18 13.62% {ix1 que} 11 root 171 ki31 0K 128K RUN 4 206:22 13.57% {idle: cpu4} 11 root 171 ki31 0K 128K CPU0 0 120:18 10.21% {idle: cpu0} 12 root -32 - 0K 688K WAIT 2 13:09 4.59% {swi4: clock} 12 root -68 - 0K 688K WAIT 1 26:02 4.44% {irq266: ix1:que } 0 root -68 0 0K 416K - 2 5:38 3.47% {ix1 que} 12 root -68 - 0K 688K WAIT 6 25:20 0.59% {irq262: ix0:que } 12 root -68 - 0K 688K WAIT 0 21:34 0.59% {irq256: ix0:que } 12 root -68 - 0K 688K WAIT 4 27:17 0.29% {irq260: ix0:que } 0 root -68 0 0K 416K - 3 1:03 0.29% {bge0 taskq} 12 root -68 - 0K 688K WAIT 7 27:34 0.24% {irq263: ix0:que } 12 root -68 - 0K 688K WAIT 5 25:59 0.24% {irq261: ix0:que } 12 root -68 - 0K 688K WAIT 1 24:18 0.24% {irq257: ix0:que } 12 root -68 - 0K 688K WAIT 3 25:46 0.20% {irq259: ix0:que } 12 root -68 - 0K 688K WAIT 2 26:36 0.15% {irq258: ix0:que } 0 root -68 0 0K 416K - 0 98:43 0.00% {dummynet} 0 root -68 0 0K 416K - 5 2:43 0.00% {ix0 que} 0 root -68 0 0K 416K - 5 2:42 0.00% {ix0 que} трафика нет совсем, но процы загружены!!! systat -ifstat /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average ||||||||||||||||||| Interface Traffic Peak Total lo0 in 0.071 KB/s 0.071 KB/s 437.163 KB out 0.071 KB/s 0.071 KB/s 437.163 KB vlan190 in 1.947 KB/s 1.947 KB/s 56.355 MB out 85.225 KB/s 85.225 KB/s 934.835 MB vlan250 in 0.035 KB/s 0.035 KB/s 421.114 GB out 0.000 KB/s 0.000 KB/s 267.643 GB vlan700 in 152.644 KB/s 152.644 KB/s 271.049 GB out 2.001 KB/s 2.001 KB/s 414.784 GB netstat -m 16881/12444/29325 mbufs in use (current/cache/total) 16880/11030/27910/262144 mbuf clusters in use (current/cache/total/max) 16880/11024 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/262144 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/64000 9k jumbo clusters in use (current/cache/total/max) 0/0/0/32000 16k jumbo clusters in use (current/cache/total/max) 37980K/25207K/63187K 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 shapper# vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 105, 14, 105, 0 UMA Zones: 448, 0, 105, 7, 105, 0 UMA Slabs: 568, 0, 1332, 5, 1876, 0 UMA RCntSlabs: 568, 0, 13964, 1, 13964, 0 UMA Hash: 256, 0, 1, 14, 3, 0 16 Bucket: 152, 0, 176, 24, 176, 0 32 Bucket: 280, 0, 224, 0, 224, 1 64 Bucket: 536, 0, 201, 2, 201, 105 128 Bucket: 1048, 0, 474, 0, 474, 163 VM OBJECT: 216, 0, 1779, 1011, 1394462, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 87916, 43, 267, 1503, 0 MAP ENTRY: 120, 0, 911, 1135, 2955907, 0 DP fakepg: 120, 0, 0, 0, 0, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 246, 25, 246, 0 16: 16, 0, 2588, 1108, 352544, 0 32: 32, 0, 4322, 1536, 229430, 0 64: 64, 0, 2399, 10817, 1194842424, 0 128: 128, 0, 7612, 827, 11784, 0 256: 256, 0, 1425, 4260, 967350364, 0 512: 512, 0, 1475, 1416, 718469, 0 1024: 1024, 0, 90, 230, 3915, 0 2048: 2048, 0, 50, 84, 281, 0 4096: 4096, 0, 310, 588, 95104, 0 Files: 80, 0, 96, 849, 384936, 0 TURNSTILE: 136, 0, 593, 87, 593, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1120, 0, 47, 343, 64340, 0 THREAD: 984, 0, 494, 98, 494, 0 SLEEPQUEUE: 80, 0, 593, 161, 593, 0 VMSPACE: 392, 0, 28, 262, 64320, 0 cpuset: 72, 0, 19, 131, 19, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 16880, 11024, 992233220, 0 mbuf: 256, 0, 1, 1420, 208605250, 0 mbuf_cluster: 2048, 262144, 27904, 6, 27904, 0 mbuf_jumbo_page: 4096, 262144, 0, 9, 10, 0 mbuf_jumbo_9k: 9216, 64000, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 32000, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 592, 71136, 0 ttyinq: 160, 0, 150, 186, 375, 0 ttyoutq: 256, 0, 80, 130, 200, 0 ata_request: 320, 0, 0, 324, 17837, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 1021, 155, 1113, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 208, 1357126, 0 S VFS Cache: 108, 0, 1041, 312, 4375, 0 L VFS Cache: 328, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 191, 57, 191, 0 NFSMOUNT: 616, 0, 0, 0, 0, 0 NFSNODE: 656, 0, 0, 0, 0, 0 pipe: 728, 0, 2, 313, 49287, 0 ksiginfo: 112, 0, 379, 677, 2657, 0 itimer: 344, 0, 0, 22, 1, 0 KNOTE: 128, 0, 0, 145, 22, 0 socket: 680, 25602, 35, 97, 1058, 0 unpcb: 240, 25600, 12, 164, 183, 0 ipq: 56, 8253, 0, 567, 817, 0 udp_inpcb: 336, 25608, 1, 109, 450, 0 udpcb: 16, 25704, 1, 1007, 450, 0 tcp_inpcb: 336, 25608, 19, 124, 195, 0 tcpcb: 880, 25600, 19, 93, 195, 0 tcptw: 72, 41000, 0, 0, 0, 0 syncache: 144, 15366, 0, 156, 11, 0 hostcache: 136, 15372, 1, 55, 1, 0 tcpreass: 40, 16464, 0, 336, 4, 0 sackhole: 32, 0, 0, 303, 8, 0 sctp_ep: 1272, 25602, 0, 0, 0, 0 sctp_asoc: 2232, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 31, 0 sctp_raddr: 616, 80004, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 96, 400026, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 336, 25608, 2, 86, 228, 0 rtentry: 200, 0, 863, 334, 2636, 0 pfsrctrpl: 152, 10000, 0, 0, 0, 0 pfrulepl: 912, 0, 28, 8, 28, 0 pfstatepl: 392, 300000, 747, 6153, 466291, 0 pfaltqpl: 240, 0, 0, 32, 1, 0 pfpooladdrpl: 88, 0, 10, 74, 10, 0 pfrktable: 1296, 1002, 0, 0, 0, 0 pfrkentry: 216, 5004, 0, 0, 0, 0 pfrkentry2: 216, 0, 0, 0, 0, 0 pffrent: 32, 600041, 0, 0, 0, 0 pffrag: 80, 0, 0, 0, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0 pfstatescrub: 40, 0, 0, 0, 0, 0 pfiaddrpl: 120, 0, 0, 0, 0, 0 pfospfen: 112, 0, 696, 96, 1392, 0 pfosfp: 40, 0, 407, 97, 814, 0 IPFW dynamic rule: 120, 0, 0, 0, 0, 0 selfd: 56, 0, 68, 1696, 3986514, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0 ip4flow: 56, 197694, 0, 0, 0, 0 ip6flow: 80, 197640, 0, 0, 0, 0 Mountpoints: 752, 0, 2, 8, 2, 0 FFS inode: 168, 0, 990, 176, 1077, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 990, 150, 1077, 0
  6. Гуру, хелп! Сервер вообще завис. Поехал пока откатываться на старые платы. Вероятно на 1000Base-T совсем другая картина нежели чем на SFP+
  7. Да стандартные 2.4.4 на фре... скачанные с офсайта... ВО! Вняли молитвам дык ведь сам делал ))) Покажите где нужно #define сделать!
  8. Всем доброго времени суток, ув. форумчане! Давеча заменил две своих старых Intel 82572 на Intel 82599 (X520-DA2). Пока (временно) 10Г - портов на коммутаторах нет, пришлось запускать через 1000Base-T SFP в связке с Cisco3750. После замены при ~50-55 Kpps на интерфейсах сыпятся ошибки. Даже старые 82572 у меня прокачивали 80 кpps (и ~500 Mbut/s), только процы уже к 100% подгружались. Система FreeBSD 8.1-RELEASE #13 CPU: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (2010.98-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.4> port 0xe880-0xe89f mem 0xfffd80000-0xfffdfffff,0xfffe78000-0xfffe7bfff irq 16 at device 0.0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.4> port 0xec00-0xec1f mem 0xfffe80000-0xfffefffff,0xfffe7c000-0xfffe7ffff irq 17 at device 0.1 on pci3 ix1: Using MSIX interrupts with 9 vectors ix1: RX Descriptors exceed system mbuf max, using default instead! ix1: PCI Express Bus: Speed 2.5Gb/s Width x8 Использую PF Nat + Dummynet (прибит к 0 корке) Что делать? Как жить? Вот sysctl.conf: dev.ix.0.rx_processing_limit=2048 dev.ix.1.rx_processing_limit=2048 net.inet.ip.redirect=0 net.inet.ip.fastforwarding=1 net.inet.tcp.maxtcptw=40960 net.inet.tcp.blackhole=1 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=500 net.inet.ip.fw.dyn_buckets=2048 # FLOWTABLE OFF net.inet.flowtable.enable=0 # ISR net.isr.direct=1 net.isr.direct_force=1 # DUMMYNET net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.one_pass=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 loader.conf: ixgbe_load="YES" kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbop=262144 kern.ipc.nmbjumbo16=32000 kern.ipc.nmbjumbo9=64000 Вот графики с интерфейсов: (ужас, который по-середине, это я пробовал LRO включить )))
  9. да любой 1310/1550 одноволоконник WDM на циске - service unsupported transceiver включи (в хелпе по '?' нет такой команды, вводи внаглую)
  10. Наговские SNR-SFP-W35-20 пойдут и циска их как свои родные поймет
  11. А ларчик просто открывался. На непатченных драйверах 1000Base-T заработал на ура! На патченных - не поднимается линк на сетевушке. Видимо нужно принять как данное ))
  12. смысл в том что пока нет ответных 10G портов. К новому году только появится модуль в 76-ю циску
  13. а если б однустрочку в драйвере пропатчил, то завелась бы и с неродными SFP+ Вопрос в том, почему она линк не подняла на медной 1G SFP-шке
  14. Доброго всем времени суток! Заказал сабжевый девайс, пропатчил самые свежие дрова на линуксе, попробовал завести на наговских 1000BASE-T SFP модулях. Воткнул в Длинк 3526 и в плату. На коммутаторе линк поднимается, на плате нет. В логах dmesg: [56251.486205] ADDRCONF(NETDEV_UP): eth1: link is not ready root@xxx-u11:# ip link show eth1 4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 90:e2:ba:27:fe:50 brd ff:ff:ff:ff:ff:ff Что покрутить? На интеле написано: И чего надо?!
  15. у меня не ipfw nat, a pf... и не на ng* надо переходить, а вообще искоренять его к чертям ))) именно поэтому почти все хомяки теперь сидят на белых IP. Остались только те рудименты, которые сидят на древних pppoe (cisco 28хх). И их в скором будущем тоже переведу на белые. Кстати, nat-states в потолке 20к... могут ли они пожрать все процы до 50% ? to Vurd: начитался про flowtable. пока решил его выключить через sysctl. Посмотрим что изменится. Если будет лучше - выкину из ядра.
  16. Спасибо за ссылочки, очень полезные! В моём случае дело было в следующем: после 9ти вечера загружался фаер pf с правилами запрета всяких icmp и другой ерунды, касающихся dos атак. В дневном конфиге этого не было в принципе. После чистки конфига pf от фильтров icmp, и прибития процесса dummynet к нулевому ядру: [CPU] [PPS] [Trafic] Т.е. фактически нагрузка спала в два раза, но, боюсь, и ЭТА нагрузка великовата.
  17. нет, не выкинуто. если выкинуть, то какие изменения будут?
  18. Ничегошеньки. Вот: shapper# pfctl -sr no scrub all pass all no state По дамминету - который грузил проц на 100% возможно что разобрался сам. Я его почему-то прибивал к 1-му ядру. Прибил к 0-му, он стал жрать... 0% . Наверное какоя бага или фича самого дамминета. Посмотрим сегодня что ночью произойдёт, когда все хомяки будут за компами и начнуть грузить канал.
  19. Пакеты фильтруются ipfw Да, каждая /25 подсеть под свой тариф. До правила 20120 доходит, т.к. под ним есть правила что все те сети что не в таблицах - в режект. И если вдруг я забыл какую-то сеть вписать, юзеры сидят бкз инета.
  20. Доброго времени суток, уважаемые! Мой сервачок что-то совсем захворал.. При трафике порядка ~230 мбит загибаются процы под 100%. Сетевые потоки {emX_rx_X} прибиты к процам. По два потока(in/out) на проц. Дамминет прибит к одному процу, но всё равно жрёт 100%... Плюс ко всему этому иногда (раз в две недели) сервак ещё и зависает намертво сволочь. Температура в норме.. память проверял. Начитался много всего, если честно уже полная каша в голове. Вот например вчерашний случай: сервак после загрузки ночных таблиц в память (в 9 вечера, удвоение скорости) поработал под нагрузкой 100% и завис. Нагрузка на один из процов: PPS на одной из карточек (сторона юзеров): Трафик на ней же: И немного ната (pf): Недавно перевели 99% пользователей на реальные ипишники (динамика с пулов dhcp), в таблицах теперь короткие записи вида: ipfw table 70 add xx.xx.xx.xx/25 70 ipfw table 40 add xx.xx.xx.xx/25 40 и т.д.. В глобальном конфиге ipfw тоже ничего особенного нет (но хз, может и есть). Вот кусочек для 3х мегабит например: #== 3 Mbit pipe ipfw pipe 70 config queue 74 bw 3145728bit/s mask dst-ip 0xffffffff gred 0.002/34/75/0.1 ipfw pipe 40 config queue 74 bw 3145728bit/s mask src-ip 0xffffffff gred 0.002/34/75/0.1 # === 3 Mbit ipfw add 15000 pipe tablearg ip from any to "table(70)" out xmit vlan700 ipfw add 15000 pipe tablearg ip from "table(40)" to any in recv vlan700 ipfw add 20120 allow ip from any to "table(70)".. ipfw add 20130 allow ip from "table(40)" to any. Стоит HP DL180G5 1хXeon 5405 + две внешние карты 82572EI PRO/1000 PT Desktop Adapter (em) яндекс-драйверы... Intel(R) PRO/1000 Network Connection 6.9.14.Yandex[$Revision: 1.36.2.17.2.6 $] тюнинга не много dev.em.0.rx_int_delay=750 dev.em.0.tx_int_delay=750 dev.em.0.rx_abs_int_delay=1500 dev.em.0.tx_abs_int_delay=1500 dev.em.1.rx_int_delay=750 dev.em.1.tx_int_delay=750 dev.em.1.rx_abs_int_delay=1500 dev.em.1.tx_abs_int_delay=1500 dev.em.0.rx_processing_limit=1024 dev.em.1.rx_processing_limit=1024 net.isr.direct=1 net.isr.direct_force=1 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.one_pass=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 dev.em.0.rx_kthreads=4 dev.em.1.rx_kthreads=4 Если надо ещё что-нить показать, выложу! Помогите разобраться с нагрузкой!
  21. Это не то что надо :)Спасибо за наведение на путь истинный! Поправил:
  22. ТОЧНО!!! заменил!Проверяю, но пока никаких Limiting icmp unreach response from 513 to 500 packets/sec нет ! На данный момент ядро поправлено: завтра начну пересборку!
  23. Температура процессора в норме ? собираю инфу coretemp'ом, и в кактус - всё в норме!
  24. спасибо, все вернул на Родину :)количество пользователей увеличил убрал. ночью пересоберу! спасибо. заменил, это осталось ещё от тех времён, когда работал только pf вместе со своим altqи количество таблентрисов урезал. не помню, нафиг я так делал! PF вообще занимается исключительно НАТом, больше в нем НИЧЕГО нет, т.к. когда-то заметил, что если закрыть им ssh снаружи, то в момент брутов сервер вешается. ipfw это дело закрывает стабильнее. попробую! Поясните, я недавно перешел на ipfw, не совсем понял.Преследовалось, чтоб написать один пайп с маской /32 , сделать таблицу и зарезать все адреса таблицы этим пайпом в обе стороны. Видимо, синтаксис неверен, объясните! Можно пример корректного написания?! Вот кусок ipfw pipe 65 show: 00065: 131.072 Kbit/s 0 ms burst 0 q131137 12 sl. 0 flows (1 buckets) sched 65601 weight 0 lmax 0 pri 0 GRED w_q 0.001999 min_th 3 max_th 6 max_p 0.099991 sched 65601 type FIFO flags 0x1 1024 buckets 92 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 2 ip 0.0.0.0/0 78.31.244.61/0 3 144 0 0 0 9 ip 0.0.0.0/0 93.186.231.124/0 1 40 0 0 0 16 ip 0.0.0.0/0 172.16.16.48/0 39 28794 0 0 0 19 ip 0.0.0.0/0 92.124.12.235/0 1 48 0 0 0 22 ip 0.0.0.0/0 212.77.140.141/0 2 82 0 0 0 25 ip 0.0.0.0/0 80.249.93.235/0 1 49 0 0 0 34 ip 0.0.0.0/0 178.66.56.166/0 43 2149 0 0 0 34 ip 0.0.0.0/0 86.19.124.4/0 5 707 0 0 0 64 ip 0.0.0.0/0 93.84.218.233/0 2 174 0 0 0 77 ip 0.0.0.0/0 93.186.235.56/0 98 4124 0 0 0 84 ip 0.0.0.0/0 82.46.16.8/0 3 137 0 0 0 86 ip 0.0.0.0/0 178.66.124.210/0 4 196 0 0 0 92 ip 0.0.0.0/0 109.168.223.13/0 3 144 0 0 0 98 ip 0.0.0.0/0 78.36.104.42/0 2 96 0 0 0 101 ip 0.0.0.0/0 78.61.232.30/0 1 48 0 0 0 103 ip 0.0.0.0/0 172.16.16.71/0 57129 52422452 7 4547 12361 нет, но хочу поставить на отдельный винт Win с SiSoftware Sandra и погонять на стресс-тестах!Если есть варианты как на BSD это налету сделать, буду рад советам! Тоже была мысль. Пока резервного нет. Зато поменял и блок разеток, и даже кабель...
  25. # === 2 Mbit ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700 ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700 на out xmit где там у вас абоненты это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.* у меня vlan700 смотрит какраз на абонентов.