RockManX 9 Posted 2015-02-24 10:22:49 Share Posted 2015-02-24 10:22:49 роде как deny_in (ее отсутвие) не из-за того что машине приходится отвечать на каждый откинутый пакет? sysctl -a | grep blackhole Link to post Share on other sites
pavlabor 1,977 Posted 2015-02-24 10:30:47 Share Posted 2015-02-24 10:30:47 @kvirtu, как успехи? Что нового? Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже Тестирую пока 9.3. - завтра хочу попробовать Проблема не в отсутствии deny_in, а в железе. Потому как железо, доже при отсутствии deny_in, должно переваривать поток и не ребутится, аверейдж будет расти до 5-10-20..., пинги до несколько секунд, очередь дропацца, но тачка не должна ребутится. А если тачка ребутится, то это означает что грабли в железе, проявляются на определенной, высокой нагрузке, вот и фсе. То что ты тюнингуеш, прикрутил deny_in и понизил нагрузку..., конечно круто, но это железо не реанимирует и наступит определенный уровень нагрузки даже при наличии deny_in, и тачка твоя свалится, бизнес на таком железе делать не рекомендуется. Link to post Share on other sites
BARVIT 113 Posted 2015-02-24 10:34:28 Share Posted 2015-02-24 10:34:28 @pavlabor, когда у меня такая вещь была (правда в ребут ничего не уходило, но проц валило в 100%) машина становилась недоступна... смена железа ровным счетом ничего не меняло. i7 ложился в 2 минуты. с deny_in работает и старичок, убрал i7 и забыл про проблему. Хз в чем тут причина. Link to post Share on other sites
pavlabor 1,977 Posted 2015-02-24 10:45:59 Share Posted 2015-02-24 10:45:59 @pavlabor, когда у меня такая вещь была (правда в ребут ничего не уходило, но проц валило в 100%) машина становилась недоступна... смена железа ровным счетом ничего не меняло. i7 ложился в 2 минуты. с deny_in работает и старичок, убрал i7 и забыл про проблему. Хз в чем тут причина. Сетевой кабель отключаешь и все задышало..., отличное железо! А в данном случае, не факт что копаешься с проблемой. Ребут, это в большинстве случаем накопление ошибки при не соответствии частот, битая ячейка памяти, перегоревший один из миллионов транзистор в проце... Link to post Share on other sites
KaYot 3,732 Posted 2015-02-24 11:45:49 Share Posted 2015-02-24 11:45:49 Ребут, это в большинстве случаем накопление ошибки при не соответствии частот, битая ячейка памяти, перегоревший один из миллионов транзистор в проце...Человек менял все железо, включая сетевки. Тут скорее какие-то вылезающие только у него баги БСД. Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 11:53:41 Author Share Posted 2015-02-24 11:53:41 роде как deny_in (ее отсутвие) не из-за того что машине приходится отвечать на каждый откинутый пакет? sysctl -a | grep blackhole sysctl -a | grep blackhole net.inet.tcp.blackhole: 2 net.inet.udp.blackhole: 1 Эти переменные уже как 2 года прописаны Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 11:58:19 Author Share Posted 2015-02-24 11:58:19 @kvirtu, как успехи? Что нового? Пока все хорошо, вроде бы нашел причину, вроде как deny_in (ее отсутвие). Распишу свои предположения чуть позже Тестирую пока 9.3. - завтра хочу попробовать Проблема не в отсутствии deny_in, а в железе. Потому как железо, доже при отсутствии deny_in, должно переваривать поток и не ребутится, аверейдж будет расти до 5-10-20..., пинги до несколько секунд, очередь дропацца, но тачка не должна ребутится. А если тачка ребутится, то это означает что грабли в железе, проявляются на определенной, высокой нагрузке, вот и фсе. То что ты тюнингуеш, прикрутил deny_in и понизил нагрузку..., конечно круто, но это железо не реанимирует и наступит определенный уровень нагрузки даже при наличии deny_in, и тачка твоя свалится, бизнес на таком железе делать не рекомендуется. хорошо,а чем Вы объясните именно лавинообразный, быстрый рост нагрузки, и также резкий его спад ? Link to post Share on other sites
kha0s 112 Posted 2015-02-24 13:05:51 Share Posted 2015-02-24 13:05:51 хорошо,а чем Вы объясните именно лавинообразный, быстрый рост нагрузки, и также резкий его спад ? А не пробовали вести аккаунтинг. Тот-же netflow генерировать и принимать коллектором? Думаю в моменты пиковых тормозов там найдется ответ. Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 15:08:48 Author Share Posted 2015-02-24 15:08:48 хорошо,а чем Вы объясните именно лавинообразный, быстрый рост нагрузки, и также резкий его спад ? А не пробовали вести аккаунтинг. Тот-же netflow генерировать и принимать коллектором? Думаю в моменты пиковых тормозов там найдется ответ. думал, но пока все хорошо, хотя попытки скачков были, в практически в ТОЖЕ самое время, как и раньше. Около 12:30 , 15 часов , 17 часов. Скрин выложу Link to post Share on other sites
kha0s 112 Posted 2015-02-24 15:25:01 Share Posted 2015-02-24 15:25:01 Есть проблемный трафик. Чем быстее от идентифицируется, тем быстрее можно решить как с ним поступать или почему он приводит к таким последствиям (кривой нат, шейпер, файрвол, еще чего...) Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 15:30:52 Author Share Posted 2015-02-24 15:30:52 (edited) В общем похоже на атаку, могу ошибаться, НО все происходит в одно и тоже время. Помогает добавление deny_in в правило НАТа . Росла нагрузка на внешнем igb0. Почему так долго было, МОЯ НЕвнимательность . Значит, в моем фаерволе в НАТе прописано log same_ports deny_in unreg_only . Я использую Абилс, там скрипт, который создает НАТ и шейпер, но без deny_in и перетирает мой НАТ. (читал доку по абилсу невнимательно, мой косяк). В моменты пиковых нагрузок, я отключал абиловский НАТ и шейпер и включал свой НАТ. После этого нагрузка падала. вот график загрузки, черными кружечками обозначены пики за сегодня Edited 2015-02-24 15:34:10 by kvirtu Link to post Share on other sites
pavlabor 1,977 Posted 2015-02-24 15:38:49 Share Posted 2015-02-24 15:38:49 (edited) Судя по нагрузке, у тебя банально не хватает расчетной мощности. Аверейдж при нормальной комплектации, должен держаться на уровне единицы, пинги в пределах не более 0,500 миллисекунд. Маштабируйся. backup3# uptime17:40 up 335 days, 8:12, 1 user, load averages: 0,04 0,08 0,08180-26# uptime17:43 up 165 days, 4:21, 2 users, load averages: 0,15 0,12 0,09Ездят раз в два года, акумы менять. Edited 2015-02-24 16:16:51 by pavlabor Link to post Share on other sites
kha0s 112 Posted 2015-02-24 15:39:41 Share Posted 2015-02-24 15:39:41 я отключал абиловский НАТ и шейпер и включал свой НАТ ключевое слово - "абилсовский нат". А в этой теме всегда упоминалось - отключаю ШЕЙПЕР и все работает. Соотв. не там искали. Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 15:41:20 Author Share Posted 2015-02-24 15:41:20 Судя по нагрузке, у тебя банально не хватает расчетной мощности. Аверейдж при нормальной комплектации, должен держаться на уровне единицы, пинги в пределах не более 500 миллисекунд. Маштабируйся. backup3# uptime 17:40 up 335 days, 8:12, 1 user, load averages: 0,04 0,08 0,08 это в процентах Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 15:42:44 Author Share Posted 2015-02-24 15:42:44 я отключал абиловский НАТ и шейпер и включал свой НАТ ключевое слово - "абилсовский нат". А в этой теме всегда упоминалось - отключаю ШЕЙПЕР и все работает. Соотв. не там искали. та да Link to post Share on other sites
ttttt 195 Posted 2015-02-24 16:11:06 Share Posted 2015-02-24 16:11:06 Линукс бы не помог с невнимательностью, а линуксоидам так хотелось Link to post Share on other sites
kvirtu 315 Posted 2015-02-24 16:17:07 Author Share Posted 2015-02-24 16:17:07 Линукс бы не помог с невнимательностью, а линуксоидам так хотелось , наблюдаем Link to post Share on other sites
DemonidZe 15 Posted 2015-02-25 12:19:54 Share Posted 2015-02-25 12:19:54 и как наблюдается? Link to post Share on other sites
kvirtu 315 Posted 2015-02-25 18:32:22 Author Share Posted 2015-02-25 18:32:22 и как наблюдается? отлично Link to post Share on other sites
WideAreaNetwork 222 Posted 2020-03-16 18:56:19 Share Posted 2020-03-16 18:56:19 помогите пжл, если чего не правильно понимаю то пните в правильную сторону есть утилита 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] как избавится от ошибки? ЧЯДНТ ? Link to post Share on other sites
mixtery 123 Posted 2020-03-16 21:02:08 Share Posted 2020-03-16 21:02:08 procstat -k 0 | awk '/igb/ { print $2 }' Link to post Share on other sites
WideAreaNetwork 222 Posted 2020-03-17 11:38:00 Share Posted 2020-03-17 11:38:00 14 часов назад, mixtery сказав: procstat -k 0 | awk '/igb/ { print $2 }' вывод этих потоков разнится от прерываний Link to post Share on other sites
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now