vadius Опубликовано 8 октября, 2009 (изменено) · Жалоба Напишу небольшой отчет может кому и поможет, а то я в свое время потратил кучу времени и нервов, как своих, так и клиентов. Выкладываю так, для информации. Что имеем: Сервер m/b S5000VSA, 8Gb Ram, 2 x Xeon E5420, 2 встроенные Intel PRO/1000 EB. Входящий канал 1Gbit/s, по нему идет интернет + городские ресурсы, так что нагрузка не хилая. Количество онлайн клиентов pptp 800-900. История: Пока по входящему каналу шёл только интернет со скоростью около 50Мбит/с, pptp сервер прекрасно работал и на poptop под FreeBSD 6.3 AMD64. Но когда подключили городские ресурсы на весь гигабит, машина стала медленно умирать, все 8 процов были загружены на 100%. Решили переходить на mpd. Сделал тюнинг системы и поставил mpd версии 5.3. Отлично, загрузка процов нравится. Idle их 75-80%. Радуемся не долго, часа через 2 сервер уходит в ребут. Почитал на форумах, оказалось я не одинок, проблема известная. Куча разных советов как с этим бороться, в основном говорят о проблеме из-за шейперов на dummynet, хреновых интеловских сетевых дровах, кривом netgraph-е и железе и т.п. Что не делал, один черт, то сервер ребутнется, то зависнет насмерть. Попробовал версии mpd 5.2, 5.1 проблема та же. Может проработать 2 часа, а может и 8. Прочитал что с 4 версией проблем меньше. Ставлю mpd 4.4.1, и быть не может, наконец то система работает 1 день без перезагрузки. Но... рано радоваться через некоторое время опять зависает. Перегружаем, работаем еще день и т.д. Выношу радиус сервер и шейпер(dummynet) на другой сервер, этот пытаюсь максимально разгрузить, остается только mpd, ipcad. Ставлю драйвера на сетевухи от yandex, кручу тюнинг системы. Один черт, НЕ помогает. Рано утром иду обновлять систему до 7.2 Amd64 релиз, ставлю mpd 5.3, сетевые драйвера 6.9.12 от интела и довольный иду спать, в надежде что в 7 версии было много изменений в сетевой подсистеме, и это должно помочь. Поспал... но не долго, через 3 часа ребут. В логах ничего интересного, одно только заметил, что перезагрузка произошла ровно в 10:30:00. И здесь появляется мысль: у меня по крону раз в 15 минут, скриптом идет обновление arp таблицы, и у тех клиентов кто ушел в минус маки забиваются нулями. Ну что делать, и этот скрипт выношу на другой сервер... И ВОТ ОНО ЧУДО!!! сервер работает, без перегрузов и зависонов день, два, три... Пытаюсь разобраться, что происходило: Клиент подключен к впн серверу и баланс уходит в минус, а радиус еще не успел его отключить от впн сервера. В это время проходит отработка скрипта по замене маков клиентов с минусовым балансом, и у netgrph-а похоже сносит от этого голову, а он соответственно тянет за собой всю систему. Ну это чисто мои предположения... Главное получили Vpn сервер на mpd5.3 под FreeBSD 7.2 AMD64 который работает стабильно. Idle процессоров в пиковое время 75-90%. То что надо... Выкладываю свои конфиги, которые получились после многократных тюнингов (сразу оговорюсь что они не претендуют на идеальность) /boot/loader.conf: if_em_load="YES" vm.kmem_size=1G vm.kmem_size_max=1G kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 kern.ipc.nsfbufs=10240 hw.em.rxd=1024 hw.em.txd=1024 net.graph.maxalloc=2048 kern.ipc.maxpipekva=200000000 /etc/sysctl.conf: kern.ipc.shmall=65536 kern.ipc.shmmax=268435456 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.nmbclusters=262144 kern.ipc.somaxconn=4096 kern.ipc.maxsockets=204800 kern.ipc.semmap=512 kern.maxfiles=204800 kern.maxfilesperproc=200000 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.randomized=0 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=65536 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=30000 net.inet.tcp.syncookies=1 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.fast_finwait2_recycle=1 kern.ipc.shm_use_phys=1 net.inet.icmp.icmplim=1000 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.fastforwarding=1 net.graph.maxdgram=128000 net.graph.recvspace=128000 net.isr.direct=1 Конфиг kernel: за основу взят GENERIC, выкинуты все ненужные дрова, и добавлено: options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options NETGRAPH Mpd.conf: startup: set user admin mypass admin set console self 192.168.1.1 5055 set console open default: load pptp_standart pptp_standart: create bundle template B set iface disable proxy-arp set iface idle 0 set iface enable tcpmssfix set ipcp no vjcomp set ipcp ranges 10.0.0.1/32 0.0.0.0/0 set ipcp dns 192.168.1.1 set bundle disable compression set bundle disable encryption set ccp no mppc set mppc no e40 set mppc no e128 set mppc no stateless create link template L pptp set link action bundle B set link disable multilink set link no acfcomp protocomp set link no pap chap set link enable chap-msv2 set link keep-alive 30 90 set link mtu 1460 set link enable incoming set link enable peer-as-calling set pptp self 192.168.1.1 load radius radius: set radius config /usr/local/etc/mpd5/radius.conf set radius server 192.168.1.2 mysecurity 1812 1813 set radius retries 3 set radius timeout 20 set radius me 192.168.1.1 set auth acct-update 300 set auth enable radius-auth set auth enable radius-acct set auth disable internal Изменено 8 октября, 2009 пользователем vadius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bsdelnik Опубликовано 8 октября, 2009 · Жалоба А зачем забивать нулями маки? Из того же скрипта легко можно и интерфейс через админку mpd прибить, что гораздо надежнее будет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadius Опубликовано 8 октября, 2009 · Жалоба на самом деле это сделано чтоб банить клиентов в сетке с отрицательным балансом, ведь кроме инета есть и другие ресурсы, а управляемых свитчей увы пока немного ... а корректным отсоединением клиентов от инета занимается радиус сервер через соответствующий скрипт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 8 октября, 2009 · Жалоба не пробовали чем нибудь другим забивать? по-моему все нули не лучшая заглушка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 8 октября, 2009 · Жалоба в ipguard'е, к примеру, de:ad:9a:c3:20:7f Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 8 октября, 2009 · Жалоба на самом деле это сделано чтоб банить клиентов в сетке с отрицательным балансом, ведь кроме инета есть и другие ресурсы, а управляемых свитчей увы пока немного ... а корректным отсоединением клиентов от инета занимается радиус сервер через соответствующий скрипт. В итоге обслуживанием ARP-сегмента займётся держатель ресурса в пределах своего топологического сегмента. Будьте уверены, он найдет способ ответить на arp-lookup раньше Вашего маршрутизатора, а там базу паролей уже несложно будет собрать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 8 октября, 2009 · Жалоба 1. Поставьте ipguard из портов. 2. Почитайте на него доку и создайте настройки (база связок IP-MAC). 3. Перепишите свой скрипт, чтобы он в базе ipguard нужному IP менял MAC например на 22:22:22:22:22:22 - это автоматом вызовет блокировку IP в сети. 4. Забудьте о своих проблемах и спите спокойно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 8 октября, 2009 · Жалоба Тех же, кто решит обслуживать ARP-сегмент самостоятельно - отстреливайте из 300-миллиметровых орудий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IvanI Опубликовано 9 октября, 2009 (изменено) · Жалоба Обьясните пожалуста на что реально влияют переменные kern.ipc.semmni="256" kern.ipc.semmns="512" kern.ipc.semmnu="256" kern.ipc.semmap="256" kern.ipc.shmmax="134217728" kern.ipc.nsfbufs=10240 net.graph.maxalloc=2048 shared_buffers = 16MB max_fsm_pages = 179200 Изменено 9 октября, 2009 пользователем IvanI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 февраля, 2010 (изменено) · Жалоба kern.ipc.nsfbufs: Maximum number of sendfile(2) sf_bufs available те для впн оно вообще не нужно, а х64 и для сендфайла не нужно. net.graph.maxalloc: Maximum number of non-data queue items to allocate kern.ipc.nmbclusters=262144kern.ipc.somaxconn=4096 kern.ipc.maxsockets=204800 kern.ipc.semmap=512 kern.maxfiles=204800 kern.maxfilesperproc=200000 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.randomized=0 это и ещё кое что было в рекомендациях Сысоева для веб серверов на nginx kern.ipc.nmbclusters=262144 это как то много. всякие про шаредмем взяты со статей про тюнинг под БД на веб сервере Изменено 24 февраля, 2010 пользователем Ivan_83 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 25 февраля, 2010 · Жалоба Для mpd4 у меня туннели прибивались так: ifconfig ng123 down ifconfig ng123 delete Чем такой вариант хуже игр с MAC-адресами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...