[jab]

Собственно говоря, на форумах все как обычно! у всех все работает, а отписать что-то конкретнее никто не может

А смысл ?

[colinn]

смысл собственно форума тогда... когда один трёп.

[jab]

смысл собственно форума тогда... когда один трёп.

Смысл этого форума - чтобы Нагибин мог впаривать бэушные киски. Ну еще баннеры крутить. :-)

[colinn]

ну тогда мне наверное читать этот форум не надо... так как я не хочу покупать кску тем более бэушную..)))

[stim89]

смысл собственно форума тогда... когда один трёп.

Смысл этого форума - чтобы Нагибин мог впаривать бэушные киски. Ну еще баннеры крутить. :-)

 

Давай подойдем чуть серьезнее к этому вопросу, т.к действительно нуждаемся в помощи. Конфиги от тебя реально получить на мыло к примеру?

[colinn]

Если чесно я хочу посмотреть реальный конфиг мпд и ядра на машинке где крутится до 500 пользователей pppoe с нарезанными трубами. И всё это не падает и выдаёт нормальную скорость своих пайпов.

[jab]

 

Да ладно, чего уж скромничать-то, скажите просто - хотим, чтобы кто-нибудь приехал, и решил бы за нас наши проблемы. Потому как документацию нам читать лень, а денег хочется. :-)

[vadimus]

Для пользователя jab этот форум - исключительно для развития чувства собственной важности, ну и ещё BSDения =)) Но если приобрести нормальный компьютер (какой-нибудь brand name server с Xeon E5460 на борту), поставить туда операционку с нормальной поддержкой многопроцессорности (т. е. не FreeBSD), то я думаю 5000 пользователей потянет нормально... Да и FreeBSD, наверное, потянет...

[colinn]

Для пользователя jab этот форум - исключительно для развития чувства собственной важности, ну и ещё BSDения =)) Но если приобрести нормальный компьютер (какой-нибудь brand name server с Xeon E5460 на борту), поставить туда операционку с нормальной поддержкой многопроцессорности (т. е. не FreeBSD), то я думаю 5000 пользователей потянет нормально... Да и FreeBSD, наверное, потянет...

А это чисто теоретическое предположение. Или оно чем-то подкреплено?? т.е. вы хотите сказать, что если собрать машинку скажем за 5К на базе того что выше сказали, то можно сказать что cisco 7206 npe g2 за ~20K отдыхает????

Изменено 7 февраля, 2008 пользователем colinn

[jab]

с нормальной поддержкой многопроцессорности (т. е. не FreeBSD),

Да я как-то на SMPng не жалуюсь, ни на Core2Duo ни на Core2Quad. По cost effectivity Xeon и рядом не валялся.

И как я писал выше - 8000 юзеров можно поднять без проблем почти на любом современном железе.

[dsk]

Все ж наверное больше должны быть интересны параметры в sysctl.conf и loader.conf, конфиги это вещь относительно типовая во многих случаях и хорошо задокументированная.

Лично меня интересует борьба с ошибками в input-е физического интерфейса на больших нагрузках, на остальное пока не жалуюсь :)

[colinn]

Все ж наверное больше должны быть интересны параметры в sysctl.conf и loader.conf, конфиги это вещь относительно типовая во многих случаях и хорошо задокументированная.

Лично меня интересует борьба с ошибками в input-е физического интерфейса на больших нагрузках, на остальное пока не жалуюсь :)

какое кол-во ошибок за минуту проходит и на какой нагрузке pps? mbps??? и как они идут постоянно по немногу или пачками?

у меня было немного где то около 1000 за 10 сек, пачками при нагрузке 150мбит в одну сторону и 30000 pps. Побороли заменой сетевых.

Сейчас картина совершенно идельная.

netstat -I em1 -w 60 -d

input (em1) output

packets errs bytes packets errs bytes colls drops

1721053 0 1272213167 1758391 0 1051553113 0 0

1722961 0 1277333613 1755262 0 1061086843 0 0

 

Изменено 7 февраля, 2008 пользователем colinn

[dsk]

Ну вот к примеру чуточку пофлудили :)

netstat -Iem0 -w1 -d
           input          (em0)           output
   packets  errs      bytes    packets  errs      bytes colls drops
      9891     0    7809242       9824     0    7783237     0     0
     32860     0   42969389      32825     0   42951299     0     0
     72298     0  102388080      72246     0  102365230     0     0
     71227     0  101377320      71160     0  101355227     0     0
     74816     2  104776413      74764     0  104750802     0     0
     74214    10  104064359      74159     0  104039637     0     0
     76008     0  105497568      75965     0  105466551     0     0
     76350     5  105856197      76292     0  105827364     0     0
     75738     0  105475654      75671     0  105447966     0     0
     75580     0  105163319      75509     0  105133921     0     0
     73069     7  102974682      73015     0  102950587     0     0
     29203     0   37313092      29175     0   37296588     0     0

 

Тазик:

CPU: Intel® Core™2 Duo CPU E6750

Мать: Intel DG33BU

Сетевуха интегрированная на ICH9

 

Файрвола на тазике нет, ну кроме allow ip from any to any.

Немножечко pf nat-а.

Изменено 8 февраля, 2008 пользователем dsk

[colinn]

А во что включён шнурок с этой сетевой, в коммутатор? Такими маленькими эрорами я думаю можно вообще пренебречь. А вообще у меня такие ошибки когда то давал патчкорд.

[dsk]

Из за таких вот маленьких ерроров игроманы совсем не маленько выносят моск техподдержке.

Их кстати может быть и больше и на меньших нагрузках, первый раз вылечили на одном тазике серьезной оптимизацией файрвола (дальше уж просто некуда), но нагрузки растут и незванные ошибочки снова спешат заглянуть в гости.

 

Шнурок включен естесственно в коммутатор, но проблема не в шнурке ибо данный "баг" вот уже много времени я наблюдаю на различных тазиках, и не только на em но и на bge.

 

 

Изменено 8 февраля, 2008 пользователем dsk

[colinn]

т.е. ты хочешь сказать что вот такие маленькие ошибки могут давать ощутимые потери??

[dsk]

В таких масштабах нет, но при большей разношерстности трафика (то что видно - флуд синтетический) может возникнуть больше ошибок что приводит к потерям.

Вот кстати немного усложнил условия, добавил три правила файрвола с таблицами, в каждой таблице по 1024 ip адреса.

UDP пакетиками по 409 байт:

    147497     0   69204466     147417     0   69191591     0
    147595     0   68986187     147531     0   68975806     0
    147763     0   69335706     147700     0   69325228     0
    147828     0   69353609     147739     0   69340075     0
    146063     0   67826000     145991     0   67816591     0
    146476     0   67714078     146368     0   67692792     0
    147934     0   69889464     147875     0   69878032     0
    148499     0   70034670     148415     0   70024535     0
    147536     0   68612778     147421     0   68593480     0
    101580     0   48183584     101495     0   48172759     0

картинка фактически идеальная, а теперь пакетиками по 204 байта

    144381     0   44029183     144317     0   44001519     0
    200417     2   61150367     200360     0   61113873     0
    200000    18   60574194     199916     0   60534196     0
    201698    46   58737956     201633     0   58707399     0
    200574    28   59654660     200476     0   59606593     0
    201195     7   58542833     201140     0   58512115     0
    205978    10   60370160     205888     0   60330035     0
    194342     1   57134025     194257     0   57103932     0
    194402     0   57723345     194338     0   57693139     0
    193848     1   55615889     193787     0   55590227     0

при этом на параллельном пинге потерялся один пакет, но самое неприятное это начали скакать задержки от 9 до 20-и мс.

 

В дополнение:

все что выше это без поллинга, а вот с поллингом и пакетами по 409 байт и kern.polling.user.frac=0

    126849     0   58981983     126793     0   58972562     0
    144804     1   66668296     144711     0   66656345     0
    144151     0   65867311     144059     0   65856938     0
    143868     0   65510619     143775     0   65501084     0
    144845     0   66228734     144785     0   66219944     0
    145163     1   66798554     145094     0   66787637     0
    145181    17   67866459     145100     0   67852924     0
    146461     3   68174046     146372     0   68161497     0
    145145     2   67023479     145058     0   67011689     0

пинг прыгает 2-4 мс, потерь не замечено, а теперь значение по уолчанию kern.polling.user.frac=50 и те же пакеты:

     14130     0    7536472      14079     0    7531661     0
     79315     0   37146319      79212     0   37136561     0
     79612     0   37013477      79544     0   37006412     0
     78878     0   36700661      78764     0   36684761     0
     78863     0   36518802      78799     0   36510156     0
     79154     0   37067292      79068     0   37055870     0
     78973     0   36987718      78871     0   36978769     0
     79230     0   37004406      79162     0   36997692     0
     78819     0   36776352      78738     0   36769214     0
     78798     0   36755073      78730     0   36746845     0

Производительность упала вдвое, но и ошибок нет.

 

Изменено 8 февраля, 2008 пользователем dsk

[Ivan Rostovikov]

>8000 юзеров можно поднять

Вопрос не в количестве. А в том что и как эти 8000 будут передавать.

Этож какие линки нужны если 8000 PPPoE онлайн ? Несколько гигабитных адаптеров ? А ведь на PPPoE аппаратный TCP offload - не канает. А что если это "домашние сети" ? Локальный трафик там серьезный. У меня Core2Quad. Тянет примерно по 100000 p/s на каждое ядро. Дальше начинаются проблемы с задержкой пакетов.

[jab]

:-)

 

Да кого это волнует ? Тут главное - чтобы тачка была brand name. И Xeon потолще. Чем дороже тачка, тем больше

откат с нее. Чем толще Xeon - тем шире можно пальцы растопыривать. А юзеров можно и в одну сотку засунуть, на кой

им гигабит ?

 

 

[jab]

 

Если всем так необходим polling, то почему ни один не прочитал документацию по нему ? :-)))

[dsk]

Да читал неоднократно, но видимо нужной изюминки не заметил :) Но да и не в нем собственно дело, меня ошибки больше всего беспокоят, они есть и с ним и без него.

[jab]

Да читал неоднократно, но видимо нужной изюминки не заметил :) Но да и не в нем собственно дело, меня ошибки больше всего беспокоят, они есть и с ним и без него.

Ну Вы надеюсь понимаете, что просто вкомпилив polling в ядро Вы ломаете весь SMP ? И просто отключить его на интерфейсах - недостаточно.

Надо пересобирать ядро без поллинга и выставлять таймауты в драйвере сетевухи, чтобы она не жрала интеррапты. Кроме того, дефолтные

настройки поллинга с hz=1000 и intr_queue=50 позволяют быстро пропустить не более 150kpps суммарно в обе стороны. Дальше просто пойдут дропы,

и рост задержек. Ну и очевидное - драйвер карточки ( если это em(4) ) надо ставить самый свежий.

[dsk]

Понимаю понимаю, не зря em6-6-6 с поллингом в ядре не собирается. Пробовал em от яндекса, но спонтанно начал появляться флаг OACTIVE, поднялось много воплей и пришлось срочно делать откат.

И кстати что лучше, em непосредственно с intel.com или em из STABLE ?

Изменено 8 февраля, 2008 пользователем dsk

[jab]

Понимаю понимаю, не зря em6-6-6 с поллингом в ядре не собирается. Пробовал em от яндекса, но спонтанно начал появляться флаг OACTIVE, поднялось много воплей и пришлось срочно делать откат.

И кстати что лучше, em непосредственно с intel.com или em из STABLE ?

Ну лучшее что я видел без поллинга - это 6.7.3 в 7.0-RC1

 

Хотя у меня например и 6.2.9 с поллингом прекрасно работает.

 

Понимаю понимаю, не зря em6-6-6 с поллингом в ядре не собирается.

Если понимаете, то что у вас прописано в intr_queue и в kern.polling.* ? И какой смысл был возвращать user_fraq на 50% ?

[dsk]

Чтобы посмотреть на сколько плохо будет при значении по умолчанию, это ж чисто эксперимент был.

И все же я б хотел что-нибудь про ошибки услышать, по поводу pps меня пока все устраивает и с поллингом и без, а ошибки могут появляться и на меньших pps чем выходило на испытаниях.