LINUX.ORG.RU
ФорумAdmin

Помогите с оптимизацией и ограничением TCP/IP протокола


0

0

Когда-то я тут поднимал вопрос по поводу пропуска колва пакетов в сек через линукс машину .

Сейчас я имею АМД3000+ 256 РАМ ядро 2.4.31 + патч IMQ + p-o-m

Сетевые intel e100

Вобщим все работает супер

IMQ не юзаем , p-o-m не юзаем (чуть ниже опишу)

вдруг ни с того ни с сего имеем нехилый system нагрузон на сервак (сервак только форвардит и считает трафик)

пинг до сервака 150-300 , потери 25% Однако сервак и я на 100 мбитном канале . Вобщем ахтунг.

Значит что предпринималось :

до проблемы выше описаной были какието проблемы с icmp - аля чтото типа нехватает какогото буффера бла бла бла выполнил echo 64000 > ip_conntrack_max помогло.

однако выше описаную проблему никак не решило

Думал линукс склинил/железо склинило . Очередной раз убедился что линукс не виснет и новое железо не имеет привычки так глючить ;)

Залез в ip_conntrack , а там .....

сразу бросилось в глаза

udp 17 12 src=IPKLIENT dst=85.17.15.10 sport=4012 dport=38621 [UNREPLIED] src=85.17.15.10 dst=IPKLIENT sport=38621 dport=4012 use=1 udp 17 9 src=IPKLIENT dst=85.17.15.10 sport=4012 dport=19501 [UNREPLIED] src=85.17.15.10 dst=IPKLIENT sport=19501 dport=4012 use=1 udp 17 0 src=IPKLIENT dst=85.17.15.10 sport=4012 dport=36507 [UNREPLIED] src=85.17.15.10 dst=IPKLIENT sport=36507 dport=4012 use=1

IPKLIENT один из наших клиентов .

и от него таких строк дохренища

после ребута ип_коннтраск_мак имело 16тыщ по умолчанию а когда глянул этот ип_контрак и посчитал строки то 15 с мелочью

Увеличил ип_контрак_мак в два раза до 32000 .

Не помогло . Нагрузка всеравно 100% на АМД3000+ проц .

С выше стоящим провайдером сравнил в этот момент колво пакетов - всего было примерно 1800 пакетов всекунду входящих и примерно столько же исх общего нашего трафика . Данного клиента удалось посчитать иптеблями и вышло почти 400 пакетов исх трафика .

забыл давать - клиентам режем скорость при помощи HTB и юзаем sourse роутинг при помощи iproute2 .

Я так понимаю что все это торренты .

p-o-m не помог - или блокировать полностью - ipp2p модуль - или никак . Т.е. запустить маркировку пакетов и метить ipp2p бесполезно - он не метит пакеты между ip-TO-ip , кажеться только емулл может полноценно метиться . Вобщим протестировав тот же DC++ и прикрутив IMQ - не помогло .

попробывал connlimit в свое время - другая зассада - когда начинает резать клиента то нагрузка на проц апупенительная , 90%. Пробывал в цепочке FORWARD . И так же не достаток - только tcp трафик . Забросил эту идею заюзать pom.

Помогите , как мне быть - пока у меня зарезана народу только скорость . Но учитывая такое повоедение горе клиентов нужно в срочном порядке искать метод ограниченоя количества одновременных сессий . Как можно ограничить ЛЮБЫЕ сессие клиента ? Дабы он имел возможность одновременно гнать только скажем 50 сессий ? Не важно что это tcp или udp . И как , какую строчку нужно добавить в iptables и как оттюнинговать /proc/sys/net/ipv4 что бы в будущем не возникало таких аномалий даже не ограничивая злосчастные сессии одновременно . Так как я понял все это боком вышло на моей амдешке . А провайдерскомму рутеру на 266 пне 2 все было пофигу . Хотя он только и форвардит траф с интерфейса на интерфейс как и наш внутренний сервер .

Вот схема :

-клиенты -> внутренний гейтвей -> АМД300+ ->интернет рутер -я --------------|

Все на 100 мбитах .

Затык именно на АМД3000 был .

Вот такая проблема :(

anonymous

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

схема вот, чтото сглючило :

-клиенты -> внутренний гейтвей -> АМД300+ ->интернет рутер

-я --------------|

Все на 100 мбитах .

Затык именно на АМД3000 был .

Вот такая проблема :(

anonymous ()

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

> p-o-m не помог - или блокировать полностью - ipp2p модуль - или никак
>. Т.е. запустить маркировку пакетов и метить ipp2p бесполезно - он не
> метит пакеты между ip-TO-ip , кажеться только емулл может полноценно
> метиться . Вобщим протестировав тот же DC++
> и прикрутив IMQ - не помогло .

Можно! layer 7, сам в общаге столкнулся с этой проблемой, смотри
http://www.dzti.edu.lv/isp-serv/index.php?l=3#mark_bittorrent


A. S.




andyS1976 ()

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

> p-o-m не помог - или блокировать полностью - ipp2p модуль - или никак . Т.е. запустить маркировку пакетов и метить ipp2p бесполезно - он не метит пакеты между ip-TO-ip , кажеться только емулл может полноценно метиться . Вобщим протестировав тот же DC++ и прикрутив IMQ - не помогло .

RTFM ( hint - use CONNMARK instead of MARK)

anonymous ()

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

какая принципиальная разница между марк и коннмарк ? Ну не знает модуль ipp2p о некоторых ip to ip соеденениях .

anonymous ()

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

> какая принципиальная разница между марк и коннмарк ? Ну не знает модуль ipp2p о некоторых ip to ip соеденениях .

Connection Tracking So far we considered single packets only. From a firewalls view it's not enough to match a single p2p packet but we'll need to consider whole connections to be able to classify as much p2p traffic as possible. We have a single marked packet but what is missing at the moment is a way to assign it to a whole connection so we can handle upcoming packets in the same way like the first match. Therefore we use connection tracking and its extension connection marking. Using CONNMARK let you put a mark on every connection found in the conntrack table by command "--save-mark". Restoring this mark is very easy as well "--restore-mark". For usage have a look at example two and three in the next chapter.

anonymous ()

Re: Помогите с оптимизацией и ограничением TCP/IP протокола

да мне бы пока просто ограничить количество пакетов в сек для клиента в диапазоне 200 p/s , какие есть варианты ?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.