l1ght
-
Всього повідомлень
2 712 -
Приєднався
-
Останній візит
-
Дней в лидерах
18
Тип контенту
Профили
Форум
Календарь
Сообщения додав l1ght
-
-
там тоже нас + билинг в одной коробке блингу все равно где работать как настроите OnConnect что он будет вносить в фаирвол зависит от вас .
http://wiki.ubilling.net.ua/doku.php?id=setupubuntuserver1204
Да я как раз это и прочитал. Ну я так линукс не очень люблю....
Но когда такой выбор стоит - тут уж придётся
-
Тут нас + биллинг в одной коробке
Насколько я помню линуха поддержка была и гарантированя работа исключительно как биллинга.
Качаю убунту.. буду тестить.
-
И почему сразу выкинуть железо? Ну живёт оно себе нормально, не перенагружается
hw.model: Intel® Pentium® CPU G860 @ 3.00GHz
Ты хоть сам понимаешь, какая пропасть поколений между Pentium 4 и Pentium G sandy bridge?Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).
Значит не железо виновато, рекомендация стандартна - сносите BSD, ставьте linux.
Да я вот думаю в сторону accel-ppp с ipoe, только вот у меня стоит Ubilling, такой он теплый и родной
Не хочется никуда переходит, да и с фрей мне как-то проще, если не считать этого момента с падением в кору.
По поводу проца - ну я просто перепутал, поэтому и вылажил строчку hw.model, дабы вопросы о железе отпали.
-
А я думал я один такой дурак
)Меня кстати net.isr спасал в такие моменты. Когда он был выключен - его включение спасло сервер от падения в кору, он конечно был нагружен очень, но нормально себя чувствовал.
Кстати кто ещё подскажет - не хотят грузится параметры из loader.conf после недавнего мажорного обновления с 9.0 до 9.2.
Лично у меня спам на определенный порт отменяется, т.к. 6881 порт у меня ничем не слушается и включен blackhole.
Да и вообще, сокстат никакого криминала не показывает
Я правило с каунтом добавил - но думаю счётчик вообще дергатся не будет.
И почему сразу выкинуть железо? Ну живёт оно себе нормально, не перенагружается
hw.model: Intel® Pentium® CPU G860 @ 3.00GHz
Завернуть траф на соседний порт свича просто не могу, т.к. аплинк зашёл прямо в машину.
-
А кхм, если вы про это http://habrahabr.ru/post/168607/ - сначала внешняя сетевая была 82574L, а потом, всё переехало на двух портовую серверную.
И была ровно та же жопа...
-
Вот как.... Чтож тогда всё стало понятно, значит будем думать про замену!
Очень благодарен.
Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет
)Так что жду ещё идей
Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке
не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?
Да у меня вообще sip трафик незамечен, и ничего у меня вроде его не использует.
Если не ошибаюсь SIP - для айпи телефонии?
-
Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.
Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.
выкидывате эти, ставьте с чипом не менее 82576.
На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к.
Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике
PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц.
ну и посмотрите что именно проц нагружает
pmcstat -S instructions -O /tmp/sample.out &
sleep 30 && killall pmcstat
pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25
Спасибо за подсказку, буду смотреть. Не знаю, как у вас при 18кппс загибалось, у меня всё шуршит аж бегом
Только вот у моей проблемы нет никакой систематики, по крайней мере не было.
Может профайлинг чего покажет...
Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке
-
Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.
Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.
-
День добрый, имеется:
9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER i386
Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).
Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же).
Но vmstat -i в норме.Вот примерно следующее видно:
last pid: 22409; load averages: 0.52, 0.50, 0.30 128 processes: 3 running, 109 sleeping, 16 waiting CPU: 0.0% user, 0.0% nice, 5.5% system, 27.2% interrupt, 67.3% idle Mem: 108M Active, 80M Inact, 129M Wired, 132K Cache, 73M Buf, 1543M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 16K RUN 0 7:38 88.28% idle{idle: cpu0} 12 root -72 - 0K 128K CPU1 1 2:46 50.05% intr{swi1: netisr 1} 11 root 155 ki31 0K 16K RUN 1 5:21 47.36% idle{idle: cpu1} 12 root -72 - 0K 128K WAIT 0 0:24 6.01% intr{swi1: netisr 0} 0 root -92 0 0K 96K - 0 0:11 2.54% kernel{em1 taskq} 0 root -92 0 0K 96K - 1 0:15 0.63% kernel{em0 taskq}interrupt total rate irq16: xhci0 ehci0 891 1 irq19: atapci0+ 4995 8 irq23: ehci1 893 1 cpu0:timer 1216146 2122 irq256: em0 2221212 3876 irq257: em1 1758013 3068 irq258: hdac0 41 0 cpu1:timer 1187698 2072 Total 6389889 11151
Ну это моменты когда нагрузка растёт и машина с ней справляется.
А бывают моменты когда машина просто в кору падает и всё. Поэтому данных что происходит тогда привести не могу.
Но то что я на скорую руку смотрел в принципе vmstat -i ничего криминального не показывает.
Какие будут идеи?
Может чего сильно в sysctl перекрутил?
kern.ipc.nmbclusters=60000 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=204800 net.inet.udp.maxdgram=57344 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.randomized=0 net.inet.tcp.nolocaltimewait=1 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.icmp.bmcastecho=0 net.inet.ip.ttl=64 net.inet.tcp.drop_synfin=1 net.inet.tcp.syncookies=1 net.inet.ip.dummynet.expire=1 net.inet.ip.fw.dyn_buckets=2048 net.inet.tcp.maxtcptw=40960 kern.ipc.maxsockbuf=16777216 net.inet.tcp.recvspace=262144 net.inet.ip.intr_queue_maxlen=8192 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.pipe_slot_limit=1000 kern.maxfilesperproc=200000 kern.ipc.shmmax=67108864 net.inet.tcp.rfc3390=0 net.inet.ip.fw.autoinc_step=1 net.inet.tcp.blackhole=2 net.inet.icmp.maskrepl=1 net.inet.udp.blackhole=1 net.link.ether.inet.max_age=30 net.inet.tcp.sendspace=262144 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.ip.random_id=1 net.inet.ip.rtexpire=60 net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 net.inet.icmp.drop_redirect=1 net.inet.ip.redirect=0 kern.maxfiles=204800 net.inet.tcp.delayed_ack=0 dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.1.rx_int_delay=200 dev.em.1.tx_int_delay=200 dev.em.2.rx_int_delay=200 dev.em.2.tx_int_delay=200 dev.em.3.rx_int_delay=200 dev.em.3.tx_int_delay=200 net.graph.recvspace=8388608 net.graph.maxdgram=8388608 net.inet.icmp.icmplim=200 net.inet.udp.recvspace=262144 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.point_to_point=0 net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_max=65535 kern.ipc.shmall=128000000 net.inet.tcp.msl=15000 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.1.rx_abs_int_delay=4000 dev.em.1.tx_abs_int_delay=4000 dev.em.2.rx_abs_int_delay=4000 dev.em.2.tx_abs_int_delay=4000 dev.em.3.rx_abs_int_delay=4000 dev.em.3.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 dev.em.1.rx_processing_limit=4096 dev.em.2.rx_processing_limit=4096 dev.em.3.rx_processing_limit=4096 net.route.netisr_maxqlen=4096 net.inet.ip.intr_queue_maxlen=10240 net.isr.dispatch=deferred net.link.bridge.pfil_onlyip=0 net.link.bridge.pfil_member=1 net.link.bridge.pfil_bridge=0 net.link.bridge.pfil_local_phys=0 net.link.bridge.ipfw=0 net.link.bridge.ipfw_arp=0 net.inet.tcp.mssdflt=1460 net.inet.tcp.syncache.rexmtlimit=0 net.inet.tcp.icmp_may_rst=0 vfs.read_max=128 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 vfs.ufs.dirhash_maxmem=16777216 net.raw.recvspace=65534 net.raw.sendspace=65534 net.inet.raw.maxdgram=65534 net.inet.raw.recvspace=65534 kern.ipc.shm_use_phys=1
Да и в sockstat никакого криминала нет... Уже извёлся незнаю чего и думать
-
Приведу просто аналогию, вы можете взять жигуль, за дешево и он будет ездить, а можете взять мерс за дорого и он тоже будет ездить, но вот вопрос. как он будет ездить, как часто он будет ломаться и насколько комфортно вам будет.
П.С. Это все уже обсуждалось 100 раз в другой теме по ТурбоПону, зачем еще раз разводить тоже самое?
Еще раз. Никто ничего против елтекса не имеет, это раз. Во вторых вы про мерседес могли бы рассказать год или два назад. А сейчас, когда у меня все отлично работает на бдкоме, какой нах@р мерседес и жигули? Может быть Мерседес и БМВ? Тогда, кто тут кто? И вообще дело не в этом =) Лично я не буду покупать у россиян, это мое лично мнение и я никого не переубеждаю. Куплю бдком, хуавей, суньхуйвчай, эриксон, еще что то. Такие дела.
Порадовал ваш ответ
Да надо прекращать флудить в теме где предоставляют оборудование на тесты!
-
Нет, не предлогайте бюджетные решения!
А то и дальше будут набегать и кричать, что построена говносеть на тупых мыльницах
Ну а по поводу микрота - 950 микрот держит порядка 80 машин (нат, шейп, дхцп, фильтрация в фаерволе).
Пиковую нагрузку, что он видел - 40 мегабит и загрузка проца примерно 60%.
Запаса ещё с головой, но микроты они такие, лучше их не перенагружать, а то у них bad block-и вылетают.
Ну а лично мне больше нравится решение на тазике, там много не надо, сойдет любая машина с линем или бздей.
Манов в интернете полно, так что при желании всё настраивается, а и в последствии работает замечательно.
-
Не будем обсуждать определенных вендоров, просто сравним Gepon и Turbo Gepon.
Gepon VS Turbo Gepon
Downlink: 1.25G 2.5G
Uplink: 1.25G 1.25G
Дело не конкретно в мультикасте, а в том что нисходящая скорость в 2 раза выше.
Так как аплоад задействуется в 99% не больше чем на половину от даунлоада - это позволить не уперется в пропускную способность в ЧНН.
У меня вообще статистика что аплоада задействуется в 5-10 раз меньше от даунлоада.
А если посчитать что, если 1 дерево состоит из 128 абонентов: и существует тариф 100 мегабит - то 10 качальщиков не положат всю пропускную способность на 2-5 минут.
Или я в чём-то не прав?
-
+++++Ничего против Eltex , но лучше куплю у китайцев чем у россиян =)
Ну что могу сказать, если сугубо из таких убеждений...
Только вот тот же BDCOM -> GEPON, a Eltex -> Turbo GEPON. Разницу думаю объяснять не надо.
-
Да 750-ки там с головой хватит
И натить, шейпить, ещё и проксик держать запаса хватить должно
-
Как думаете 750 микротик подойдет ?
750-го и на больше хватить может, если не требовать от него чего-то сверх))
-
Не хочу трогать политику, но ...
Политика - политикой, а работа - работой!
Мне вот скоро в руки тоже елтекс попадет. Жду не дождусь, поработать с хваленым елтексом.
И блин при чём тут политика когда человек оборудование на тесты предлагает?
-
отключите порты , которые горят из консоли. Если не попустит, до блоками поотключайте пока не найдете лежаших. И все заработает
Спасибо - то что нужно. Свич заработал
-
Спасибо, буду пытатся
-
О как, тогда всё понятно
Спасибо за инфу!
-
Нет конечно, путаете технологии.
Ну насколько я понимаю 82 опция это собственно agent circuit id и agent remote id.
Agent circuit id - с какого порта.
Agent remote id - айди самого свича.
Если я правильно понял вы намекаете что каким-то волшебным образом номер влана может выступать как circuit id?
Если нет - поправте как правильнее будет, или расскажите, что имели в виду.
Потому что я всё таки думаю что именно на доступе нужна 82 опция.
-
Всем доброго времени суток.
Значит столкнулся я лицом к лицу с выше упомянутым коммутатором - D'Link DES 3200-26/1A.
Знакомый притащил и попросил "глянуть что с ним".
Ну у свича немного невменяемое поведение как-то. Он сброшен на дефолт как я понял.
Проблема в следующем к консоли я подключаюсь нормально и всё ок.
А вот порты (все 24 100 мегабитных) не фурычат. А 2 из них и вовсе горят всё время, хотя к ним ничего не подключено.
Втыкаю свой ноут в любой из 24 портов - 0. Никакой реакции.
В 2 гигабтных втыкаюсь - реакция идет, а толку немного. А точнее сказать и вовсе нету. Даже через них на коммутатор зайти я не могу через его стандартный айпи.
-
Если для абонентского влана указывать хулпер адрес - то тогда л3 интерфейс должен находится на свиче доступа или агрегации, правильно?
И тогда возвращаемся к тому, что уже говорил
dhcp-relay ну а самое удобное для влан пер усер это сисько на ней собирать все вланы
-
Хм, сказано было что только выше серии 3560 умеют private vlan.
Согласен, без 82 опции тяжко.
Но вот надо что-то придумать.
-
у меня много cisco 2960 8 портовых, а они private vlan не умеют допустим.
FreeBSD hi loading CPU
в Софт
Опубліковано: · Відредаговано L1ght
Ну это разве что ставить свич и зеркалить на порт, а на втором порте сидеть с ваершарком.
Да и мне ipfw по вкус, удобно просто, нет километровых конфигов.