URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 94861
[ Назад ]

Исходное сообщение
"FreeBSD странности в top"

Отправлено Dimon , 23-Июл-13 18:07 
В списке процессов:
31.49% kernel{em0 ...)
18.65% kernel{em1 ...)

в шапке:
36.2% system
46.8% system

в списке процессов:
77.39% idle{idle ...)
71.29% idle{idle ...)

в шапке:
61.7% idle
51.1% idle

то есть, в шапке примерно 30% "воруют" у idle в пользу system.
Нагрузка более-менее стабильна, цифры немного гуляют, но разница стабильно около 30% на 9.1 (две двухядерные машины), на 8.3 (одна машина 4 ядра) около 20%.
Живет там роутинг, терминация VLAN и PPPoE, NAT от pf, ipfw/dummynet, мосты/шейперы VLAN-ов на netgraph.
Что это?

# top -SPH
или
# top -CSPH

last pid: 44536;  load averages:  0.78,  0.69,  0.71    up 0+20:41:15  16:51:26
366 processes: 3 running, 349 sleeping, 14 waiting
CPU 0:  2.1% user,  0.0% nice, 36.2% system,  0.0% interrupt, 61.7% idle
CPU 1:  2.1% user,  0.0% nice, 46.8% system,  0.0% interrupt, 51.1% idle
Mem: 412M Active, 824M Inact, 278M Wired, 112M Buf, 476M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root          155 ki31     0K    16K CPU0    0 838:44 77.39% idle{idle: c
   11 root          155 ki31     0K    16K RUN     1 736:20 71.29% idle{idle: c
    0 root          -92    0     0K   112K -       1 330:08 31.49% kernel{em0 q
    0 root          -92    0     0K   112K -       0 227:49 18.65% kernel{em1 q
3223 clamav         20    0   261M   224M uwait   0   0:00  0.29% clamd{clamd}
2835 bind           20    0   123M   105M uwait   0   5:15  0.20% named{named}
2835 bind           20    0   123M   105M uwait   0   5:14  0.20% named{named}
3991 root           20   -1 10956K  2844K select  1   3:10  0.20% vtund
    0 root          -92    0     0K   112K -       0 225:14  0.10% kernel{dummy
44507 root           20    0  9780K  2888K CPU0    0   0:00  0.10% top
   12 root          -60    -     0K   112K WAIT    0   8:53  0.00% intr{swi4: c
   12 root          -92    -     0K   112K WAIT    0   4:27  0.00% intr{irq258:
   15 root          -16    -     0K     8K -       1   3:03  0.00% yarrow
3223 clamav         20    0   261M   224M select  1   2:01  0.00% clamd{clamd}
2835 bind           20    0   123M   105M kqread  0   1:39  0.00% named{named}
   13 root          -16    -     0K    16K sleep   1   1:16  0.00% ng_queue{ng_


Содержание

Сообщения в этом обсуждении
"FreeBSD странности в top"
Отправлено urgordeadbeef , 27-Июл-13 15:15 
>[оверквотинг удален]
> в шапке:
> 61.7% idle
> 51.1% idle
> то есть, в шапке примерно 30% "воруют" у idle в пользу system.
> Нагрузка более-менее стабильна, цифры немного гуляют, но разница стабильно около 30% на
> 9.1 (две двухядерные машины), на 8.3 (одна машина 4 ядра) около
> 20%.
> Живет там роутинг, терминация VLAN и PPPoE, NAT от pf, ipfw/dummynet, мосты/шейперы
> VLAN-ов на netgraph.
> Что это?

Ты сравниваешь разные значения (WCPU vs CPU). И не верю, что у тебя top -C показывает тоже самое, что и top.
WCPU это кумулятивная статистика за всё время жизни процесса, экспонента от потребления проца(мгновенное значение) и времени жизни(монотонно растущее).
К тому же в случае с sched_ule аккаунтинг не очень точен, если процентное соотношение времени работы процесса к времени простоя больше заданного значения интерактивности в самом шедулере (процесс двигается между очередями без обновления статистики).
Если же у тебя совсем нерелевантные значения, значит статклок криво работает, возможно надо поменять timecounter.


"FreeBSD странности в top"
Отправлено Dimon , 28-Июл-13 16:56 
# top -CSPH

last pid: 95732;  load averages:  0.35,  0.37,  0.36    up 0+16:07:31  15:50:52
291 processes: 5 running, 272 sleeping, 14 waiting
CPU 0:  0.0% user,  0.0% nice, 21.4% system,  0.9% interrupt, 77.7% idle
CPU 1:  0.0% user,  0.0% nice, 29.5% system,  0.0% interrupt, 70.5% idle
Mem: 356M Active, 830M Inact, 285M Wired, 112M Buf, 519M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   11 root          155 ki31     0K    16K RUN     0 796:16 87.50% idle{idle: c
   11 root          155 ki31     0K    16K CPU1    1 749:43 82.57% idle{idle: c
    0 root          -92    0     0K   112K CPU1    1 106:23 15.77% kernel{em0 q
    0 root          -92    0     0K   112K -       1 100:28 11.28% kernel{em1 q

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


"FreeBSD странности в top"
Отправлено urgordeadbeef , 28-Июл-13 19:05 
> Сейчас нагрузка поменьше, но картина аналогична, в шапке показана намного большая загрузка,
> idle в шапке и списке нитей сильно несовпадают.

С sched_ule скорее всего и не совпадёт.
Можно попробовать повыставлять kern.timecounter.hardware в HPET/TSC(если ядра синхронизированный TSC имеют) или kern.sched.interact=0.
Опять же, в зависимости от того, во что выставлено machdep.idle.
acpi idle вкупе с acpi таймером самые тормозные.
Судя по топу, у тебя больше толку будет от TSC + spin. Ну и в зависимости от нагрузки возможно надо выключить kern.sched.steal_idle - когда при специфической нагрузке sched_idletd начинает поедать проц (хорошо видно через pmcstat).


"FreeBSD странности в top"
Отправлено Dimon , 08-Авг-13 14:18 
Не хочу крутить цапы только из за неверных показаний.
Кому верить скажите, который idle ближе к правде?

Если память - узкое место, проц при ожидании данных из памяти будет "загружен"?
Сменили Pentium D 3,0 на Core2 Duo 3,33, чипс 965-й, планка памяти одна, проц разгрузился раза в 1,5. Теперь думаю как бы проверить, насколько там будет полезен дуал, только эксперимент?


"FreeBSD странности в top"
Отправлено urgordeadbeef , 12-Авг-13 00:07 
> Не хочу крутить цапы только из за неверных показаний.
> Кому верить скажите, который idle ближе к правде?

idle-процессы в топе - это обычные процессы, которые проц выполняет при полном простое. Метод отработки можно выбрать через machdep.idle. Но если переход из режима простоя не мгновенный и выполняется не сразу (кривая реализация acpi, рассинхронизация TSC на разных ядрах, например), то с течением времени погрешность будет нарастать. Важно понимать, что это не остаток от непотреблённого проца.

> Если память - узкое место, проц при ожидании данных из памяти будет
> "загружен"?
> Сменили Pentium D 3,0 на Core2 Duo 3,33, чипс 965-й, планка памяти
> одна, проц разгрузился раза в 1,5. Теперь думаю как бы проверить,
> насколько там будет полезен дуал, только эксперимент?

Если есть узкое место (не процессор), в ядре будет lock contention, выражаемый в повышенной нагрузке на system в топ (из-за адаптивных блокировок). Место легко узнать с помощью pmcstat.