iValera Опубликовано 22 декабря, 2008 (изменено) · Жалоба Есть сервер 3logic MicroStar (MSI) P1-105A2, i7230+ICH7R (Mulciteo2), S775 Intel Q6600 LGA775 CORE QUAD 2.4 2x4M 1066 BOX 512MB DDR2-533 PC2-4200 две Seagate 80Gb SATA-2 А точнее два. Почти идентичны по железу, но ПО стоит одинаковое: Задача - сервера доступа. Freebsd 7.0-STABLE-200807, mpd 5.1.1, ipfw (на таблицах), netgraph, ng_nat, utm5_rfw, dynashape Прокачка 1го сервера 30Мбит/с, примерно 450 pptp одновременных туннелей. Прокачка 2го сервера 30Мбит,с 300pptp туннелей. Т.к. сейчас утро, top с загрузкой выложить не могу, пока только так (250 pptp tun online) last pid: 96252; load averages: 0.07, 0.08, 0.04 up 19+15:16:48 10:51:57 58 processes: 2 running, 44 sleeping, 12 waiting CPU: 0.0% user, 0.0% nice, 37.8% system, 26.6% interrupt, 35.5% idle Mem: 58M Active, 249M Inact, 174M Wired, 68K Cache, 112M Buf, 1520M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 ki31 0K 8K RUN 162.9H 65.33% idle 21 root 1 -68 - 0K 8K - 122.1H 14.65% em1 taskq 12 root 1 -44 - 0K 8K WAIT 112.8H 11.96% swi1: net 24 root 1 -68 - 0K 8K WAIT 641:42 1.32% irq10: em0 atap 27 root 1 -68 - 0K 8K - 41.5H 0.00% dummynet 20 root 1 -68 - 0K 8K - 788:38 0.00% em0 taskq 13 root 1 -32 - 0K 8K WAIT 111:04 0.00% swi4: clock В пик idle 0,0% em1 taskq и swi1: net делят загрузку между собой пополам, la подскакивает до двух, новых pptp пользователей начинает отбрасывать (ошибка 800), шелл лагает. Как видно SMP отключен, с его работой - фря может работать без перебоев как один день, так и неделю - а потом виснет или уходит в ребут. Пробовали и SMP, SMP+polling, с HTT - безуспешно, действительно ли SMP ещё сыроват? Второй сервер с нагрузкой послабее - всё тоже самое - ребуты и зависание, причём могут быть как в 10 утра (когда нагрузки никакой, а могут быть и в вечером). Ставили 6.x - тоже самое. Сейчас от безысходности работаем на одном ядре, нагрузка постепенно растёт, трафик + туннели. не знаем как дальше тянуть. cat /etc/sysctl.conf net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 net.link.ether.inet.proxyall=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.somaxconn=512 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.expire=1 net.inet.ip.dummynet.max_chain_len=32 net.inet.ip.dummynet.io_fast=1 # em driver tuning dev.em.0.rx_processing_limit=200 dev.em.1.rx_processing_limit=200 Куда копнуть? Спасибо. Изменено 22 декабря, 2008 пользователем iValera Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 22 декабря, 2008 · Жалоба Откатиться на mpd 4.4.x Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 22 декабря, 2008 · Жалоба А нам так нравился netflow из коробки =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 23 декабря, 2008 · Жалоба в 4.4.х тоже есть нетфлоу из коробки Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 23 декабря, 2008 · Жалоба Низнал. mikevlz, спасибо. Но мы для начала попробуем 5.2 (сейчас стоит 5.1). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 23 декабря, 2008 · Жалоба Стоит 3 впн-а с немного разным железом, все с SMP mpd 5.2. Один тоже постоянно в ребут уходил. Помогло обновление до 7.1-PRERELEASE и выкидывание всего лишнего/никритичного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 25 декабря, 2008 · Жалоба Решили проблему с резким всплесокм lavg при высоком к-ве ng-интерфейсов. Ядро не выделяло больше 60 мегов на процесс (mpd5). Решили путем введения следующих параметров ядра: options MAXDSIZ=(2048UL*1024*1024) options MAXSSIZ=(728UL*1024*1024) options DFLDSIZ=(1024UL*1024*1024) Но и не смотря на это, существует еще одна большая проблема. Сервак виснет произвольно в любой момент времени не важно при какой нагрузке. При этом остается возможность удаленного доступа (ssh). top -S кажет в поле STATE для swi1: net *in_mu, а для dummynet *if_ad. Согласно man, STATE, это событие, на котором происходит ожидание процесса. Как правило, это WAIT (в штатном режиме функционирования нашего сервера доступа). По вышеуказанным статусам я ничего не нагуглил. Есть подозрение, что "не вытягивает" dummynet. В ipfw всего 2889 правил, из них 2850 - пайпы. Сейчас у пользователей приобладают высокоскоростные безлимитные тарифы и мы не исключаем, что причиной сбоя является зараженный клиент. В ближайшее время постараемся перевести dummynet на таблицы, либо вобще уйти от ipfw в пользу pf, а шейпинг будет реализован через ng_car. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 декабря, 2008 · Жалоба Правильно сконфигуреный pf все-равно жрет больше проца, чем ipfw с dummynet в stateless mode при примерно одинаковых конфигурациях. То есть - если не нужно делать pf nat + altq, то лучше обойтись dummynet с табличками и ветвлением через skipto. Если же в ipfw делается навороченный stateful, то имеет смысл смотреть на pf. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 25 декабря, 2008 · Жалоба Ув. jab, благодарю за ответ. Таблицы успешно удалось внедрить в механизм контроля доступа, с pipe пытался - не вышло. Буду пробовать снова. Вместе с этим посмотрим в сторону использования skipto. Еще в догонку (пока везут новое железо для экспериментов). Ставить 7.0, или можно смело релиз-кандидейт лить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 декабря, 2008 · Жалоба Ув. jab, благодарю за ответ. Таблицы успешно удалось внедрить в механизм контроля доступа, с pipe пытался - не вышло. Буду пробовать снова. Вместе с этим посмотрим в сторону использования skipto. А чего там внедрять-то ? И здесь и на opennet'е десять раз обсасывалось. Хоть с tablearg, хоть без него. skipto используется для того, чтобы минимизировать количество правил, сквозь которые проходит каждый пакет. Чем длиннее цепочка, тем больше нагрузка на CPU, и после некоторого количества правил ( скажем более 1000 ) нагрузка растет экспоненциально. В результате при попытке прогнать 10kpps сквозь последнее правило - тачка встает намертво. Особенно если там allow from any to any. Еще в догонку (пока везут новое железо для экспериментов). Ставить 7.0, или можно смело релиз-кандидейт лить? Ну я бы не ставил, у меня по-моему моложе 7.0-RELEASE-p4 ничего нету... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 29 декабря, 2008 · Жалоба С наступающим! Что было сделано: 1) Перевели шейпирование на таблицы (вот такая конструкция): pipe 40961 config bw 4096Kbit/s mask src-ip 0xffffffff pipe 40962 config bw 4096Kbit/s mask dst-ip 0xffffffff 100 pipe tablearg ip from table\(2\) to any in recv ng* 200 pipe tablearg ip from any to table\(22\) out xmit ng* 2) Полностью отказались от stateful режима. Сейчас есть сервера работающие в старом режиме (statefull - пускай и частичный). Там к-во динамических правил примерно равно к-ву абонентов онлайн помноженного на 1.5. Т.е. сейчас на наиболее загруженном насе 534 динамических правила. 3) Почистили сами правила, оставили самое необходимое. Сократили к-во правил с 2955 до 30. Помогло как введение таблиц, так и выкидывание ненужных строчек. 4) С целью исключения двойного прохождения пакетов по одному правилу постарались максимально подробно указать направление прохождение пакета (in, out / recv, xmit). Чего не делали: 1) Для skipto применения не нашлось. Решили, что с 30-ю правилами и так будет нормально. 2) Читаем про тюнинг sysctl-ов для более производительной работы dummynet О результатах тестирования отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Blackmore Опубликовано 30 декабря, 2008 · Жалоба Ставить 7.0, или можно смело релиз-кандидейт лить? релиз кандидат ставить - в чистой 7,0 есть проблемы, которые уже пофиксили, с mpd5.2 на релизе кандидате проблем пока нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 30 декабря, 2008 · Жалоба Я кстати, когда качал rc1 почему-то при переходе на ftp-сцылу обнаружил RC2. А в новостяъ про это ничего нет. В роадмапе у них помоему 7.1 уже вот-вот. Её-то и поставим при первой же возможности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 3 января, 2009 · Жалоба Всех СНГ!!! Вобщем, пока все гуд. Накапливаем аптайм на "временной" машине с двумя интерфейсами rtl8139 =) last pid: 86725; load averages: 0.01, 0.01, 0.00 up 5+06:31:52 20:45:48 62 processes: 2 running, 44 sleeping, 16 waiting CPU: 0.8% user, 0.0% nice, 4.3% system, 21.9% interrupt, 73.0% idle Mem: 16M Active, 204M Inact, 144M Wired, 92K Cache, 112M Buf, 1625M Free Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 ki31 0K 8K RUN 107.7H 84.28% idle 22 root 1 -68 - 0K 8K WAIT 596:11 13.87% irq10: rl0 rl1 12 root 1 -44 - 0K 8K WAIT 288:13 4.59% swi1: net 30 root 1 -68 - 0K 8K - 146:42 0.00% dummynet 13 root 1 -32 - 0K 8K WAIT 33:09 0.00% swi4: clock sio 15 root 1 44 - 0K 8K - 15:06 0.00% yarrow 719 root 1 44 0 8824K 5168K select 7:01 0.00% snmpd 36 root 1 20 - 0K 8K syncer 4:20 0.00% syncer Дамминет судим по показателю TIME. После всяческих оптимизаций этот показатель упал по сравнению с остальными процессами. <kan5300@nas4>netstat -s -p ip ip: 2424834596 total packets received 43 bad header checksums 0 with size smaller than minimum 5 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 1432783 fragments received 0 fragments dropped (dup or out of space) 4851 fragments dropped after timeout 712790 packets reassembled ok 699142507 packets for this host 2875 packets for unknown/unsupported protocol 1438769544 packets forwarded (0 packets fast forwarded) 130636 packets not forwardable 433661 packets received for unknown multicast group 0 redirects sent 888643261 packets sent from this host 0 packets sent with fabricated ip header 452 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 83994 output datagrams fragmented 168186 fragments created 14517 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 4 января, 2009 · Жалоба vpn2# netstat -s -p ip ip: 1706042421 total packets received 100704 bad header checksums 0 with size smaller than minimum 45 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 2102676878 packets for this host 4821130 packets for unknown/unsupported protocol 367003331 packets forwarded (631763883 packets fast forwarded) 14493113 packets not forwardable 5366937 packets received for unknown multicast group 0 redirects sent 976081913 packets sent from this host 1892783 packets sent with fabricated ip header 65925 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 424738 output datagrams fragmented 898993 fragments created 116612 datagrams that can't be fragmented 0 tunneling packets that can't find gif 2273 datagrams with bad address in header last pid: 88707; load averages: 0.17, 0.10, 0.03 up 43+05:09:51 17:43:04 79 processes: 3 running, 57 sleeping, 19 waiting CPU states: 1.0% user, 0.0% nice, 1.4% system, 1.0% interrupt, 96.5% idle Mem: 43M Active, 11M Inact, 85M Wired, 836K Cache, 55M Buf, 1857M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 root 1 171 52 0K 8K CPU1 1 1031.0 98.93% idle: cpu1 11 root 1 171 52 0K 8K RUN 0 871.2H 96.53% idle: cpu0 62360 root 2 96 0 52088K 28936K select 1 107:01 0.10% mpd5 14 root 1 -44 -163 0K 8K WAIT 0 122.2H 0.05% swi1: net 541 root 1 96 0 5988K 3588K select 1 55:31 0.05% zebra 42 root 1 -68 0 0K 8K - 0 21.5H 0.00% dummynet 12 root 1 -32 -151 0K 8K WAIT 0 779:24 0.00% swi4: clock sio vpn2# uname -a FreeBSD vpn2.******* 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #0: Mon Nov 3 14:21:59 MSK 2008 admin@***********:/usr/obj/nanobsd.full/usr/src/sys/router i386 Вот как-то так... mpd5.2 если интересно. Камень - что-то из C2D Е8*00. Интелевская серверная мама на 3210SHLX. Сетевухи встроенные. В пиках 500 человек на тазик, pptp с шифрованием. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 8 января, 2009 · Жалоба Откатиться на mpd 4.4.x Вот как раз 4.4.1 стоит. Пробовали 7.1, 7.1 RC2, 6.4 везде виснет два раза в сутки. Причем рядом стоят еще два сервера с аналогичными конфигами и работают без проблем. Решение найдено? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 9 января, 2009 · Жалоба Вот как раз 4.4.1 стоит. Пробовали 7.1, 7.1 RC2, 6.4 везде виснет два раза в сутки. Причем рядом стоят еще два сервера с аналогичными конфигами и работают без проблем. Решение найдено? Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 12 января, 2009 · Жалоба Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются. jab, Вы ECC память ставите? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 12 января, 2009 · Жалоба а смысл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 12 января, 2009 · Жалоба ECC ИМХО для СУБД имеет смысл ставить. На роутер смысла нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 12 января, 2009 · Жалоба jab, Вы ECC память ставите? Нет. У меня стоимость двойной ошибки мизерная. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 12 января, 2009 · Жалоба Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются. Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 12 января, 2009 · Жалоба Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :) Ну если Вы считаете что "с SMP" и "без SMP" - это идентичные конфиги, то мне тут добавить нечего. Тут в консерватории что-то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 12 января, 2009 · Жалоба Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :) Ну если Вы считаете что "с SMP" и "без SMP" - это идентичные конфиги, то мне тут добавить нечего. Тут в консерватории что-то. Это разные сборки из одних и тех-же исходников :) Много чего разного и в библиотеках, но мне от того, что где-то присутствует неявный глюк(dummynet,netgraph, само ядро) как-то не очень хорошо... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 12 января, 2009 · Жалоба Это разные сборки из одних и тех-же исходников :) Много чего разного и в библиотеках, но мне от того, что где-то присутствует неявный глюк(dummynet,netgraph, само ядро) как-то не очень хорошо... Ну так соберите кернел дебаг, выведите на консоль соседнего сервера и выясните в чем глюк. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...