FreeBSD 7.2 - Высокий load averages

[RockManX 9]

 

 

роде как deny_in (ее отсутвие)

не из-за того что машине приходится отвечать на каждый откинутый пакет?

sysctl -a | grep blackhole 

[pavlabor 1 939]

 

@kvirtu, как успехи? Что нового?

Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже

Тестирую пока 9.3. - завтра хочу попробовать

 

Проблема не в отсутствии  deny_in, а в железе.

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

аверейдж будет расти до 5-10-20..., пинги до несколько секунд, очередь дропацца, но тачка не должна ребутится.

А если тачка ребутится, то это означает что  грабли в железе, проявляются на определенной, высокой нагрузке, вот и фсе.

 

То что ты тюнингуеш, прикрутил  deny_in и понизил нагрузку...,

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

бизнес на таком железе делать не рекомендуется.

[BARVIT 113]

@pavlabor, когда у меня такая вещь была (правда в ребут ничего не уходило, но проц валило в 100%) машина становилась недоступна... смена железа ровным счетом ничего не меняло. i7 ложился в 2 минуты. с deny_in работает и старичок, убрал i7 и забыл про проблему. Хз в чем тут причина.

[pavlabor 1 939]

@pavlabor, когда у меня такая вещь была (правда в ребут ничего не уходило, но проц валило в 100%) машина становилась недоступна... смена железа ровным счетом ничего не меняло. i7 ложился в 2 минуты. с deny_in работает и старичок, убрал i7 и забыл про проблему. Хз в чем тут причина.

Сетевой кабель отключаешь и все задышало..., отличное железо!

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

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

[KaYot 3 708]

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

Человек менял все железо, включая сетевки. Тут скорее какие-то вылезающие только у него баги БСД.

[kvirtu 315]

 

роде как deny_in (ее отсутвие)

не из-за того что машине приходится отвечать на каждый откинутый пакет?

sysctl -a | grep blackhole 

 

sysctl -a | grep blackhole

net.inet.tcp.blackhole: 2

net.inet.udp.blackhole: 1

 

Эти переменные уже как 2 года прописаны

[kvirtu 315]

 

 

@kvirtu, как успехи? Что нового?

Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже

Тестирую пока 9.3. - завтра хочу попробовать

 

Проблема не в отсутствии  deny_in, а в железе.

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

аверейдж будет расти до 5-10-20..., пинги до несколько секунд, очередь дропацца, но тачка не должна ребутится.

А если тачка ребутится, то это означает что  грабли в железе, проявляются на определенной, высокой нагрузке, вот и фсе.

 

То что ты тюнингуеш, прикрутил  deny_in и понизил нагрузку...,

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

бизнес на таком железе делать не рекомендуется.

 

хорошо,а чем Вы объясните именно  лавинообразный, быстрый  рост нагрузки, и также резкий его спад ?

[kha0s 112]

 

 

хорошо,а чем Вы объясните именно  лавинообразный, быстрый  рост нагрузки, и также резкий его спад ?

 

А не пробовали вести аккаунтинг. Тот-же netflow генерировать и принимать коллектором?  Думаю в моменты пиковых тормозов там найдется ответ. 

[kvirtu 315]

 

хорошо,а чем Вы объясните именно  лавинообразный, быстрый  рост нагрузки, и также резкий его спад ?

 

А не пробовали вести аккаунтинг. Тот-же netflow генерировать и принимать коллектором?  Думаю в моменты пиковых тормозов там найдется ответ. 

 

думал, но пока все хорошо, хотя попытки скачков были, в практически в ТОЖЕ  самое время, как и раньше. Около 12:30 ,  15 часов , 17 часов. Скрин выложу

[kha0s 112]

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

[kvirtu 315]

В общем похоже на атаку, могу ошибаться, НО все происходит в одно и тоже время.

Помогает добавление deny_in в правило НАТа . Росла нагрузка на внешнем igb0.

Почему так долго было, МОЯ НЕвнимательность .

Значит,  в моем фаерволе в НАТе прописано log same_ports deny_in unreg_only . Я использую Абилс, там скрипт, который создает НАТ и шейпер, но без deny_in и перетирает мой НАТ. (читал доку по абилсу невнимательно, мой косяк).

В моменты пиковых нагрузок,  я отключал абиловский НАТ и шейпер и включал свой НАТ. После этого нагрузка падала.

вот график загрузки, черными кружечками обозначены пики за сегодня

Изменено 2015-02-24 15:34:10 пользователем kvirtu

[pavlabor 1 939]

Судя по нагрузке, у тебя банально не хватает расчетной мощности.

Аверейдж при нормальной комплектации, должен держаться на уровне единицы,

пинги в пределах не более 0,500 миллисекунд.

 

Маштабируйся.

backup3# uptime
17:40  up 335 days,  8:12, 1 user, load averages: 0,04 0,08 0,08
180-26# uptime
17:43  up 165 days,  4:21, 2 users, load averages: 0,15 0,12 0,09

Ездят раз в два года, акумы менять.

Изменено 2015-02-24 16:16:51 пользователем pavlabor

[kha0s 112]

 

 

я отключал абиловский НАТ и шейпер и включал свой НАТ

 

ключевое слово - "абилсовский нат".  А в этой теме всегда упоминалось - отключаю ШЕЙПЕР и все работает. Соотв. не там искали.

[kvirtu 315]

Судя по нагрузке, у тебя банально не хватает расчетной мощности.

Аверейдж при нормальной комплектации, должен держаться на уровне единицы,

пинги в пределах не более 500 миллисекунд.

 

Маштабируйся.

backup3# uptime

17:40  up 335 days,  8:12, 1 user, load averages: 0,04 0,08 0,08

 

это в процентах

[kvirtu 315]

 

я отключал абиловский НАТ и шейпер и включал свой НАТ

 

ключевое слово - "абилсовский нат".  А в этой теме всегда упоминалось - отключаю ШЕЙПЕР и все работает. Соотв. не там искали.

 

та да

[ttttt 195]

Линукс бы не помог с невнимательностью, а линуксоидам так хотелось

[kvirtu 315]

Линукс бы не помог с невнимательностью, а линуксоидам так хотелось

, наблюдаем

[DemonidZe 15]

и как наблюдается?

[kvirtu 315]

и как наблюдается?

отлично

[WideAreaNetwork 222]

помогите пжл, если чего не правильно понимаю то пните в правильную сторону

 

есть утилита procstat которая отображает детальную информацию о процессах, задача стоит привязать dummynet к 0 ядру а прерывания сетевой карты к 1-7 ядрам, вроде как все просто, но обязательно вылезет какая-то ошибка которая не даст пожить нормально

 

так как шейпер dummynet и прерывания interrupt являются системными процессами их PID всегда равен 0, это видно по команде procstat -at, но эта же команда еще отображает TID процеса, если правильно понимаю то это поток (thread), на просторах инета есть скриптики по прибиванию потока к ядру с помощью утилиты cpuset, все это выглядит где-то так

#!/bin/sh

AWK=/usr/bin/awk
CPUSET=/usr/bin/cpuset
GREP=/usr/bin/grep
PROCSTAT=/usr/bin/procstat

PROCESS=dummynet

TID=`$PROCSTAT -at | $GREP $PROCESS |$AWK '"/$PROCESS/" {print $2}'`
$CPUSET -l 0 -t $TID

думаю дайка сначала проверю (проверял на виртуалке)

procstat -at | grep dummynet | awk '{print $2}'

в ответ естественно получил номер TID (айди потока), после чего делаю так званое "прибивание"

cpuset -l 0 -t [номер TID]

на виртуалке все хорошо, перешел на боевой сервак, и по аналогии хотел прибить потоки прерываний сетевой карты к ядрам 1-7, для начала сделал на боевом серваке

procstat -at | grep igb | grep intr | awk '{print $2}'

в ответ получил номера потоков

$ procstat -at | grep igb | grep intr | awk '{print $2}'
procstat: sysctl(kern.proc): No such process
100055
100057
100059
100061
100063
100065
100067
100069
100071
100072
100074
100076
100078
100080
100082
100084
100086
100088
100089
100091
100093
100095
100097
100099
100101
100103
100105
100106
100108
100110
100112
100114
100116
100118
100120
100122

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

$ procstat -at | grep dummynet
    0 100171 kernel              dummynet              0    8 run     -
procstat: sysctl(kern.proc): No such process

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

 

$ cpuset -l 1-7 -t `procstat -at | grep igb | grep intr | awk '{print $2}'`
procstat: sysctl(kern.proc): No such process
usage: cpuset [-l cpu-list] [-s setid] cmd ...
       cpuset [-l cpu-list] [-s setid] -p pid
       cpuset [-c] [-l cpu-list] -C -p pid
       cpuset [-c] [-l cpu-list] [-j jailid | -p pid | -t tid | -s setid | -x irq]
       cpuset -g [-cir] [-d domain | -j jailid | -p pid | -t tid | -s setid |
              -x irq]

как избавится от ошибки?

ЧЯДНТ ?

[mixtery 121]

 procstat -k 0 | awk '/igb/ { print $2 }'

[WideAreaNetwork 222]

14 часов назад, mixtery сказав:

procstat -k 0 | awk '/igb/ { print $2 }'

вывод этих потоков разнится от прерываний