Замучала UTM_CORE помогите!!!(исправили)теперь скорости нет

leonidq

Проблему с коре решили заного поставили UTM 006 и ручками перенесли абонентов.

Проблема с подключением пропала конект с первого раза. Загрузка коре не более 1% норм тоесть.

Осталась другая проблема: выходит она ближе к вечеру - скорость в инете загрузка страниц стает минимальная практически ее нет при этом канал внешний незабит свободен на 30-40%. Помогает только ребут сервера,но это невыход.

Система собрала вся на одной машине установлено 3 тарифа Базовый скорость на нем неограничена(ничего нережим там), Безлимитны и Офис скорость на них ограничена радиус параметрами. Куда смотреть кто подскажет? в логах все чисто. Скорость загрузки страниц падает на всех тарифах(как старый добрый диалап стает). В базе около 800абонентов из них половина на безлимитном тарифе.

Подскажите куда капнуть еще.

Нафаня

Нафаня писал(а):подскажите. Приформировании основного отчета утм стал падать в кору.
в дебаге вот :
http://pu12.tih.ru/debug.log
Это впервые такое за два года работы.
сталкивался кто с таким?
версия 004.
верификатор пуст.

Подскажет кто нибудь что нить?. еще кучу всяких мессаджей сыпется в дебаг непонятных...

Pulse · Сообщение **Pulse** » Пн ноя 01, 2010 16:58

Нафаня писал(а):
Нафаня писал(а):подскажите. Приформировании основного отчета утм стал падать в кору.
в дебаге вот :
http://pu12.tih.ru/debug.log
Это впервые такое за два года работы.
сталкивался кто с таким?
версия 004.
верификатор пуст.
Подскажет кто нибудь что нить?. еще кучу всяких мессаджей сыпется в дебаг непонятных...

обновись же!

Нафаня

Pulse писал(а):
Нафаня писал(а):
Нафаня писал(а):подскажите. Приформировании основного отчета утм стал падать в кору.
в дебаге вот :
http://pu12.tih.ru/debug.log
Это впервые такое за два года работы.
сталкивался кто с таким?
версия 004.
верификатор пуст.
Подскажет кто нибудь что нить?. еще кучу всяких мессаджей сыпется в дебаг непонятных...
обновись же!

Да взял обновления уже сейчас собрал тестовую тачку завтра винты привезут и буду обновляться. а можно сразу с 004 на 008 прагнуть? или по шагам обновляться?

Pulse · Сообщение **Pulse** » Пн ноя 01, 2010 17:39

в соседней ветке обсуждают

leonidq

leonidq писал(а):Проблему с коре решили заного поставили UTM 006 и ручками перенесли абонентов.

Проблема с подключением пропала конект с первого раза. Загрузка коре не более 1% норм тоесть.

Осталась другая проблема: выходит она ближе к вечеру - скорость в инете загрузка страниц стает минимальная практически ее нет при этом канал внешний незабит свободен на 30-40%. Помогает только ребут сервера,но это невыход.

Система собрала вся на одной машине установлено 3 тарифа Базовый скорость на нем неограничена(ничего нережим там), Безлимитны и Офис скорость на них ограничена радиус параметрами. Куда смотреть кто подскажет? в логах все чисто. Скорость загрузки страниц падает на всех тарифах(как старый добрый диалап стает). В базе около 800абонентов из них половина на безлимитном тарифе.

Подскажите куда капнуть еще.

Еще заметил в данное время когда скорость падает ставишь пинг до шлюза он сначала неидет пакет 3-4 пропадает,а потом пинг ровный, стоп пинг и поновой также 3-4 нету и ровный следом, делаешь ребут сервера все прекрастно стает. Звонил вышестоящему тот проверял у них все хорошо. От вышестоящего схема такая медиаконвектор далее мой сервер.

Нафаня

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

leonidq

Выгледит это так (когда тупить инет начинает у всех): запускаем пинг до шлюза в моем случае 80.78.99.18
$ ping 80.78.99.18
PING 80.78.99.18 (80.78.99.18 ): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.78.99.18: icmp_seq=1 ttl=255 time=3.003 ms
64 bytes from 80.78.99.18: icmp_seq=2 ttl=255 time=3.046 ms
64 bytes from 80.78.99.18: icmp_seq=3 ttl=255 time=3.182 ms
Дальше стабильно идут ответы.

Пинг по новой таже картинка.

Помогает ребут сервера- но это невыход. После ребута часов 12 работает нормально (иногда и 6-7 часов и все поновой повторяется)

Схема включения такая медиаконвектор вышестоящего - мой сервер.

Подскажите куда смотреть еще.

kirush · Сообщение **kirush** » Вт ноя 02, 2010 16:53

что говорит:
a) top -SP
b) netstat -w1
в момент тупизны?

ds · Сообщение ds » Вт ноя 02, 2010 18:32

freebsd pf?
Может помочь
# grep limit /etc/pf.conf
set limit states 20000

Думаю ковырять надо в сторону переполнения какого то сетевого буфера

leonidq

kirush писал(а):что говорит:
a) top -SP
b) netstat -w1
в момент тупизны?

top -SP
last pid: 28340; load averages: 1.34, 1.03, 0.95 up 0+02:18:33 20:50:28
429 processes: 9 running, 404 sleeping, 16 waiting
CPU 0: 2.1% user, 0.0% nice, 4.3% system, 0.0% interrupt, 93.6% idle
CPU 1: 4.3% user, 0.0% nice, 21.7% system, 0.0% interrupt, 73.9% idle
CPU 2: 2.2% user, 0.0% nice, 10.9% system, 0.0% interrupt, 87.0% idle
CPU 3: 2.2% user, 0.0% nice, 21.7% system, 0.0% interrupt, 76.1% idle
CPU 4: 2.2% user, 0.0% nice, 19.6% system, 0.0% interrupt, 78.3% idle
CPU 5: 4.3% user, 0.0% nice, 13.0% system, 4.3% interrupt, 78.3% idle
CPU 6: 0.0% user, 0.0% nice, 10.9% system, 2.2% interrupt, 87.0% idle
CPU 7: 0.0% user, 0.0% nice, 8.7% system, 15.2% interrupt, 76.1% idle
Mem: 164M Active, 270M Inact, 157M Wired, 1220K Cache, 112M Buf, 2412M Free
Swap: 4096M Total, 4096M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 1 171 ki31 0K 8K CPU7 7 120:55 97.07% idle: cpu7
12 root 1 171 ki31 0K 8K CPU6 6 121:14 91.36% idle: cpu6
16 root 1 171 ki31 0K 8K CPU2 2 114:48 90.97% idle: cpu2
18 root 1 171 ki31 0K 8K RUN 0 109:47 90.28% idle: cpu0
15 root 1 171 ki31 0K 8K CPU3 3 110:27 86.28% idle: cpu3
13 root 1 171 ki31 0K 8K CPU5 5 120:56 80.47% idle: cpu5
17 root 1 171 ki31 0K 8K CPU1 1 111:45 77.98% idle: cpu1
14 root 1 171 ki31 0K 8K CPU4 4 102:34 72.46% idle: cpu4
30 root 1 -68 - 0K 8K - 4 28:42 22.85% em1 taskq
29 root 1 -68 - 0K 8K - 3 20:52 14.89% em0 taskq
20 root 1 -32 - 0K 8K WAIT 6 31:07 14.26% swi4: clock sio
707 root 1 -68 - 0K 8K sleep 1 8:14 5.76% ng_queue6
704 root 1 -68 - 0K 8K sleep 5 8:16 5.57% ng_queue3
706 root 1 -68 - 0K 8K sleep 0 8:13 5.47% ng_queue5
708 root 1 -68 - 0K 8K sleep 7 8:15 5.37% ng_queue7
702 root 1 -68 - 0K 8K sleep 1 8:14 5.37% ng_queue1
701 root 1 -68 - 0K 8K sleep 5 8:15 5.27% ng_queue0
703 root 1 -68 - 0K 8K sleep 2 8:15 5.08% ng_queue2
705 root 1 -68 - 0K 8K sleep 0 8:14 4.98% ng_queue4
614 bind 11 4 0 109M 92072K kqread 4 0:40 0.78% named
820 mysql 15 4 0 118M 32172K sbwait 0 0:00 0.49% mysqld
22 root 1 -16 - 0K 8K - 2 0:21 0.00% yarrow
367 root 1 8 - 0K 8K pftm 6 0:18 0.00% pfpurge
543 root 1 44 0 3184K 1228K select 1 0:13 0.00% syslogd
916 root 7 44 0 14036K 8028K select 2 0:08 0.00% utm5_radius
878 root 2 44 0 7252K 3604K select 3 0:07 0.00% utm5_rfw
19 root 1 -44 - 0K 8K WAIT 0 0:05 0.00% swi1: net
46 root 1 -8 - 0K 8K - 0 0:02 0.00% fdc0
3 root 1 -8 - 0K 8K - 2 0:01 0.00% g_up

netstat -w1

input (Total) output
packets errs bytes packets errs bytes colls
44614 0 25983279 43415 0 29475079 0
44196 0 25733280 42536 0 29549222 0
43880 0 26437116 40688 0 28840744 0
43735 0 26034923 41725 0 29023839 0
42428 0 25635061 40342 0 28633954 0
41940 0 25209789 39520 0 28177100 0
41095 0 25212296 38200 0 27449366 0
39399 0 24211027 36712 0 26518424 0
40470 0 24550973 37773 0 27232024 0
41974 0 25620912 40107 0 28552442 0
43621 0 26319792 41537 0 28849286 0
44869 0 25796184 43320 0 29057908 0
43356 0 24577985 42436 0 28508799 0
44416 0 25624347 42979 0 29275302 0
43473 0 25568665 40983 0 28242353 0
43698 0 26121081 41997 0 28847112 0
42617 0 25722517 40923 0 28971566 0
42135 0 25629345 40222 0 29147801 0
41526 0 25109648 39592 0 28606378 0
40581 0 24679557 39142 0 28137526 0
input (Total) output
packets errs bytes packets errs bytes colls
42349 0 25783743 40431 0 28731215 0
44177 0 26265143 43221 0 30464970 0
44016 0 26414754 42384 0 29407552 0
44292 0 26374905 42725 0 29671412 0
45235 0 26218316 44182 0 29901437 0
46084 0 27771228 44063 0 30993679 0
43393 0 26081568 41908 0 29229151 0
43850 0 26910519 41688 0 29816734 0
43646 0 26855909 41539 0 29754621 0
42434 0 26335238 40570 0 29463609 0
42910 0 26645095 40413 0 29515841 0
42463 0 26458276 40341 0 29451584 0
42173 0 25783365 40791 0 29244286 0
44316 0 26564353 42306 0 29434788 0
43988 0 26096577 42410 0 29725141 0
43744 0 26729112 41534 0 29838256 0
45564 0 26708876 44625 0 30742518 0
44872 0 26679387 42957 0 30307954 0
45319 0 27640072 43314 0 30927009 0
43813 0 26651429 41623 0 30107533 0
41397 0 25289389 38879 0 28143175 0
input (Total) output
packets errs bytes packets errs bytes colls
41219 0 25486590 39175 0 28757999 0
41726 0 25935712 39737 0 28729652 0
40998 0 24888970 39058 0 28125995 0
41349 0 24862232 40572 0 28469492 0
43811 0 25816414 42578 0 29119851 0
45200 0 26559187 43124 0 29386765 0
45815 0 26651920 44507 0 29701837 0
45886 0 26672713 45002 0 30331287 0
44990 0 26841963 43083 0 29748274 0
44072 0 26503941 42135 0 29476785 0
43210 0 26151194 41103 0 29200198 0
41750 0 25450917 39437 0 28788247 0
41104 0 25115325 40044 0 28658202 0
41704 0 25259273 39796 0 28456181 0
43062 0 26314441 41553 0 30012588 0
43017 0 25905280 41164 0 29077838 0
44869 0 26555790 43617 0 29757396 0
45166 0 26886181 43232 0 30359295 0
45739 0 26300263 44976 0 30013121 0
45034 0 26730161 43523 0 30063689 0
42483 0 25595995 41057 0 28994755 0

kirush · Сообщение **kirush** » Вт ноя 02, 2010 21:12

выходим за рамки netup.ru, на nag.ru неоднократно обсуждалось,
я бы начал с проверки/замены:
а) сетевые
б) патчкорды
в) разъемы
г) оборудование (свитчи/конвертора).

leonidq

ds писал(а):freebsd pf?
Может помочь
# grep limit /etc/pf.conf
set limit states 20000

Думаю ковырять надо в сторону переполнения какого то сетевого буфера

# Options: tune the behavior of pf, default values are given.
set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 5 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 50000, frags 5000 }
set loginterface none
#set optimization normal
set block-policy drop
set require-order yes
set fingerprints "/etc/pf.os"
#set state-policy if-bound

Это на даный момент в конфиге

leonidq

ds писал(а):freebsd pf?
Может помочь
# grep limit /etc/pf.conf
set limit states 20000

Думаю ковырять надо в сторону переполнения какого то сетевого буфера

Выставил вот так
set limit states 80000
Посмотрю отпишусь

leonidq

leonidq писал(а):
ds писал(а):freebsd pf?
Может помочь
# grep limit /etc/pf.conf
set limit states 20000

Думаю ковырять надо в сторону переполнения какого то сетевого буфера
Выставил вот так
set limit states 80000
Посмотрю отпишусь

Все равно начинается тупизна интернета, хотя до её начала уже почти сутки проходят.Сутки полет нормальный, а потом все поновой.
Также пинги как выше написано и все. Стоит ли более выставить? Или в другую сторону смотреть?