LINUX.ORG.RU
ФорумAdmin

ksoftirqd жрет процессорное время и создает нагрузку.

 , ,


0

2

Всем привет!

Прошу помощи - не могу разобраться из-за чего ksoftirqd жрет процессорное время и создает нагрузку на CPU.

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
18   root      20   0       0      0      0 S  30,2  0,0 223:48.49 ksoftirqd/2

Железо такое: мать - X7SPE-HF, на ней Atom D525. Он двухядерный, с Hyper-Threading, сеть 2x1000 Мбит/с, на основе Intel 82574L.

Температура в норме:

root@server00:~# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +35.0°C  (crit = +100.0°C)
Core 1:       +36.0°C  (crit = +100.0°C)

Дрова на сеть такие:
root@server00:~# ethtool -i eth0
driver: e1000e
version: 2.3.2-k
firmware-version: 1.9-0
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Сервер выполняет роль маршрутизатора для небольшого офиса (макс 17 хостов), плюс в LXC контейнерах на нем FTP и почта. Сейчас сервер не загружен, но как только они начнут работать опасаюсь возможных проблем.
Контейнеры выключал, демона LXC отключал - все тоже самое.
Все это дело работает на Ubuntu-server 14.04.1, ядро 3.13.0-44.

Кстати, в моем домашнем сервачке (где такая же Ubuntu, и ядро) стоит такая же карточка, только отличается firmware-version, дома оно 2.1-2.

Помогите плиз разобраться в чем может быть причина проблемы.



Последнее исправление: borschov (всего исправлений: 3)

Ты сломал мне глаза. Зачем столько переводов строки в посте? И выхлопы оберни в тег [code].

mandala ★★★★★
()
Последнее исправление: mandala (всего исправлений: 1)

из-за чего ksoftirqd жрет процессорное

А жрёт постоянно, или как ? Попробуй в /proc/interrupts посмотреть, кто что делает.

AS ★★★★★
()

softirq - это обработка данных после обработки прерывания.

Например обработка ip пакетов. смотри какие irq активно используются.

vel ★★★★★
()
Ответ на: комментарий от AS

просветите плиз, как отслеживать? вывод-то не динамический. отслеживать по top, и когда ksoftirqd выходит в top, бежать смотреть /proc/interrupts. я правильно понимаю?

borschov
() автор топика
Ответ на: комментарий от vel

как это отследить? никогда не стакивался...

root@server00:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         48          0          0          0   IO-APIC-edge      timer
  1:          0          0          1          1   IO-APIC-edge      i8042
  8:          1          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          1          1          1          1   IO-APIC-edge      i8042
 16:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:          0          1          0          1   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb8
 19:      49092      23959      46867      20895   IO-APIC-fasteoi   ata_piix, ata_piix, uhci_hcd:usb5, uhci_hcd:usb7
 21:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:         12         13         14         13   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
 40:          0          0          0          0   PCI-MSI-edge      PCIe PME, pciehp
 41:          0          0          0          0   PCI-MSI-edge      PCIe PME, pciehp
 42:          0          0          0          0   PCI-MSI-edge      PCIe PME, pciehp
 43:          3         13     680132          1   PCI-MSI-edge      eth0-rx-0
 44:     650441          1          0          0   PCI-MSI-edge      eth0-tx-0
 45:          1          0          0          1   PCI-MSI-edge      eth0
 46:     148458     106017     234671     161186   PCI-MSI-edge      eth1-rx-0
 47:     222816      66706      33554      41881   PCI-MSI-edge      eth1-tx-0
 48:          0          1          1          2   PCI-MSI-edge      eth1
NMI:        341       5470        209        185   Non-maskable interrupts
LOC:    1102840    5719155     757802     811695   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:        341       5470        209        185   Performance monitoring interrupts
IWI:      90580     455449     148050      40438   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:     807835     135878     137630      32832   Rescheduling interrupts
CAL:       3586      32273       1562      29814   Function call interrupts
TLB:       7450       1419       3426      16007   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:        623        623        623        623   Machine check polls
ERR:          0
MIS:          0
borschov
() автор топика
Ответ на: комментарий от borschov

просветите плиз, как отслеживать ?

В общем-то, надо просто найти наибольшее число и посмотреть, как быстро оно растёт. top не особенно нужен, смысл-то выяснить, что чаще всего прерывания дёргает, и какие. Может быть, это что-то даст. Вообще, есть такая штука - irqtop. Это скрипт на руби, лежит вот тут: http://sourceforge.net/projects/ipt-netflow/. К ipt-netflow прямого отношения не имеет, можно просто вытащить скрипт из тарбола.

AS ★★★★★
()
Ответ на: комментарий от borschov

абсолютные значения ничего не говорят. Нужно получить число прерываний в секунду. Например «mpstat -I ALL 5»

vel ★★★★★
()
Ответ на: комментарий от borschov
 43:          3         13     680132          1   PCI-MSI-edge      eth0-rx-0
 44:     650441          1          0          0   PCI-MSI-edge      eth0-tx-0
 46:     148458     106017     234671     161186   PCI-MSI-edge      eth1-rx-0
 47:     222816      66706      33554      41881   PCI-MSI-edge      eth1-tx-0

это вот за какое время и в какой момент набежало ?

AS ★★★★★
()
Ответ на: комментарий от AS
root@server00:~# uptime
 16:08:04 up 2 days,  4:11,  2 users,  load average: 0,07, 0,11, 0,13

все это время сервер по сути простаивает. за все время работы, конкретный момент не назвать.

borschov
() автор топика
Ответ на: комментарий от borschov

найти колонку с максимальным числом прерываний.

Но IMHO у тебя нет проблемы. 2 суток uptime это 2880 минут, а ksoftirqd сожрал 223 минуты - это меньше 10%.

сожрала скорее всего сеть:

ksoftirqd/2 - это ядро 2, посмотри от кого на нем больше всего прерываний (eth0-rx-0,eth1-rx-0,local timer)

для Atom-D525 - это нормально.

vel ★★★★★
()
Ответ на: комментарий от vel

штатный mpstat

Ладно ?

зачем нужны поделки на руби

Согласен, что руби, в некотором роде, перебор, но вывод информативнее - раз, по теме - два: mpstat ведь не даёт раскладку на тему, кто именно ест ?

Как-то вот так:

              CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7
  cpuUtil:     1.2    0.2   10.8    0.2    2.4    3.1    8.7    9.1   total CPU utilization %
 irqTotal:      29     26  10208    707   3471   4069   9256   8141   total hardware IRQs
i       4:       0      0      0      0      0      0      0      0   IO-APIC-edge      serial
i      16:       .      .      .      1      .      .      .      .   IO-APIC-fasteoi   ehci_hcd:usb2,
i      56:       .      .      .      2      .      .      .      .   PCI-MSI-edge      ahci
i      57:       .      .   1561      .      .      .      .      .   PCI-MSI-edge      eth7
i      58:       0      0      0      0      0      0      0      0   PCI-MSI-edge      eth0
i      59:       .      .      .      .      .      .      .   1488   PCI-MSI-edge      eth0-TxRx-0
i      60:       .      .      .      .      .      .      .   1649   PCI-MSI-edge      eth0-TxRx-1
i      61:       .      .      .      .      .      .      .   1649   PCI-MSI-edge      eth0-TxRx-2
i      62:       .      .      .      .      .      .      .   1570   PCI-MSI-edge      eth0-TxRx-3
i      63:       .      .      .      .      .      .   1766      .   PCI-MSI-edge      eth0-TxRx-4

AS ★★★★★
()
Ответ на: комментарий от borschov

конкретный момент не назвать.

Ещё вариант, кстати, поставить collectd. Через какое-то время статистика наберётся. Плагин irq там ещё довключить: по-умолчанию отключен, как правило. Плюс нужная информация будет о пакетах в секунду, летающих через eth. Если предполагать, что это из-за трафика, то знать pps полезно. Опять же, можно смотреть зависимость между параметрами.

AS ★★★★★
()
Ответ на: комментарий от vel

посмотреть где, в /proc/interrupts?

вот вывод mpstat

Среднее:  CPU       HI/s    TIMER/s   NET_TX/s   NET_RX/s    BLOCK/s BLOCK_IOPOLL/s  TASKLET/s    SCHED/s  HRTIMER/s      RCU/s
Среднее:    0       0,00       2,16       4,04       1,76       0,09       0,00       0,00       6,33       0,00       1,23
Среднее:    1       0,00       9,68       0,00       0,75       0,23       0,00       0,00       4,97       0,01      11,41
Среднее:    2       0,00       1,97       0,00       1,58       0,09       0,00       0,00       1,35       0,01       1,24
Среднее:    3       0,00       3,15       0,29       0,00       0,10       0,00       0,00       2,71       0,00       1,73
root@server00:~#
куда тут смотреть?

borschov
() автор топика
Ответ на: комментарий от vel

Atom 525 64-битный процессор, а Ubuntu установлена с архитектурой i686. Как вы считаете, это может вносить коррективы?

borschov
() автор топика
Ответ на: комментарий от borschov

на тех задачах которые описаны в начале треда - разницу между 32/64 битами найти трудно.

Если нет задач нуждающихся в более 3Гб памяти, то от 64 бит пользы нет.

vel ★★★★★
()
Ответ на: комментарий от borschov

куда тут смотреть ?

Тут бы должен ksoftirqd/1 трудиться, а не 2. В общем, наверное, ставь collectd. Посмотришь по графикам, что происходит одновременно с ростом нагрузки. Да и на будущее это будет полезно.

AS ★★★★★
()
Ответ на: комментарий от borschov

заморочиться с разнесением прерываний по ядрам ?

Да, только, это уже кто-то сделал, похоже. Сервис irqbalance запущен ?

AS ★★★★★
()
Ответ на: комментарий от AS

да запущен. я кстати совсем про него забыл, и попробовал сделать по этой статье), но понятное дело, желаемого результата нет.

borschov
() автор топика
Ответ на: комментарий от AS

collectd c web-панелью поставил (крутая штука, ничего не скажешь, до этого везде юзал MRTG), но ничего подозрительного не нахожу. CPU1 всегда загружен сильнее остальных ядер. я в топике писал, про firmware-version на е1000е, не могу разобраться возможно ли его обновить. на sourseforge выложены более новые версии драйверов на e1000e, но не рискую обновлять т.к. хожу на сервер удаленно. может действительно попробовать «раскидать» прерывания по ядрам.

borschov
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.