Alba Posted October 13, 2006 Posted October 13, 2006 что можно "покрутить" для оптимизации tcp на линуксе? стоит дуал xeon с интелёвыми серверными гигабитными картами (4 шт), из задач - роутинг и нат проблема в том, что он роутит не больше 120мбит в секунду, и, график mrtg выглядит весьма странно... Вставить ник Quote
balamutang Posted October 13, 2006 Posted October 13, 2006 может в шину какую упирается? 120 это почти 133 Вставить ник Quote
Alba Posted October 14, 2006 Author Posted October 14, 2006 может в шину какую упирается? 120 это почти 133хм... а причём?кстати, до этой машины стоял какой-то п4 с гигабитными обычными pci-картами - график был примерно такой-же... p.s. забыл сказать, что все карты pci-x Вставить ник Quote
tankistua Posted October 14, 2006 Posted October 14, 2006 а что по загрузке системы и какая ось стоит ? фаервол пробовал снимать ? Вставить ник Quote
Alba Posted October 14, 2006 Author Posted October 14, 2006 а что по загрузке системы и какая ось стоит ? фаервол пробовал снимать ?загрузка системы - копеечная :)ось - gentoo 2006.0 с ядром 2.6.17 фаервол работает только как нат (порядка 150-200 цепочек, отключить, соответственно, не смогу - машина раздаёт инет в сеть). вирусов/сканов нет - они рубятся "на подлёте" на другой железке. Вставить ник Quote
Kuzin Andrey Posted October 14, 2006 Posted October 14, 2006 150-200 цепочек это дофига !!! NetFilter просматривает все правила последовательно. Соответственно, кто последний тот тормознее... Для них все правила просчитываются. А загрузка копеечной тут быть не может, львиную долю проца жрет последовательный поиск по ip. Уменьшайте количество правил, объединяйте по каким-то общим признакам. Или вы каждое правило используете, чтобы трафик считать ?! Вставить ник Quote
Alba Posted October 15, 2006 Author Posted October 15, 2006 (edited) 150-200 цепочек это дофига !!! NetFilter просматривает все правила последовательно. Соответственно, кто последний тот тормознее... Для них все правила просчитываются. А загрузка копеечной тут быть не может, львиную долю проца жрет последовательный поиск по ip.Уменьшайте количество правил, объединяйте по каким-то общим признакам. Или вы каждое правило используете, чтобы трафик считать ?! каждое правило НАТит конкретный айпишник в интернет. как уменьшить количество цепочек - не представляю.насчёт загрузки проца: load average: 6.12, 6.61, 6.56 в машине два Intel® Xeon CPU 3.00GHz и ещё napi включен?CONFIG_E1000=yCONFIG_E1000_NAPI=y Edited October 15, 2006 by Alba Вставить ник Quote
mr.Scamp Posted October 15, 2006 Posted October 15, 2006 На графике хорошо виден профиль траффика. Имхо - файлопомойка с незашейпанным исходом. Пользовати с линком в 100 Мбит качают фильм за 5 минут, в провалах бегает просто инет или ещё что. Вставить ник Quote
tankistua Posted October 15, 2006 Posted October 15, 2006 насчёт загрузки проца: load average: 6.12, 6.61, 6.56на роутере это серьезная нагрузка вообще-то. На лицо неправильно построенная сеть. Если у вас гигабит инета, то неиметь автономную системиу это просто бред. Плюс ко всему занатить 120 мегабит - это нехилая задача всетаки. На таких линках и скоростях ни о каком нате и речи быть не мот, стандартные фаерволы тоже использовать нельзя. Такие нагрузки в режиме фильтра насколько мне известно выдерживает freebsd+pf. И то с достаочно скудными функциями по фильтрации. Вобщем - меняйте тип сети, перестраивайте ее. Вставить ник Quote
Alba Posted October 16, 2006 Author Posted October 16, 2006 (edited) насчёт загрузки проца: load average: 6.12, 6.61, 6.56на роутере это серьезная нагрузка вообще-то. На лицо неправильно построенная сеть. Если у вас гигабит инета, то неиметь автономную системиу это просто бред. Плюс ко всему занатить 120 мегабит - это нехилая задача всетаки. На таких линках и скоростях ни о каком нате и речи быть не мот, стандартные фаерволы тоже использовать нельзя. Такие нагрузки в режиме фильтра насколько мне известно выдерживает freebsd+pf. И то с достаочно скудными функциями по фильтрации. Вобщем - меняйте тип сети, перестраивайте ее. что-то совсем домыслы какие-то страшные :)чтобы была понятна структура ядра - покажу "на пальцах" НАТ-ится только то, что летит из сети (allied telesyn) в инет. остальное - роутинг. проблема между Allied Telesyn и ROU - графиг загрузки mrtg на интерфейсе ROU "сверху" Edited October 16, 2006 by Alba Вставить ник Quote
edwin Posted October 16, 2006 Posted October 16, 2006 2Alba: 1) Зачем натить отдельно каждого ? Можно ведь натитить сети ... к-во правил будет намного меньше 2) у Вас Device polling включен ? 3) проверте включено ли SMP, работает или оно 4) Хотеслось бы увидеть полный вывод top'а .... Вставить ник Quote
UglyAdmin Posted October 16, 2006 Posted October 16, 2006 А не может там быть переполнения 32-битных счётчиков? У меня такое было - стал использовать 64-битные. :) Вставить ник Quote
mr.Scamp Posted October 16, 2006 Posted October 16, 2006 (edited) Я заметил у себя нечто подобное. В cacti включил 64-битные счётчики, и... график упал до 0, данные перестали сниматся. Может, надо не редактировать существующий Data Source, а создать график заново? Edited October 16, 2006 by mr.Scamp Вставить ник Quote
GateKeeper Posted October 17, 2006 Posted October 17, 2006 (edited) а еще говорят, что под разные mediaopt надо по-разному тюнить стек... в общем, голову в руки, руки на клаву, клавой набираем opennet.ru и ищем там не такую уж и давнюю статью про тюнинг линухов и фрях под разные mediaopt. 2tankistua: А не просветите "скудность" фильтра pf? Про шейпер знаю - труб как в ipfw+DUMMYNET там нет, но назвать фильтр скудным... Edited October 17, 2006 by GateKeeper Вставить ник Quote
jab Posted October 17, 2006 Posted October 17, 2006 2tankistua: А не просветите "скудность" фильтра pf? Про шейпер знаю - труб как в ipfw+DUMMYNET там нет, но назвать фильтр скудным... Имелось ввиду, что когда надо NATить более 100Мбит - приходится все фишки у pf отрубать. Потому как при stateful behavior он жрет проц в значительно сильнее чем к примеру ipfw stateful. Ну и приходится делать выборочный scrub, optimization aggressive, limits задирать до потолка... Вставить ник Quote
Alba Posted October 17, 2006 Author Posted October 17, 2006 да, дело оказалось в 64 битных счётчиках (в mtrg добавил версию протокола 2)... причём, сначала повалились ошибки, что типа нету ifHC** в mib-ах, пришлось пересобирать snmpd с включенными mfd-wrappers - тогда стало вроде работать... но, пока аптайм маленький - увидел вчера вечером 270мегабит... посмотрю на график пару суток, да может, действительно tcp-стэк покручу - может чего поболе "выжму"... :) всем спасибо за внимание :) p.s. хотя, вот странно, iptraf показывает на порядок заниженные цифры... я понимаю, конечно, что там другой совсем принцип, но, всё-же... Вставить ник Quote
GateKeeper Posted October 17, 2006 Posted October 17, 2006 (edited) Имелось ввиду, что когда надо NATить более 100Мбит - приходится все фишки у pf отрубать. Да нет... Фраза была именно о фильтре (rules), а не о NAT (nat) pf-a. Вот в этой части хотелось бы поподробнее... Edited October 17, 2006 by GateKeeper Вставить ник Quote
mr.Scamp Posted October 21, 2006 Posted October 21, 2006 Alba, а можно ли поподробнее? У меня net-snmpd стоит. И cacti в 64-битном формате данные снимать не хочет, ни по 2й, ни по 3й версси протокола. Что я не так делаю? Вставить ник Quote
tankistua Posted October 24, 2006 Posted October 24, 2006 Ну господа, я думаю многие со мной согласяться, что зароутить гигабит - это достаточно ресурсоемкая задача. Гигабит надо не роутить - а свитчевать. кошка которая может пролопатить гигабит стоит пару кило-сотен мертвых президентов, а ты хочешь тазком за 3К это сделать. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.