Ядро выжирает весь проц

[h1vs2]

Добрый день!
На сервер только биллинг, запущен nodeny.pl


72717 root      103  -15  1094M   940M CPU1   1 445.5H 100.00% perl5.10.1

Выжирает одно ядро и все на этом.
FreeBSD stats.under.net.ua 7.2-RELEASE FreeBSD 7.2-RELEASE
Nodeny 50.16
В чем может быть проблема?
Спасибо.

[goletsa]

Добрый день!
На сервер только биллинг, запущен nodeny.pl


72717 root      103  -15  1094M   940M CPU1   1 445.5H 100.00% perl5.10.1

Выжирает одно ядро и все на этом.
FreeBSD stats.under.net.ua 7.2-RELEASE FreeBSD 7.2-RELEASE
Nodeny 50.16
В чем может быть проблема?
Спасибо.

А конфигурация железа и объем трафика который ходит\считается?

[h1vs2]

Добрый день!
На сервер только биллинг, запущен nodeny.pl


72717 root      103  -15  1094M   940M CPU1   1 445.5H 100.00% perl5.10.1

Выжирает одно ядро и все на этом.
FreeBSD stats.under.net.ua 7.2-RELEASE FreeBSD 7.2-RELEASE
Nodeny 50.16
В чем может быть проблема?
Спасибо.

А конфигурация железа и объем трафика который ходит\считается?

sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: i386
hw.model: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz
hw.ncpu: 4
hw.machine_arch: i386
1500 мб оперативки свободно
в пиках 1.5 Гбит считается

[goletsa]

Добрый день!
На сервер только биллинг, запущен nodeny.pl


72717 root      103  -15  1094M   940M CPU1   1 445.5H 100.00% perl5.10.1

Выжирает одно ядро и все на этом.
FreeBSD stats.under.net.ua 7.2-RELEASE FreeBSD 7.2-RELEASE
Nodeny 50.16
В чем может быть проблема?
Спасибо.

А конфигурация железа и объем трафика который ходит\считается?

sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: i386
hw.model: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz
hw.ncpu: 4
hw.machine_arch: i386
1500 мб оперативки свободно
в пиках 1.5 Гбит считается

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

[h1vs2]

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

Я наверно не правильно выразился, понятно что именно подсчет съедает, но без него то никак.
Меня интересует так сказать, как побороть, ведь сжирает только одно ядро процессора, возможно ли как-то распараллелить?
На этом сервере ядро биллинга, база и вебка.

[vitaliych]

cpuset?
http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=1&manpath=FreeBSD+7.2-RELEASE&format=html

[h1vs2]

cpuset?
http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=1&manpath=FreeBSD+7.2-RELEASE&format=html

Нет )

[Efendy]

Сделать и/или:

• увеличить период обсчета трафика (настройки нодени)
• в ipcad (если он коллектор трафика) включить агрегацию некоторых адресов, по которым не нужна детализация, например, все адреса, попадающие в 192.168.0.0/16 агрегировать в 192.168.0.0, что обеспечит защиту от сканирования подсети, вернее последствия от сканирования
• включить полную агрегацию всего трафика в 0.0.0.0, кроме адресов клиентов, естественно детализация трафика не будет работать
• отключить запись детализированной статистики
• блокировать клиентов при достижении определенного количества потоков. Надо понимать, что проблема-то не в объемах трафика, а в количестве потоков, которые ядро переваривает. Потоки в основном формируют вирусы  и сейчас чаще торренты. "У торрентов количество потоков настраиваемо" говорим клиентам, которых постоянно будет блочить, ессно работает на на всех истеричек "за шо я бабло плачу?"

[Efendy]

И приведите статистику сколько в сумме потоков и объем трафика в срез.

[h1vs2]

Добрый день ещё раз.

Увеличил время записи трафика, убрал обсчет направлений на UA-IX, забыли убрать, он не нужен.

Сейчас :

Код:

Статистика отображаемого среза трафика: 19:56
Количество обработанных строк
от коллекторов трафика	892082	 
Время обсчета направлений	25.3	сек
Время добавления трафика
к текущим значениям в базе данных	1.6	сек
Время получения данных трафика
для передачи клиентам	0.3	сек
Записей в кеше адресов обсчета направлений	910742	 
gw4_kernel ipcad	xx.xx.xx.xx
65 122 152	байт
Время отключения абонентов превысивших лимиты	0.0	сек
Записан детельный трафик на	100.0	%
Время записи детализации трафика	38.2	сек

last pid: 28645;  load averages:  0.77,  0.61,  0.53                                                                                                                                  up 15+01:37:46  20:00:23
113 processes: 6 running, 94 sleeping, 1 zombie, 12 waiting
CPU 0:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
CPU 1:  6.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 93.2% idle
CPU 2:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU 3:  0.4% user,  0.0% nice,  0.0% system,  0.4% interrupt, 99.2% idle
Mem: 765M Active, 2090M Inact, 148M Wired, 45M Cache, 112M Buf, 429M Free
Swap: 5900M Total, 12K Used, 5900M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root         1 171 ki31     0K     8K CPU3   3 338.8H 84.28% idle: cpu3
   14 root         1 171 ki31     0K     8K RUN    0 273.1H 75.68% idle: cpu0
   13 root         1 171 ki31     0K     8K CPU1   1 292.8H 68.80% idle: cpu1
   12 root         1 171 ki31     0K     8K RUN    2 316.5H 61.87% idle: cpu2
20338 root         1  93  -15   444M   365M CPU2   2  93.7H 56.69% perl5.10.1
  858 mysql       28  45    0   494M   459M ucond  1   0:00  6.35% mysqld

Но все равно переодически ужасно тупит админка. Да и сам сервер по ssh. Где узкое место, винты? Что посоветуете, тех. поддержка жалуется...

[versus]

Поставьте мониторнг, что то типа какти, посмотрите что происходит на сервере когда "ужасно тупит админка", в том числе статистику по iostat. 
И половину вопросов исчезнет.

[goletsa]

Да лучше наверна collectd локально поставить, там больше сенсоров. Там правда зависимостей ппц сколько.

[VitalVas]

я остановился на munin....

[Efendy]

Попробуй запустить ядро нодени с меньшим приоритетом, по умолчанию -15  (самый высокий), поставь 0 или плюсовое значение. "Тупит админка" - это понятие растяжимое. Мот там mysql долго sql запросы выполняет. В личных настройках своей учетной записи _администратора_ поставь галку на "показывать отладочную информацию" - появится кнопка debug - когда будет тупить нажми на нее и посмотри что сколько времени выполнялось.

И, вообще, "ядро выжирает весь проц" - это не проблема, оно жрет все свободные ресурсы, которые ей даются, это же хорошо, что вычислительные мощности утилизируются на 100%. Другой вопрос чтобы оно не забирало у других процессов эти мощности, но я уверен, что не забирает - это по опыту

[versus]

  load averages:  0.77,  0.61,  0.53   

Тут видно что не забирает у других. Вобще машинка не нагруженная стоит.