vadius Опубликовано 13 апреля, 2011 · Жалоба Запарились уже. Спасайте. В связи с увеличением канала (интернет,город) в январе был установлен новый сервер на граничный маршрутизатор с FreeBSD 8.1 (AMD64), потом обновлен до 8.2-Release (AMD64). Железо такое: Мать Intel S5520UR, два CPU Xeon E5620, памяти 8 Гб две двухголовые (em) HP NC360T PCIe DP Gigabit Server Adapter (n1e5132) две встроенные (igb) 82575EB Gigabit Network Connection На нем крутится bgp, ospf, dummynet, ssh, ipfw, dns. NATа - нет. Firewall 90 правил, включая 22 pipe для шейпера. Входящий трафик в пике: Интернет около 300Мбит(~50К пакетов), город 600-700Мбит (~90К пакетов). Город и интернет на разных каналах. Исходящий раза в полтора поменьше. Ошибок на интерфейсах нет. Шейпер висит на входящем из интернета. Проблема в следующем: Раз в неделю получаем kernel panic fatal trap 12 (current process = 12 (irq258:igb0:que 2) или (current process = 0 (em2 taskq)) и завис, пару раз была перезагрузка. Самое интересное, часто падает днем в то время когда нагрузка ниже средней. Пробовали драйвера от яндекса один черт. Убираешь тюнинг падает дня через 2-3. Из тюнинга: sysctl.conf kern.ipc.nmbclusters=524288 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=0 net.inet.tcp.drop_synfin=1 net.inet.tcp.syncookies=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=65536 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=1000 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.pipe_slot_limit=2048 net.inet.ip.fastforwarding=1 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.ip.intr_queue_maxlen=1000 kern.ipc.shm_use_phys=1 net.isr.direct=1 net.isr.direct_force=1 net.link.ether.inet.log_arp_movements=0 dev.igb.0.flow_control=0 dev.igb.1.flow_control=0 dev.em.X.rx_int_delay=1000 dev.em.X.tx_int_delay=1000 dev.em.X.rx_abs_int_delay=2000 dev.em.X.tx_abs_int_delay=2000 dev.em.X.rx_processing_limit=2000 dev.em.X.flow_control=0 loader.conf net.isr.maxthreads=4 Из ядра все лишнее выброшено. Flowtable, polling отключен. Вот top днем, когда нагрузка невысокая. В пике загрузки сервера CPU idle ~85% top -SH last pid: 39098; load averages: 0.44, 0.61, 0.56 up 0+23:34:55 15:01:39 163 processes: 9 running, 122 sleeping, 32 waiting CPU: 0.0% user, 0.0% nice, 5.9% system, 1.1% interrupt, 93.0% idle Mem: 370M Active, 510M Inact, 700M Wired, 272K Cache, 822M Buf, 6245M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU6 6 23.5H 100.00% {idle: cpu6} 11 root 171 ki31 0K 128K CPU5 5 23.4H 100.00% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 4 23.4H 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU3 3 23.2H 100.00% {idle: cpu3} 11 root 171 ki31 0K 128K CPU1 1 23.1H 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU7 7 23.5H 99.66% {idle: cpu7} 11 root 171 ki31 0K 128K CPU2 2 17.6H 75.59% {idle: cpu2} 11 root 171 ki31 0K 128K CPU0 0 16.8H 71.88% {idle: cpu0} 0 root -68 0 0K 336K - 2 153:07 15.48% {em0 taskq} 0 root -68 0 0K 336K - 2 166:42 14.89% {em1 taskq} 0 root -68 0 0K 336K - 0 94:47 10.79% {em2 taskq} 0 root -68 0 0K 336K - 2 133:54 9.38% {em3 taskq} 12 root -68 - 0K 512K WAIT 1 18:30 3.56% {irq257: igb0:que} 0 root -68 0 0K 336K - 0 155:54 2.59% {dummynet} 0 root -68 0 0K 336K - 2 26:09 1.95% {igb0 que} 12 root -68 - 0K 512K WAIT 0 16:22 0.59% {irq256: igb0:que} 12 root -68 - 0K 512K WAIT 3 15:21 0.39% {irq259: igb0:que} 12 root -68 - 0K 512K WAIT 2 15:52 0.10% {irq258: igb0:que} 2173 root 44 0 144M 137M select 1 10:35 0.00% bgpd 12 root -32 - 0K 512K WAIT 4 6:54 0.00% {swi4: clock} 0 root 44 0 0K 336K sched 0 3:02 0.00% {swapper} 13 root -16 - 0K 16K - 4 2:28 0.00% yarrow 12 root -68 - 0K 512K WAIT 0 1:23 0.00% {irq261: igb1:que} 12 root -68 - 0K 512K WAIT 1 1:05 0.00% {irq262: igb1:que} 12 root -68 - 0K 512K WAIT 3 0:59 0.00% {irq264: igb1:que} 2196 root 44 0 24896K 6420K select 1 0:59 0.00% snmpd 12 root -68 - 0K 512K WAIT 2 0:54 0.00% {irq263: igb1:que} 0 root -68 0 0K 336K - 0 0:39 0.00% {igb1 que} Если нужна какая информация пишите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 13 апреля, 2011 (изменено) · Жалоба покажите правила фаерволла. net.inet.ip.fastforwarding=1 выключить? почти оффтоп, просто заметка: loader.conf net.isr.maxthreads=4 разве есть смысл при net.isr.direct=1 и kern.ipc.nmbclusters=524288 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.shm_use_phys=1 вернуть в базовые значения Изменено 13 апреля, 2011 пользователем Giga-Byte Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 13 апреля, 2011 (изменено) · Жалоба net.inet.ip.fastforwarding=1 был отключен до недавнего времени, сейчас включили для тестирования. Сервер умирает и так и так :( net.isr.maxthreads=4 с net.isr.direct=1 смысла конечно нет, я оставил для того чтобы пробовать с net.isr.direct=0, но тогда загрузка проца растет и один черт виснет. kern.ipc.nmbclusters=524288kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.shm_use_phys=1 т.е убрать их из rc.conf? 00011 pipe 1 ip from any to 111.222.80.0/21 in via eth1 00011 pipe 2 ip from 111.222.80.0/21 to any out via eth1 00012 pipe 3 ip from any to 111.222.88.0/22 in via eth1 00012 pipe 4 ip from 111.222.88.0/22 to any out via eth1 00012 pipe 3 ip from any to 111.222.92.0/24 in via eth1 00012 pipe 4 ip from 111.222.92.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.93.0/24 in via eth1 00013 pipe 6 ip from 111.222.93.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.94.0/23 in via eth1 00013 pipe 6 ip from 111.222.94.0/23 to any out via eth1 00014 pipe 7 ip from any to 111.333.16.0/24 in via eth1 00014 pipe 8 ip from 111.333.16.0/24 to any out via eth1 00021 pipe 9 ip from any to 111.333.23.0/27 in via eth1 00021 pipe 10 ip from 111.333.23.0/27 to any out via eth1 00022 pipe 11 ip from any to 111.333.23.32/27 in via eth1 00022 pipe 12 ip from 111.333.23.32/27 to any out via eth1 00023 pipe 13 ip from any to 111.333.23.64/27 in via eth1 00023 pipe 14 ip from 111.333.23.64/27 to any out via eth1 00024 pipe 15 ip from any to 111.333.23.96/27 in via eth1 00024 pipe 16 ip from 111.333.23.96/27 to any out via eth1 00031 pipe 13 ip from any to 111.333.23.192/27 in via eth1 00031 pipe 14 ip from 111.333.23.192/27 to any out via eth1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01300 deny ip from any to 172.16.0.0/12 via eth1 01400 deny ip from 172.16.0.0/12 to any via eth1 01500 deny ip from any to 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 01600 deny ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any 01700 skipto 10000 ip from any to 111.333.23.192/27 01800 fwd 192.168.251.12 ip from any to any out recv eth1 xmit eth3 01900 fwd 192.168.252.12 ip from any to any out recv eth1 xmit eth2 10000 allow icmp from any to any 10100 allow tcp from any to any established 10200 allow ip from any to any frag 10300 allow ip from 172.10.0.0/20,172.10.128.0/22 to any { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 } 10400 allow ip from any to 172.10.0.0/20,172.10.128.0/22 { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 } 10500 allow ip from any to 111.222.80.0/20,111.333.16.0/21 10600 allow ip from 111.222.80.0/20,111.333.16.0/21 to any ... далее идут правила доступа к локальным сервисам и серверам внутри сети ... 65535 deny ip from any to any eth0 - входящий город поделен на вланы eth1 - входящий интернет eth2,eth3 - исходящий к Nas-ам eth4,eth5 - исходящий еще к 2 сетям 11-31 - пайпы шейпера, скорости доступа поделили по подсетям 1800,1900 - заворачиваем интернет трафик в вланы к Nas-ам, для дальнейшего обсчета в биллинге. 10300,10400 серые адреса по городу Изменено 13 апреля, 2011 пользователем vadius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 13 апреля, 2011 · Жалоба Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет) зы "emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 13 апреля, 2011 · Жалоба kern.ipc.nmbclusters=524288kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.shm_use_phys=1 т.е убрать их из rc.conf? угу 00011 pipe 1 ip from any to 111.222.80.0/21 in via eth1 00011 pipe 2 ip from 111.222.80.0/21 to any out via eth1 00012 pipe 3 ip from any to 111.222.88.0/22 in via eth1 00012 pipe 4 ip from 111.222.88.0/22 to any out via eth1 00012 pipe 3 ip from any to 111.222.92.0/24 in via eth1 00012 pipe 4 ip from 111.222.92.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.93.0/24 in via eth1 00013 pipe 6 ip from 111.222.93.0/24 to any out via eth1 00013 pipe 5 ip from any to 111.222.94.0/23 in via eth1 00013 pipe 6 ip from 111.222.94.0/23 to any out via eth1 00014 pipe 7 ip from any to 111.333.16.0/24 in via eth1 00014 pipe 8 ip from 111.333.16.0/24 to any out via eth1 00021 pipe 9 ip from any to 111.333.23.0/27 in via eth1 00021 pipe 10 ip from 111.333.23.0/27 to any out via eth1 00022 pipe 11 ip from any to 111.333.23.32/27 in via eth1 00022 pipe 12 ip from 111.333.23.32/27 to any out via eth1 00023 pipe 13 ip from any to 111.333.23.64/27 in via eth1 00023 pipe 14 ip from 111.333.23.64/27 to any out via eth1 00024 pipe 15 ip from any to 111.333.23.96/27 in via eth1 00024 pipe 16 ip from 111.333.23.96/27 to any out via eth1 00031 pipe 13 ip from any to 111.333.23.192/27 in via eth1 00031 pipe 14 ip from 111.333.23.192/27 to any out via eth1 попробуйте не использовать in via eth1, используйте out via ethX на какой интерфейс там ваши сети уходят 111.х.у.z соответственно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 13 апреля, 2011 · Жалоба Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет) сильно долбить туда тоже не стоит, а то начнут игнорировать :) зы "emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы... не обязательно, это уже к другой теме, про производительность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 13 апреля, 2011 · Жалоба не обязательно, это уже к другой теме, про производительность. одно другому не мешает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 13 апреля, 2011 · Жалоба Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет) вот с коркой проблема, никак ее нет "emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы... Сейчас прибито: cpuset -l 0,2 -p 0 в top-е видно попробуйте не использовать in via eth1, используйте out via ethX на какой интерфейс там ваши сети уходят 111.х.у.z соответственно. это вот можно попробовать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 13 апреля, 2011 · Жалоба вот с коркой проблема, никак ее нет т.е. всякие # Build kernel with gdb(1) debug symbols makeoptions DEBUG=-g # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # (in a nutshell, reboot if there's a panic) options KDB_UNATTENDED не помогают и все равно висит ? Сейчас прибито: cpuset -l 0,2 -p 0 в top-е видно Я бы таки размазал по ядрам, уж коли их есть. приэтом 0,2 оно все равно болтается то там, то там. ну да ладно, скорее всего к висам/трапам оно таки отношения не имеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 13 апреля, 2011 · Жалоба в ядре: makeoptions DEBUG=-g options KDB options KDB_TRACE а вот options KDB_UNATTENDED нет Я бы таки размазал по ядрам, уж коли их есть. приэтом 0,2 оно все равно болтается то там, то там. ну да ладно, скорее всего к висам/трапам оно таки отношения не имеет. пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90% меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 13 апреля, 2011 · Жалоба пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90% меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так это решается заменой в pipe правилах in via... на out via... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 13 апреля, 2011 · Жалоба это решается заменой в pipe правилах in via... на out via... Giga-Byte спасибо за совет, срочным образом меняю на out :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 13 апреля, 2011 · Жалоба /bin/ps -p 0 -axcH -o lwp,command | egrep 'dummynet' | while read lwp cmd; do /usr/bin/cpuset -l Х -t $lwp; done приколотит думминет (а не весь кернел) к конкретному процессору X. У меня в таком виде оно не грузит процессоры ни на in ни на out... (ну аут конечно правильнее.) а вот options KDB_UNATTENDED нет У утверждается что должно помочь получить ребут и соотв дамп.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 13 апреля, 2011 · Жалоба /bin/ps -p 0 -axcH -o lwp,command | egrep 'dummynet' | while read lwp cmd; do /usr/bin/cpuset -l Х -t $lwp; doneприколотит думминет (а не весь кернел) к конкретному процессору X. У меня в таком виде оно не грузит процессоры ни на in ни на out... (ну аут конечно правильнее.) st_re благодарю за помощь, а то я что-то не смог найти как отдельный процесс прибить к нужному ядру (видимо плохо искал :) ), буду экспериментировать. options KDB_UNATTENDED попробую поставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 14 апреля, 2011 · Жалоба Фигня какая то, на разных ядрах загрузка dummynet кардинально отличается. Прибиваю dummynet к 0 ядру: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU1 1 41:16 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU3 3 41:14 100.00% {idle: cpu3} 11 root 171 ki31 0K 128K CPU4 4 40:57 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU2 2 38:04 100.00% {idle: cpu2} 11 root 171 ki31 0K 128K CPU0 0 37:31 100.00% {idle: cpu0} 11 root 171 ki31 0K 128K CPU7 7 40:37 98.19% {idle: cpu7} 11 root 171 ki31 0K 128K CPU6 6 41:07 96.39% {idle: cpu6} 11 root 171 ki31 0K 128K RUN 5 40:20 91.46% {idle: cpu5} 0 root -68 0 0K 336K - 7 2:06 8.69% {em3 taskq} 0 root -68 0 0K 336K - 5 3:13 7.76% {em1 taskq} 0 root -68 0 0K 336K - 6 1:00 5.86% {em2 taskq} 0 root -68 0 0K 336K - 4 0:51 4.05% {em0 taskq} 12 root -68 - 0K 512K WAIT 0 0:08 0.20% {irq256: igb0:que} 0 root 44 0 0K 336K sched 2 3:02 0.00% {swapper} 0 root -68 0 0K 336K - 0 1:47 0.00% {dummynet} к 1 ядру: 0 root -68 0 0K 336K - 1 1:50 0.00% {dummynet} ко 2: 0 root -68 0 0K 336K - 2 1:55 0.00% {dummynet} к 3: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU1 1 44:34 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K CPU4 4 44:12 100.00% {idle: cpu4} 11 root 171 ki31 0K 128K CPU7 7 43:46 100.00% {idle: cpu7} 11 root 171 ki31 0K 128K CPU2 2 41:24 100.00% {idle: cpu2} 0 root -68 0 0K 336K - 3 2:00 100.00% {dummynet} 11 root 171 ki31 0K 128K RUN 5 43:24 99.66% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 0 40:50 98.97% {idle: cpu0} 11 root 171 ki31 0K 128K CPU6 6 44:22 96.09% {idle: cpu6} к 4 ядру: 0 root -68 0 0K 336K - 4 2:07 96.29% {dummynet} к 5: 0 root -68 0 0K 336K - 5 2:11 0.00% {dummynet} к 6: 0 root -68 0 0K 336K - 6 2:12 0.00% {dummynet} к 7: 0 root -68 0 0K 336K - 7 2:15 0.00% {dummynet} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 14 апреля, 2011 · Жалоба kern.ipc.nmbclusters=524288 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.shm_use_phys=1 вернуть в базовые значения что то я сомневаюсь на счет базового значения kern.ipc.nmbclusters, оно равно 25600. я сохранял netstat -m, когда у меня было kern.ipc.nmbclusters=262144 26540/10074/36614/262144 mbuf clusters in use (current/cache/total/max) получается не хватит mbuf кластеров? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 14 апреля, 2011 · Жалоба kern.ipc.nmbclusters=524288 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.shm_use_phys=1 вернуть в базовые значения что то я сомневаюсь на счет базового значения kern.ipc.nmbclusters, оно равно 25600. я сохранял netstat -m, когда у меня было kern.ipc.nmbclusters=262144 26540/10074/36614/262144 mbuf clusters in use (current/cache/total/max) получается не хватит mbuf кластеров? согласен, поставьте тогда в 61000 либо kern.maxusers=512 >> /boot/loader.conf в конфиге ядра кстати какое значение? с повышеным maxusers можно (а может нужно) попробовать увеличить vm.kmem_size, vm.kmem_size_max к 1G (если памяти 2Гб и больше) а также vm.kmem_size_scale=2 на счет прибить дамминет к ядрам - ИМХО надо тогда и потоки обработки "прерываний" (em taskq) прибивать к той же группе ядер, у которых кэш L3 один. некоторые говорили отключать HT (hyper threading), чтобы не путались ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 14 апреля, 2011 · Жалоба в ядре все по умолчанию, вот sysctl-ы kern.maxuser: 384 vm.kmem_size_scale: 1 vm.kmem_size: 8206544896 vm.kmem_size_max: 329853485875 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 14 апреля, 2011 · Жалоба в ядре все по умолчанию, вот sysctl-ы kern.maxuser: 384 vm.kmem_size_scale: 1 vm.kmem_size: 8206544896 vm.kmem_size_max: 329853485875 ай, вру, тогда не трогайте, там с amd64 куча варнингов и ахтунгов было на счет изменения этих значений. у меня то на роутерах i386, аптаймы уже годами. тогда просто maxusers до 512 и смотрите как увеличится nmbclusters (можно на другой машине), либо поставьте nmbclusters в 61000, думаю никуда больше не упрётся с таким значением (нежели с 262144) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 14 апреля, 2011 · Жалоба да уже думал что надо было ставить i386 на роутер. nmbclusters поставил в 61000 буду смотреть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 14 апреля, 2011 · Жалоба А что там такое на 3-4 ядрах ? что это вообще ? egrep '^[[:space:]]*cpu' /var/run/dmesg.boot ? не HT часом ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 апреля, 2011 · Жалоба флоу кеш из ядра удалить нафик - пересобрать ядро без него. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 14 апреля, 2011 (изменено) · Жалоба А что там такое на 3-4 ядрах ? не знаю, я ничего к ним не привязывал HT отключен. egrep '^[[:space:]]*cpu' /var/run/dmesg.boot cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 20 cpu4 (AP): APIC ID: 32 cpu5 (AP): APIC ID: 34 cpu6 (AP): APIC ID: 50 cpu7 (AP): APIC ID: 52 cpu0: <ACPI CPU> on acpi0 cpu1: <ACPI CPU> on acpi0 cpu2: <ACPI CPU> on acpi0 cpu3: <ACPI CPU> on acpi0 cpu4: <ACPI CPU> on acpi0 cpu5: <ACPI CPU> on acpi0 cpu6: <ACPI CPU> on acpi0 cpu7: <ACPI CPU> on acpi0 флоу кеш из ядра удалить нафик - пересобрать ядро без него. flowtable из ядра убран был сразу, с ним сетевая подсистема вставала колом буквально через 1-2 минуты после поднятия сервера. Изменено 14 апреля, 2011 пользователем vadius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 14 апреля, 2011 · Жалоба Проблема в следующем: Раз в неделю получаем kernel panic fatal trap 12 (current process = 12 (irq258:igb0:que 2) или (current process = 0 (em2 taskq)) и завис, пару раз была перезагрузка. Самое интересное, часто падает днем в то время когда нагрузка ниже средней. Проблема известная. Обновляйтесь до 8.2-STABLE, там это на днях исправили. И держите net.isr.direct=1 и net.isr.direct_force=1 (по дефолту, то есть), другие значения тоже провоцируют паники, а с этими всё стабильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 апреля, 2011 · Жалоба пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90% меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так Потому что 4 ядра получились у интела объединением двух двух ядреных процессоров в один корпус, но с общим L3 кешем, соотвественно когда у вас сетевухи на одной паре ядрес с общим кешем, а диминет на другой то вы получаете пинальти и процессор стоит и синхронизирует кеши L2 через L3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...