Elisium Опубликовано 27 июня, 2012 (изменено) · Жалоба Доброго дня. Есть два самосборных сервера: Мать: AsRock X79 Extreme3 Проц: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz Сетевуха: Intel 10G X520-DA2 E10G42BTDA 82599ES dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 Память: 4 ГБ БП: 460 Ватт FSP Оба настроены АБСОЛЮТНО идентично - с первого сделан клон винчестера и поставлен на второй. Ось: FreeBSD bgp2_btm.crystal.in.ua 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Jun 26 19:57:19 EEST 2012 amd64 Сервера включены в тестовый режим работы, то есть, при отказе одного включается (в ручном режиме :( ) второй.Трафик бегает только по одному порту 10Г карты и в ЧНН допрыгивает до 2,8 ин \ 2,8 оут ГБ. Оба используются только как БГП - один основной, второй резервный. В будущем (чистом и светлом) планировалось повесить туда еще и шейпера. Но так как наша связка биллинг+шейпер заточена под Фрю, то поменять ось на сервере не вариант. Проблема в следующем: в произвольные моменты времени (от 10 минут до суток) активный сервер зависает. Причем зависает так, что не реагирует на клавиатуру. Перегрузить можно только нажатием на Ресет. В этот момент на экране нет никаких сообщений об ошибках - просто висит надпись Логин. Дампы не делаются, хотя включены. Судя по встроеному мониторингу температуры, перегрева нет, температура до 52 градусов самого горячего ядра. Память тестировали. Зависнуть может в моменты и когда бегает 50 МБт трафа и когда 2500 МБт. На обоих серверах стоят одинаковые комплектующие. Меняли уже все запчасти, кроме материнки и проца. На драйвера от сетевой стоит патчик от 'amarao', отключающий проверку типа СФП на порту. Без него порт не поднимается и пишет "Unsupported SPF+ module", так как DA-кабель не интеловский. Iperfом между серверами пролетает 8ГБ трафика. Тестировал два часа - ни один не завис. Изначально на серверах стояла Фря 9.0 СТАБЛЕ. Так на ней сервера висли уже в течении пары часов после запуска в работу. Еще интересное наблюдение: Точно такой же сервер (третий) стоит под систему виртуализации. У него аптайм уже больше месяца, таких проблем нет. Но и трафика там больше 10-20 МБт не пробегает и используется бортовая карта Broadcom bge. Проштудированы уже и ЖЖ 'dadv'a, и ЭТА и ЭТА и ЭТА темы, загуглено всё до дыр. Просветление так и не наступило =( На что можно обратить внимание? Что посоветуете? Какие еще конфиги\тесты приложить? Вот эта же тема на Локале Конфиги: ядро: Закомментированы все ненужные устройства, включен DEBUG=-g, ВЫКЛЮЧЕН options INET6. От себя добавлены device coretemp device cpuctl options HZ=2000 options IPFIREWALL options IPDIVERT options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=999 options DUMMYNET options NETGRAPH options NETGRAPH_SOCKET options NETGRAPH_IPFW options NETGRAPH_NETFLOW options NETGRAPH_KSOCKET options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLACK) loader.conf vm.pmap.pg_ps_enabled="1" net.inet.tcp.tcbhashsize=16384 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=512 net.graph.maxdata=4096 net.isr.defaultqlimit=4096 net.link.ifqmaxlen=1024 net.isr.maxthreads=1 net.isr.direct=0 net.isr.direct_force=0 kern.ipc.nmbclusters=262800 Если сделать kern.ipc.nmbclusters выставлено по умолчанию или меньше 65000, то при загрузке драйвер сетевой карты пишет - "Невозможно установить значение буферов, будет использовано значение по умолчанию" (както так) sysctl.conf net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.random_id=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.fast_finwait2_recycle=1 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.inet.udp.recvspace=131072 net.inet.raw.recvspace=262800 net.inet.tcp.maxtcptw=40960 net.inet.tcp.syncookies=1 net.inet.tcp.keepidle=40000 net.inet.tcp.keepintvl=40000 net.inet.tcp.keepinit=40000 net.route.netisr_maxqlen=4096 net.inet.ip.intr_queue_maxlen=4096 net.inet.icmp.icmplim=600 net.inet.ip.fw.dyn_max=16384 net.inet.ip.fw.dyn_buckets=32768 net.inet.ip.dummynet.hash_size=2048 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.expire=0 net.inet.ip.dummynet.pipe_slot_limit=1000 ###net.graph.recvspace=350000 ###net.graph.maxdgram=350000 kern.ipc.maxsockbuf=83886080 kern.ipc.somaxconn=4096 net.inet.ip.redirect=0 net.inet.ip.fastforwarding=1 dev.ix.0.fc=0 dev.ix.1.fc=0 dev.ix.0.rx_processing_limit=4000 dev.ix.1.rx_processing_limit=4000 Если kern.ipc.maxsockbuf выставлено в значение по умолчанию или меньше 1000000, то даже пинг пишет "No space buffer available" netstat -m 25085/2695/27780 mbufs in use (current/cache/total) 25083/1163/26246/262800 mbuf clusters in use (current/cache/total/max) 25083/1157 mbuf+clusters out of packet secondary zone in use (current/cache) 0/5/5/131400 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/65700 9k jumbo clusters in use (current/cache/total/max) 0/0/0/32850 16k jumbo clusters in use (current/cache/total/max) 56437K/3019K/59457K 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 netstat -Q Configuration: Setting Value Maximum Thread count 1 1 Default queue limit 4096 10240 Direct dispatch disabled n/a Forced direct dispatch disabled n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Flags ip 1 4096 flow --- igmp 2 4096 source --- rtsock 3 4096 source --- arp 7 4096 source --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 3 0 0 0 35752 35752 igmp 0 0 0 0 0 0 0 rtsock 0 2 0 0 0 34293 34293 arp 0 8 0 0 0 70179 70179 vmstat -i interrupt total rate irq16: ehci0 20863 1 irq23: ehci1 44164 3 cpu0: timer 27679535 1999 irq256: ix0:que 0 150825498 10897 irq257: ix0:que 1 149848455 10827 irq258: ix0:que 2 143558676 10372 irq259: ix0:que 3 145734821 10529 irq260: ix0:que 4 147141456 10631 irq261: ix0:que 5 148140406 10703 irq262: ix0:link 2 0 irq263: ix1:que 0 13816 0 irq264: ix1:que 1 13816 0 irq265: ix1:que 2 13816 0 irq266: ix1:que 3 13816 0 irq267: ix1:que 4 13816 0 irq268: ix1:que 5 13816 0 irq269: ix1:link 11 0 irq271: bge0 1 0 irq272: ahci1 4694 0 cpu5: timer 27679401 1999 cpu1: timer 27679136 1999 cpu3: timer 27679415 1999 cpu2: timer 27679333 1999 cpu4: timer 27679339 1999 Total 1051478102 75973 top -SHPI last pid: 2552; load averages: 0.52, 0.64, 0.58 up 0+03:51:43 12:29:30 137 processes: 8 running, 90 sleeping, 39 waiting CPU 0: % user, % nice, % system, % interrupt, % idle CPU 1: % user, % nice, % system, % interrupt, % idle CPU 2: % user, % nice, % system, % interrupt, % idle CPU 3: % user, % nice, % system, % interrupt, % idle CPU 4: % user, % nice, % system, % interrupt, % idle CPU 5: % user, % nice, % system, % interrupt, % idle Mem: 31M Active, 9960K Inact, 185M Wired, 152K Cache, 17M Buf, 3660M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 96K CPU5 5 216:47 98.73% idle{idle: cpu5} 11 root 171 ki31 0K 96K CPU4 4 216:48 98.54% idle{idle: cpu4} 11 root 171 ki31 0K 96K CPU3 3 215:10 96.34% idle{idle: cpu3} 11 root 171 ki31 0K 96K CPU2 2 212:52 94.92% idle{idle: cpu2} 11 root 171 ki31 0K 96K RUN 0 209:56 93.51% idle{idle: cpu0} 11 root 171 ki31 0K 96K RUN 1 211:01 93.41% idle{idle: cpu1} 12 root -68 - 0K 640K WAIT 0 15:30 8.01% intr{irq256: ix0:q 12 root -68 - 0K 640K WAIT 3 14:49 8.01% intr{irq259: ix0:q 12 root -68 - 0K 640K CPU1 1 15:12 7.86% intr{irq257: ix0:q 12 root -68 - 0K 640K WAIT 2 15:03 7.86% intr{irq258: ix0:q 12 root -68 - 0K 640K WAIT 5 14:30 7.71% intr{irq261: ix0:q 12 root -68 - 0K 640K WAIT 4 14:10 7.08% intr{irq260: ix0:q 0 root -68 0 0K 400K - 3 2:51 0.98% kernel{ix0 que} 0 root -68 0 0K 400K - 3 2:40 0.88% kernel{ix0 que} 0 root -68 0 0K 400K - 0 2:36 0.88% kernel{ix0 que} 0 root -68 0 0K 400K - 0 2:42 0.78% kernel{ix0 que} 0 root -68 0 0K 400K - 2 2:39 0.78% kernel{ix0 que} 0 root -68 0 0K 400K - 5 2:43 0.63% kernel{ix0 que} systat -if /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average |||| Interface Traffic Peak Total ... skip... ix0 in 215.106 MB/s 215.106 MB/s 2.152 TB out 214.945 MB/s 214.945 MB/s 2.150 TB sysctl dev.ix.0 dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000 dev.ix.0.%parent: pci3 dev.ix.0.fc: 0 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.rx_processing_limit: 4000 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 307 dev.ix.0.link_irq: 2 dev.ix.0.queue0.interrupt_rate: 11235 dev.ix.0.queue0.txd_head: 1877 dev.ix.0.queue0.txd_tail: 1877 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 522247016 dev.ix.0.queue0.rxd_head: 764 dev.ix.0.queue0.rxd_tail: 754 dev.ix.0.queue0.rx_packets: 522423035 dev.ix.0.queue0.rx_bytes: 439349665008 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 250000 dev.ix.0.queue1.txd_head: 1922 dev.ix.0.queue1.txd_tail: 1922 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 499340467 dev.ix.0.queue1.rxd_head: 908 dev.ix.0.queue1.rxd_tail: 905 dev.ix.0.queue1.rx_packets: 499393418 dev.ix.0.queue1.rx_bytes: 433420059450 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 55555 dev.ix.0.queue2.txd_head: 476 dev.ix.0.queue2.txd_tail: 479 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 502389134 dev.ix.0.queue2.rxd_head: 1992 dev.ix.0.queue2.rxd_tail: 1990 dev.ix.0.queue2.rx_packets: 502468551 dev.ix.0.queue2.rx_bytes: 447423791311 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 41666 dev.ix.0.queue3.txd_head: 341 dev.ix.0.queue3.txd_tail: 343 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 489592945 dev.ix.0.queue3.rxd_head: 241 dev.ix.0.queue3.rxd_tail: 239 dev.ix.0.queue3.rx_packets: 489627888 dev.ix.0.queue3.rx_bytes: 438060012259 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 1000000 dev.ix.0.queue4.txd_head: 952 dev.ix.0.queue4.txd_tail: 952 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 471091610 dev.ix.0.queue4.rxd_head: 1578 dev.ix.0.queue4.rxd_tail: 1577 dev.ix.0.queue4.rx_packets: 471164458 dev.ix.0.queue4.rx_bytes: 409881181720 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 55555 dev.ix.0.queue5.txd_head: 584 dev.ix.0.queue5.txd_tail: 584 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 482597087 dev.ix.0.queue5.rxd_head: 1815 dev.ix.0.queue5.rxd_tail: 1813 dev.ix.0.queue5.rx_packets: 482629398 dev.ix.0.queue5.rx_bytes: 414473310965 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 0 dev.ix.0.mac_stats.ill_errs: 0 dev.ix.0.mac_stats.byte_errs: 0 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 0 dev.ix.0.mac_stats.remote_faults: 2 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.link_xon_txd: 0 dev.ix.0.mac_stats.link_xon_rcvd: 0 dev.ix.0.mac_stats.link_xoff_txd: 0 dev.ix.0.mac_stats.link_xoff_rcvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 2606615322672 dev.ix.0.mac_stats.good_octets_rcvd: 2606325113515 dev.ix.0.mac_stats.total_pkts_rcvd: 2970506195 dev.ix.0.mac_stats.good_pkts_rcvd: 2967678482 dev.ix.0.mac_stats.mcast_pkts_rcvd: 867 dev.ix.0.mac_stats.bcast_pkts_rcvd: 122071 dev.ix.0.mac_stats.rx_frames_64: 90966031 dev.ix.0.mac_stats.rx_frames_65_127: 1041294326 dev.ix.0.mac_stats.rx_frames_128_255: 85729000 dev.ix.0.mac_stats.rx_frames_256_511: 44289698 dev.ix.0.mac_stats.rx_frames_512_1023: 66616039 dev.ix.0.mac_stats.rx_frames_1024_1522: 1638783388 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 0 dev.ix.0.mac_stats.recv_jabberd: 0 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 58309085 dev.ix.0.mac_stats.good_octets_txd: 2604466960626 dev.ix.0.mac_stats.total_pkts_txd: 2967230280 dev.ix.0.mac_stats.good_pkts_txd: 2967230280 dev.ix.0.mac_stats.bcast_pkts_txd: 7837 dev.ix.0.mac_stats.mcast_pkts_txd: 0 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 543929978 dev.ix.0.mac_stats.tx_frames_65_127: 587900462 dev.ix.0.mac_stats.tx_frames_128_255: 85715330 dev.ix.0.mac_stats.tx_frames_256_511: 44286755 dev.ix.0.mac_stats.tx_frames_512_1023: 66615662 dev.ix.0.mac_stats.tx_frames_1024_1522: 1638782093 dev.ix.0.mac_stats.fc_crc: 0 dev.ix.0.mac_stats.fc_last: 0 dev.ix.0.mac_stats.fc_drpd: 0 dev.ix.0.mac_stats.fc_pkts_rcvd: 0 dev.ix.0.mac_stats.fc_pkts_txd: 0 dev.ix.0.mac_stats.fc_dword_rcvd: 0 dev.ix.0.mac_stats.fc_dword_txd: 0 Присутствует dev.ix.0.mac_stats.checksum_errs: 58309085 Но менялась и сетевая карта, и кабели и порты на свиче: ошибки по счетчику есть, а реальных потерь пакетов - нет. vmstat -z Ошибок нет. Везде, кроме buckets, нули. Изменено 27 июня, 2012 пользователем Elisium Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 июня, 2012 · Жалоба net.inet.tcp.tcbhashsize=16384 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=512 ... net.isr.direct=0 net.isr.direct_force=0 tcp к роутингу отношения не имеет. иср.директ - в 9.0 (читаем релиз нотес) только для чтения, и настраивается оно теперь через сисцтл: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.random_id=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.fast_finwait2_recycle=1 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.inet.udp.recvspace=131072 net.inet.raw.recvspace=262800 net.inet.tcp.maxtcptw=40960 net.inet.tcp.syncookies=1 net.inet.tcp.keepidle=40000 net.inet.tcp.keepintvl=40000 Эти параметры не применяются к роутинговому трафику, только для пакетов адресованных хост системе. net.inet.ip.fastforwarding=1 Попробуйте 0 и net.isr.dispatch=deferred - должно разложить нагрузку по ядрам. device coretemp device cpuctl options HZ=2000 options IPFIREWALL options IPDIVERT options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=999 options DUMMYNET options NETGRAPH options NETGRAPH_SOCKET options NETGRAPH_IPFW options NETGRAPH_NETFLOW options NETGRAPH_KSOCKET коретемп, ипфаервол, димминет, нетграф - прекрасно грузятся модулями. см релизнотес, теперь можно их прямо из рц скрипта грузить. нетграф и так динамически грузится почти весь, по мере использования. Ошибки мак - ошибки физ уровня, ос тут не причём. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 27 июня, 2012 · Жалоба иср.директ - в 9.0 (читаем релиз нотес) только для чтения У нас стоит 8.3 и тоно меняется в сисцтл. Может, не применяется, но меняется - точно. Попробуйте 0 и net.isr.dispatch=deferred - должно разложить нагрузку по ядрам. В 8ке нет net.isr.dispatch Выключил net.inet.ip.fastforwarding - суммарная загрузка проца выросла на 15%. Включил обратно. Карта сама отлично раскладывает всё на все свободные процы. коретемп, ипфаервол, димминет, нетграф - прекрасно грузятся модулями. см релизнотес, теперь можно их прямо из рц скрипта грузить. нетграф и так динамически грузится почти весь, по мере использования. Да, спасибо, читал уже. Просто бОльшая часть конфигов - это кочевание с 6ки и аж до 9ки с некоторыми исправлениями. Вот эта же тема на Локале Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 27 июня, 2012 · Жалоба Но так как наша связка биллинг+шейпер заточена под Фрю, то поменять ось на сервере не вариант. Вариант ipfw3+dummynet под Linux не рассматривали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 июня, 2012 · Жалоба Сорри, видел 9.0 в посте, не обратил внимание что оно не используется. Карта раскладывает и может что то происходит когда пакет полностью обрабатывается в обработчике прерывания, что ставит систему колом. Прерывания обрабатываются более специфично, нежели просто ядерные потоки. Также очереди тоже многое меняют и могут как провоцировать так и убирать проблемы. 15% - при таком запасе мало что решают, попробуйте погонять с обработкой в иср потоках, вместо прерываний. Ещё есть в руснете ирк канал и мыллист разработчиков на офф сайте, в последнем точно стараются помочь товарищам с конкретными проблемами в продакшене. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 27 июня, 2012 · Жалоба Но так как наша связка биллинг+шейпер заточена под Фрю, то поменять ось на сервере не вариант. Вариант ipfw3+dummynet под Linux не рассматривали? Кстати, да. Както про это не подумал. Мысль. Спасибо за наводку. Сорри, видел 9.0 в посте, не обратил внимание что оно не используется. Карта раскладывает и может что то происходит когда пакет полностью обрабатывается в обработчике прерывания, что ставит систему колом. Прерывания обрабатываются более специфично, нежели просто ядерные потоки. Также очереди тоже многое меняют и могут как провоцировать так и убирать проблемы. 15% - при таком запасе мало что решают, попробуйте погонять с обработкой в иср потоках, вместо прерываний. Ещё есть в руснете ирк канал и мыллист разработчиков на офф сайте, в последнем точно стараются помочь товарищам с конкретными проблемами в продакшене. На текущий момент переставил винчестер с системой и карту 10Г на полностью другое железо - сервер HP DL160. Пока полет нормальный. Жду, как пройдет ночь и завтрашний день. п.с. Больше ответов я оставил в теме на Локале. Там просто чаще отвечают =(. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 29 июня, 2012 · Жалоба 15% - при таком запасе мало что решают, попробуйте погонять с обработкой в иср потоках, вместо прерываний. Не надо такое советовать, лучше не будет. Тем более что в случае dummynet indirect isr там и так вылезет. Вообще говоря, ситуация довольно странная. На вид оно в принципе должно молотить как минимум несколько гигабит без проблем (если, конечно, там не совсем все плохо с файрволллом). У нас достаточно большое количество коробок с десяточными интелями на 8-S, в целом по больнице симптомов зависания насмерть при хоршем железе - нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 29 июня, 2012 · Жалоба На другом железе (другая мать и проц) - полет нормальный, все ок. Летит 3/3 ГБт трафа. Пока поставил на второй сервер интеловскую мать вместо асрока. Пару дней пусть побегает, посмотрим, как интел делает мамки =) Сегодня так же товарищи сообщили, что тоже наблюдают проблемы на асроковских мамках и 10Г картах. Правда, не так глобально как у меня. Там то карту не видно, то трафик не бегает =(. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 30 июня, 2012 · Жалоба Я бы ещё (на всякий случай) попробовал options SCHED_4BSD Из моего опыта два основных программных источников полной блокировки системы: шторм прерываний и ошибки в планировщике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 1 июля, 2012 · Жалоба FLOWTABLE заккоментировано? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 1 июля, 2012 (изменено) · Жалоба Но так как наша связка биллинг+шейпер заточена под Фрю, то поменять ось на сервере не вариант. Только ИМХО, практический опыт, _без анализа_ выкладок от ТС.. Т.е. только "моё_личное_мнение", НЕ утверждение, просто ИМХО... Итак... Биллинг и шейпер - только на FreeBSD, роутинг и NAT(если нужен) - только на Linux (у меня - CentOS-5). И... Железо - только Intel.. Ну или "богатые железные решения" от Cisco (НЕ юзал тоже :-)).. Моё (до 1Г) работает.. Если не трогать и не "грозить" (штормы в сегментх сети при грозах) - не беспокоит. Ну и ещё одно "НО" - 10Г ещё не юзал. Не исключаю, что там другой "расклад". Т.е. ещё раз - ИМХО... Изменено 1 июля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 1 июля, 2012 · Жалоба Биллинг и шейпер - только на FreeBSD Без намерения спровоцировать очерендой флейм - поясните, чем биллингу лучше на Фре? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 1 июля, 2012 · Жалоба FLOWTABLE заккоментировано? Так оно вроде как с 8.2 уже пропало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 1 июля, 2012 (изменено) · Жалоба FLOWTABLE заккоментировано? Так оно вроде как с 8.2 уже пропало. Апд темы: На Интеловской мамке работает вот уже третий день без дополнительных плясок с бубном и без проблем. Имхо, вывод: или у Интела мамки лучше плюс настройки биоса както "побезопаснее" или АсРок все-таки "кот в мешке" - необходимо немалое прыгание по горячим углям, что бы оно более-менее нормально заработало. На текущий момент решение вопроса - замена материнки на Интел. С асроковскими еще немного пободаюсь попозже. Изменено 1 июля, 2012 пользователем Elisium Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 1 июля, 2012 (изменено) · Жалоба Биллинг и шейпер - только на FreeBSD Без намерения спровоцировать очерендой флейм - поясните, чем биллингу лучше на Фре? В том-то и дело, что разложить по полочкам не смогу, это только практический опыт и как следствие, только личное мнение, не более того.. Начинал (в 2005-м) с биллинга+шейпер на Linux - было трудно.. Перетащил и то и другое на FreeBSD (mpd+radius) - вполне можно сказать, что настроил и забыл. А вот роутинг и фильтрацию (фаервол) реализовать получилось без проблем именно на Linux iptables (ipfw и pf тоже были в ряду "претендентов", но "не прошли"..). Т.е., так сказать - "без комментариев" и _возможно_ из серии - "что Я умею готовить".. :) Ну и еще вот это готов подтвердить Имхо, вывод: или у Интела мамки лучше плюс настройки биоса както "побезопаснее" или АсРок все-таки "кот в мешке" - необходимо немалое прыгание по горячим углям, что бы оно более-менее нормально заработало. На текущий момент решение вопроса - замена материнки на Интел. также, "без комментариев".. :) Хотя, нет.. Всё же не удержусь, малость прокомментирую. Тоже ИМХО - похоже, что любой *nix/BSD (по моему скромному мнению) изначально заточен под Intel и соотв. веселее пляшет именно на этом железе.. P.S. Может и ошибаюсь.. Изменено 1 июля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 1 июля, 2012 · Жалоба или АсРок все-таки "кот в мешке" А чего хотеть от "экспериментального" подразделения Asus, которое всегда славилось своей любовью к извращениям (типа CPU upgrade слотов, редких гибридов включая 2-сокетные платы под процы разных поколений, ессно - с поддержкой одновременно только одного проца, и т.п. редкими извращениями) и экстремально низкой ценой? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 3 июля, 2012 · Жалоба Резюме: На интеловской мамке работает как часы. Асроковскую уже и трогать не хочется - нервы мучать себе дороже будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 3 июля, 2012 · Жалоба Резюме: На интеловской мамке работает как часы. Асроковскую уже и трогать не хочется - нервы мучать себе дороже будет. Теперь посчитайте планировавшуюся экономию и фактические убытки от решения выбрать самосборное барахло вместо бренда. А чего хотеть от "экспериментального" подразделения Asus В "экспертах", способных задним числом всё "объяснить" подобным образом, недостатка обычно не бывает. "А чего хотеть от цисковских индусов", "а чего хотеть от наколенного линукса", "а чего хотеть от ...", ну и т.д. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 3 июля, 2012 · Жалоба На интеловской мамке работает как часы. Асроковскую уже и трогать не хочется - нервы мучать себе дороже будет. Можно поподробнее про модель матери и какой камень стоит? Какая нагрузка в итоге и что крутится на этом железе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 4 июля, 2012 · Жалоба Было: Мать: AsRock X79 Extreme3 Проц: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz Стало: Мать: Intel DX79TO Проц: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz На сейчас используется как БГП (все еще проверяю работу БЕЗ шейперов\итд). Загрузка 12%, трафик 2,9Г\2,9Г up\down (симметричный) в пике. PPS > 1M. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 4 июля, 2012 · Жалоба В "экспертах", способных задним числом всё "объяснить" подобным образом, недостатка обычно не бывает. "А чего хотеть от цисковских индусов", "а чего хотеть от наколенного линукса", "а чего хотеть от ...", ну и т.д. :) Если человек ставит железо от производителя, выпускающего в основной массе дешевый ширпотреб переменной глюкавости - то чего удивляться-то тому, что оно может не работать как надо? Я к примеру давно вычеркнул асрок из списка кандидатов на покупку даже в десктоп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 7 июля, 2012 · Жалоба И снова доброго дня. В продолжение этой же темы: Наблюдаю странный глюк: Собраны два сервера. Из ОТЛИЧАЮЩИХСЯ комплектующих в серверах - винт, видео и марка памяти. На винчестерах ось клонирована с одного на другой. Через сервер номер 1 бегает в 1,5 раза больше трафика (1600\1600 против 1100\1100), чем через сервер 2. Но ЗАГРУЗКА проца выше в ТРИ раза ...23% и 7% соответственно. БИОС на обоих одинаковых версий, настройки - тоже. Сетевуха и видео вставлены в точно такие же слоты, что и в другом сервере. Даже лог загрузки одинаков ..=( Характер трафика должен быть не сильно отличающийся - сеть просто поделена на два больших куска. Каждый проходит через свой сервер. Топ с более загруженного сервера: last pid: 2200; load averages: 1.30, 1.32, 1.25 up 0+01:08:54 23:33:12 124 processes: 8 running, 86 sleeping, 30 waiting CPU 0: 0.0% user, 0.0% nice, 5.3% system, 13.5% interrupt, 81.2% idle CPU 1: 0.0% user, 0.0% nice, 4.5% system, 17.7% interrupt, 77.8% idle CPU 2: 0.0% user, 0.0% nice, 3.7% system, 15.0% interrupt, 81.3% idle CPU 3: 0.0% user, 0.0% nice, 3.4% system, 15.0% interrupt, 81.6% idle CPU 4: 0.0% user, 0.0% nice, 0.4% system, 15.0% interrupt, 84.6% idle CPU 5: 0.0% user, 0.0% nice, 0.4% system, 10.5% interrupt, 89.1% idle Mem: 37M Active, 13M Inact, 180M Wired, 304K Cache, 23M Buf, 3637M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 96K CPU4 4 56:30 92.72% idle{idle: cpu4} 11 root 171 ki31 0K 96K CPU5 5 56:40 91.80% idle{idle: cpu5} 11 root 171 ki31 0K 96K CPU3 3 56:27 90.38% idle{idle: cpu3} 11 root 171 ki31 0K 96K RUN 2 54:55 85.84% idle{idle: cpu2} 11 root 171 ki31 0K 96K RUN 0 52:13 84.18% idle{idle: cpu0} 11 root 171 ki31 0K 96K CPU1 1 53:27 83.69% idle{idle: cpu1} 12 root -68 - 0K 496K CPU1 1 11:23 17.24% intr{irq257: ix0:que } 12 root -68 - 0K 496K WAIT 2 10:40 15.62% intr{irq258: ix0:que } 12 root -68 - 0K 496K WAIT 0 11:58 14.89% intr{irq256: ix0:que } 12 root -68 - 0K 496K WAIT 3 10:31 14.21% intr{irq259: ix0:que } 12 root -68 - 0K 496K WAIT 5 11:44 13.92% intr{irq261: ix0:que } 12 root -68 - 0K 496K WAIT 4 11:29 12.94% intr{irq260: ix0:que } 0 root -68 0 0K 416K - 4 2:11 2.93% kernel{ix0 que} 0 root -68 0 0K 416K - 0 2:21 2.88% kernel{ix0 que} 0 root -68 0 0K 416K - 0 2:21 2.73% kernel{ix0 que} 0 root -68 0 0K 416K - 3 2:12 2.73% kernel{ix0 que} 0 root -68 0 0K 416K - 1 2:15 2.44% kernel{ix0 que} 0 root -68 0 0K 416K - 2 1:56 2.39% kernel{ix0 que} 1840 root 44 0 31380K 9736K select 0 0:43 0.24% snmpd Проверил все, что мог. Если и есть разница в выдаваемых различными утилитами результатах, то на уровне 10% Сижу, смотрю на все это и молча удивляюсь. Есть ли у более опытных товарисчей идеи, в чем подвох ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 8 июля, 2012 (изменено) · Жалоба Сравните статус энергосберегающих функций. Сравните количество прерываний. Загруженность в большей степени зависит от количества пакетов (PPS), а не от трафика. Изменено 8 июля, 2012 пользователем bel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 8 июля, 2012 · Жалоба Сравните статус энергосберегающих функций. Сравните количество прерываний. Загруженность в большей степени зависит от количества пакетов (PPS), а не от трафика. 1. Версии биосов и настройки в них - одинаковые 2. На первом сервере их на 20% больше 3. На ВТОРОМ сервере ППС БОЛЬШЕ примерно на 60-100К Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 8 июля, 2012 · Жалоба 2. На первом сервере их на 20% больше 3. На ВТОРОМ сервере ППС БОЛЬШЕ примерно на 60-100К Параметры сетевых карт точно одинаковые? В первую очередь, размеры очередей и порог для throttling'a (если он поддерживается). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...