Перейти до

Рекомендованные сообщения

Опубліковано:
5 часов назад, KaYot сказал:

А зачем крутить? И так по ядрам нагрузка разлилась, все красиво.

либо с серваком что-то не то, либо таки надо тюнить, с картой 4*1 на чипе интела стало только хуже, при трафике уже 500-600мбит, скорость жутко падает, спидтест показывает на закачке 2-3мбит , а на отдачу хоть все 100мбит

Опубліковано:
1 час назад, WideAreaNetwork сказал:

либо с серваком что-то не то, либо таки надо тюнить, с картой 4*1 на чипе интела стало только хуже, при трафике уже 500-600мбит, скорость жутко падает, спидтест показывает на закачке 2-3мбит , а на отдачу хоть все 100мбит

а что за железо на серваке стоит?

Опубліковано: (відредаговано)
13 часов назад, NaviNavi сказал:

а что за железо на серваке стоит?

HP Proliant DL360G5 Intel(R) Xeon(R) CPU 2хL5420  @ 2.50GHz, на котором крутится все, нат, роутинг, биллинг, шейпер, днс,апач, мускул и т.д.

пока настраиваю тюнинг там посмотрим что выйдет с этого

 

подскажите, значения sysctl можно вернуть по умолчания без ребута, если настраивались на лету?

Відредаговано WideAreaNetwork
Опубліковано: (відредаговано)
1 час назад, WideAreaNetwork сказал:

HP Proliant DL360G5 Intel(R) Xeon(R) CPU 2хL5420  @ 2.50GHz, на котором крутится все, нат, роутинг, биллинг, шейпер, днс,апач, мускул и т.д.

пока настраиваю тюнинг там посмотрим что выйдет с этого

 

подскажите, значения sysctl можно вернуть по умолчания без ребута, если настраивались на лету?

Это фантастика какая-то. Ищите узкое место ибо 500мбит/с должно даже на одной встроенной карт работать, а не то что на лагге из 4-х интеловских карт. Смотрите загрузку процессора поядерно (top может показівать неверно!), смотрите есть ли потери пакетов, смотрите, какой именно процесс садит производительность, смотрите действительно ли приём и передача пакетов равномерно распределяются по физическим интерфейсам. Роутинг - это что? Есть BGP или просто статика? Нат, шейпер, файервол вполне могут садить всё. На чём сделано? Штатно, на ipfw? Ой, да тут столько вариантов может быть, что даже тяжело что-то посоветовать, вплоть до технической неисправности.

Менять на лету можно те, которые меняются, которые в sysctl.conf. Те, которые в  loader.conf - только через перезагрузку. Если на лету поменять нельзя - оно вам скажет, не переживайте.

Відредаговано Baneff
  • Thanks 1
Опубліковано:
7 часов назад, Baneff сказал:

Штатно, на ipfw?

а ведь @KaYot мне практически сразу об этом сказал))) выключил все правила

ipfw add 1 allow ip from any to any

и по спидтесту вместо 30мбит/200мбит получил 245мбит на 195мбит

получается тюнить нужно не так всю ОС для инета , как правила IPFW

Опубліковано:
7 часов назад, Baneff сказал:

Смотрите загрузку процессора поядерно (top может показівать неверно!), смотрите есть ли потери пакетов, смотрите, какой именно процесс садит производительность

поделись, как это все увидеть?

Опубліковано:
Только что, WideAreaNetwork сказал:

а разве 


top -SCHIP 

не поядерно видит?

связан с этим:

8 часов назад, Baneff сказал:

top может показівать неверно!

 

Опубліковано:
43 минуты назад, WideAreaNetwork сказал:

а ведь @KaYot мне практически сразу об этом сказал))) выключил все правила


ipfw add 1 allow ip from any to any

и по спидтесту вместо 30мбит/200мбит получил 245мбит на 195мбит

получается тюнить нужно не так всю ОС для инета , как правила IPFW

Ну сам-то ipfw сильно систему не грузит, это надо специально постараться. Если там максимум несколько десятков правил с правильной логикой последовательности и с упаковкой данных в таблицы, то всё будет ок. Штатный ядерный NAT тоже не должен создавать большой нагрузки по идее. А вот штатный шейпер dummynet может легко пригрузить, да. Ну и потом систему грузит не так скорость, как кол-во пакетов в сек pps, котрые через систему пролетают? То есть если летит куча мелких пакетов, то это грузит больше. Но это ж азы, я так, на всякий случай.

Опубліковано:
13 минут назад, Baneff сказал:

Ну и потом систему грузит не так скорость, как кол-во пакетов в сек pps, котрые через систему пролетают? То есть если летит куча мелких пакетов, то это грузит больше.

так и есть, при 200kpps начинаются траблы, при 300kpps невозможно ничего в онлайне смотреть

Опубліковано:
11 часов назад, WideAreaNetwork сказал:

крутится все, нат, роутинг, биллинг, шейпер, днс,апач, мускул и т.д.

я ебу. А самбы, сислога, беапного с конфигами там нет часом? Ну чтоб флешрояль был.

Опубліковано:

ах да, дурачок я, при 600-700мбит трафике еще в декабре мне надо было поставить 10 компов/серваков, ща дойдем до гига и целый кластер построим

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

Опубліковано: (відредаговано)

perf top -U есть во фре?

а

atop?

17 минут назад, WideAreaNetwork сказал:

еще в декабре мне надо было поставить 10 компов/серваков

Нахуя? Просто выучить что такое KVM. Ну или на худой конец - проксмос

Відредаговано Dimkers
Опубліковано:
44 минуты назад, Dimkers сказал:

Ну или на худой конец - проксмос

как раз его и изучаю

52 минуты назад, Dimkers сказал:

perf top -U есть во фре?

не нашел

52 минуты назад, Dimkers сказал:

а

atop?

утилиту в портах нашел, еще не установлена

Опубліковано:

так установите, там наглядно можно глянуть что может подтупливать тачку.

 

Кстати прерывания сетевок пробовали развесить только на 1 проц?

 

  • Thanks 1
Опубліковано:
20 минут назад, Dimkers сказал:

так установите, там наглядно можно глянуть что может подтупливать тачку.

сделаю

23 минуты назад, Dimkers сказал:

Кстати прерывания сетевок пробовали развесить только на 1 проц?

пока ищу и читаю мануалы как это делать, до этого не было карты которую можно было раскидывать

Опубліковано:
5 часов назад, Dimkers сказал:

Пару линков тогда вам для общей кучки

спасибо, только у нас FreeBSD :) сути не меняет наверное, буду искать как делать для нашей ОСи

Опубліковано:

Отвечу тут на обращение в личку, может ещё кому пригодится. По поводу привязки процессов к ядрам. к ядрам.

 

По состоянию на FreeBSD 11 . В 12 и 13 возможно что-то поменялось, не знаю, надо проверять.

Наши эксперименты привели к отрицательному результату: попытка привязать dummynet или прерывания к ядрам ничего не улучшили, а может даже и ухудшили ситуацию. Система сама достаточно хорошо рапределяет нагрузку по ядрам в автомате, без ручного управления, поэтому в результате мы от привязки отказались.

 

По поводу dummynet есть в нюансы. Во первых, надо учитывать, что dummynet  всё ещё не научили на тот момент параллелиться, к сожалению в каждый момент одновременно работала только на одном ядре, хотя по ядрам скакала без проблем. Поэтому конфигурация с например четырьмя ядрами на 4-ГГц могла шейпить эффективнее, чем конфигурация с 16 ядрами на 2.4ГГц, вопрос был в скорости одного ядра. Все остальные процессы параллелились прекрасно, соответственно на многоядерной системе всё бегало бы резвее, но увы. Возможно сейчас уже исправили.

 

Во-вторых. Много писали в форумах о том, что привязка dummynet  ядру 0 резко снижает нагрузку. Так вот, это был такой баг, который к периоду 11-й и позже версий уже никакого отношения не имеет - исправили. Однако, если есть желание поэкспериментировать, то вот так это в 11-й делалось, нашёл я в своих записках вот такое:

 

Привязать dummynet к определённому ядру CPU (пример):
procstat -at | grep dummynet
    0 100026 kernel           dummynet           1   16 sleep   -       
cpuset -t 100026 -l 0

 

Отвязать dummynet  от определённых ядер и снова размазать по всем ядрам как было (для 8-core):
cpuset -t 100026 -l 0-7

 

Привязывается dummynet к CPU0 одной командой:
cpuset -l 0 -t `procstat -t 0 | awk '/dummynet/ {print $2}'`

 

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

  • Thanks 2
Опубліковано:

Ещё добавлю по поводу измерения нагрузки на ядра и процессы. Да, есть штатный top и в портах есть atop удобный и логи пишет. Есть в портах ещё какие-то утильки подобные. Но в своё время писали в форумах, что они неправильно показывают загрузку. Не знаю правильно или неправильно, сравнивать лень было, но была поставлена задача нарисовать с помощью системы mrtg (есть в портах) точно правильный график общей средней загрузки по всем ядрам и процессам и отдельно, как самый критичный, график загрузки dummynet. Оказалось, что самая первичная и самая точная информация о загрузке выдается в системных переменных kern.cp_time и поядерно kern.cp_times . Смотреть значения можно естественно с помощью sysctl и дальше обработка с помощью скрипта и передача данных в mrtg . Там данные по загрузке процессора в неких попугаях или тиках, неважно, но результат после вычислений выходит правильный. Если кого-то интересуют детали реализации, то могу попробовать поискать в архивах и сам скрипт и настройки mrtg . Этот же скрипт вычислял и загрузку dummynet  с помощью утилит procstat и ps .

  • Thanks 1
Опубліковано:

Мне кажется заразу я таки нашел, убрал в фаерволе правила для ipcad-а (да да на том же серваке ещё колектор) и скорость с 20мбит в ЧНН стала снова 250-300мбит, либо ipcad выносить на отдельную машину ( а это возможно?) либо искать другие пути сбора трафика, или вообще отказаться от этого

Опубліковано:
1 час назад, WideAreaNetwork сказал:

Мне кажется заразу я таки нашел, убрал в фаерволе правила для ipcad-а (да да на том же серваке ещё колектор) и скорость с 20мбит в ЧНН стала снова 250-300мбит, либо ipcad выносить на отдельную машину ( а это возможно?) либо искать другие пути сбора трафика, или вообще отказаться от этого

Да, это тоже проходили, конечно убрать ipcad . Надо было сразу огласить весь список. Лично я не против варианта "всё в одном", но некоторые вещи таки не стОит. А оно надо вообще, траффик мониторить? Кроме того есть и другие методы.

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
×
×
  • Створити нове...