поиск программ ядра

как мы можем определить % sy процесс, потребляющий CPU.

В следующем случае нет сетевого фильтра и трафик ниже 1 Мбит / с. Но все же системный процесс использует слишком много ЦП, и использование ЦП для процесса с ограниченным доступом также велико. Как мы можем определить процесс, потребляющий ЦП на системном уровне.

top - 01:22:18 up  10:09,  3 users,  load average: 14.36, 13.68, 11.68
Tasks: 200 total,   3 running, 197 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.1%us, 63.5%sy, 33.3%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  1.8%us, 34.2%sy, 64.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16436984k total,  8449956k used,  7987028k free,    73420k buffers
Swap:  8385920k total,        0k used,  8385920k free,  5566404k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
5706 tlmsys    27   4 4490m 1.6g  13m S 51.6 10.2  12:37.67 java
4233 oracle    25   0 3448m  47m  33m R  9.9  0.3   0:03.62 oracle
3166 root      15   0 62616 1216  656 S  0.7  0.0   0:01.47 sshd
5512 tlmsys    15   0 96992  12m 9424 S  0.7  0.1   0:04.03 stlfetch
5520 oracle    15   0 3424m  72m  69m S  0.7  0.5   0:08.42 oracle
6 root      10  -5     0    0    0 S  0.3  0.0   0:01.59 events/0
4476 monitor   15   0 90116 1764 1008 S  0.3  0.0   0:00.61 sshd
5872 tlmsys    25   4 4479m 135m  11m S  0.3  0.8   0:25.72 java
7139 oracle    16   0 12740 1180  824 S  0.3  0.0   0:06.76 top
9268 root      16   0 12740 1180  816 S  0.3  0.0   0:02.80 top
9978 root      15   0 12740 1176  820 R  0.3  0.0   0:00.07 top
1 root      15   0 10348  696  584 S  0.0  0.0   0:00.79 init
2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.02 migration/0
3 root      34  19     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/0
4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.01 migration/1
5 root      34  19     0    0    0 R  0.0  0.0   0:00.00 ksoftirqd/1
7 root      10  -5     0    0    0 S  0.0  0.0   0:00.16 events/1
8 root      10  -5     0    0    0 S  0.0  0.0   0:00.09 khelper
145 root      12  -5     0    0    0 S  0.0  0.0   0:00.03 kthread
150 root      10  -5     0    0    0 S  0.0  0.0   0:00.15 kblockd/0
151 root      10  -5     0    0    0 S  0.0  0.0   0:00.03 kblockd/1
152 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
311 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 cqueue/0
312 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 cqueue/1
315 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
317 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
389 root      18   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
390 root      15   0     0    0    0 S  0.0  0.0   0:00.78 pdflush
391 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 kswapd0
392 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
393 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 aio/1
599 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 kpsmoused
645 root      10  -5     0    0    0 S  0.0  0.0   0:00.01 mpt_poll_0

ясно, что java занимает 51,6% процессора и oracle 9.9, поэтому, даже если все процессоры процесса объединены, его уровень ниже 100%, а средняя загрузка должна быть меньше 2,

но почему средняя загрузка 14.

Как мы можем увидеть процесс ядра (% sy), который использует высокий процессор.

uname -a

Linux 2.6.18-155.el5 (todbase1)

если это ошибка ядра. Разве мы не видим процесс со стороны системы.

% sy указывает время, затраченное на процессы ядра (на самом деле потоки ядра), и на те части ядра, которые не являются процессами. Процессы ядра обычно отображаются вверху (ksoftirqd/0 является одним). Если вы выполняете сортировку по мгновенному использованию ЦП, и это процесс ядра, вносящий вклад в% sy, этот процесс будет отображаться. Однако, если это не процесс ядра, а ядро, которое выполняется, top не предоставит никакой информации.

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

С более новым ядром вы можете использовать perf top, а в redhat 5.X, если вы хотите посмотреть глубже, вы можете использовать systemtap, будьте осторожны с systemtap в живой производственной системе, потому что он работает в пространстве ядра.

Для системного времени есть два основных кандидата на ввод-вывод:

Сеть - но у вас мало буферов
Disk-IO - обычно вы тоже должны увидеть wait - здесь не так
второстепенным кандидатом может быть пропускная способность ОЗУ (сборка мусора java?)

Что меня немного озадачивает, так это твой кайф отлично стоимость.

Возможно cat /proc/interrupts предоставит вам больше информации здесь.

Я склонен говорить, что у вас проблемы с сетью.

Итак, добавьте вывод ethtool -S IFACE |grep -vw 0, слишком. Замените IFACE именем вашей основной сетевой карты.