• Seedbox

  • [Résolu] Ksoftirqd utilise 100% du CPU quand rtorrent télécharge

Bonjour à tous,

Voilà quelques années que je m'amuse sur un dédié Kimsufi grâce à ce forum (un grand merci à vous 😉). Je suis resté chez Kimsufi mais j'ai changé de serveur il y a peu.
Ma machine ( Serveur KS-7 - Intel i3 2130 - 8Go DDR3 1333 MHZ - 2To) est sous Debian 10 et me sert principalement comme Seedbox (on est deux utilisateurs dessus) et serveur mail. Pour gérer les espaces des utilisateurs j'ai partitionné avec LVM et le serveur est sécurisé grâce au tuto d'ex_rat. Et depuis quelques mois, j'ai repéré un dysfonctionnement.
Si le serveur est allumé depuis un moment, il met du temps à répondre dès qu'il y a un téléchargement en cours sur rtorrent. Si je mets le dl en pause, il repart "à la normale".
J'ai fait un petit top pendant un dl et je vois que ksoftirqd monte en charge et utilise 100% du CPU.

top - 08:59:58 up 19 days, 13:44,  2 users,  load average: 0,90, 0,51, 0,41
Tasks: 166 total,   2 running, 164 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,3 us,  0,6 sy,  0,0 ni, 72,9 id,  1,2 wa,  0,0 hi, 25,1 si,  0,0 st
MiB Mem :   7877,7 total,    143,2 free,    459,8 used,   7274,7 buff/cache
MiB Swap:    512,0 total,    147,2 free,    364,8 used.   7084,4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   22 root      20   0       0      0      0 R 100,0   0,0   1575:48 ksoftirqd/2
30895 guibol    20   0 2219248 108180  33656 S   1,3   1,3   3:05.22 rtorrent main
13840 root      20   0    2308   1608   1488 S   1,0   0,0   2:39.21 portsentry
 1359 www-data  20   0   23088   8536   4404 S   0,3   0,1   6:45.44 nginx
 1474 guibis    20   0  183880  12624  10368 S   0,3   0,2   3:56.01 rtorrent main
    1 root      20   0  171112   8520   6152 S   0,0   0,1   3:11.30 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.43 kthreadd
    3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
    4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
    6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/0:0H-kblockd
    8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
    9 root      20   0       0      0      0 S   0,0   0,0   0:45.13 ksoftirqd/0
   10 root      20   0       0      0      0 I   0,0   0,0  15:31.37 rcu_sched
   11 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_bh
   12 root      rt   0       0      0      0 S   0,0   0,0   0:03.51 migration/0
   14 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
   15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
   16 root      rt   0       0      0      0 S   0,0   0,0   0:03.64 migration/1
   17 root      20   0       0      0      0 S   0,0   0,0   0:47.57 ksoftirqd/1
   19 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/1:0H-kblockd
   20 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/2
   21 root      rt   0       0      0      0 S   0,0   0,0   0:17.52 migration/2
   24 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/2:0H-kblockd
   25 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/3
   26 root      rt   0       0      0      0 S   0,0   0,0   0:03.45 migration/3
   27 root      20   0       0      0      0 S   0,0   0,0   0:37.04 ksoftirqd/3

La commande cat /proc/interrupts me retourne ça :

  0:          7          0          0          0   IO-APIC   2-edge      timer
  8:          1          0          0          0   IO-APIC   8-edge      rtc0
  9:          0          0          0          0   IO-APIC   9-fasteoi   acpi
 16:          0          0          0         25   IO-APIC  16-fasteoi   ehci_hcd:usb1
 18:          0          0          0          0   IO-APIC  18-fasteoi   i801_smbus
 23:          0         31          0          0   IO-APIC  23-fasteoi   ehci_hcd:usb3
 24:          0          0          0          0   PCI-MSI 458752-edge      PCIe PME
 25:          0          0          0          0   PCI-MSI 460800-edge      PCIe PME
 26:          0          0  256807397          0   PCI-MSI 409600-edge      eno1
 27:          0          0          0          0   PCI-MSI 1048576-edge      xhci_hcd
 28:          0          0          0          0   PCI-MSI 1048577-edge      xhci_hcd
 29:          0          0          0          0   PCI-MSI 1048578-edge      xhci_hcd
 30:          0          0          0          0   PCI-MSI 1048579-edge      xhci_hcd
 31:          0          0          0          0   PCI-MSI 1048580-edge      xhci_hcd
 32:          0          0   32809178          0   PCI-MSI 512000-edge      ahci[0000:00:1f.2]
 33:          0          0          0         15   PCI-MSI 360448-edge      mei_me
NMI:       1894       1754      32725       1676   Non-maskable interrupts
LOC:   93230764   85384870  138887705   91576953   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:       1894       1754      32725       1676   Performance monitoring interrupts
IWI:        236        304      76089        316   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:   12725387    6327749    2046477    3274516   Rescheduling interrupts
CAL:     475459     662281     265599     343002   Function call interrupts
TLB:     371900     563731     166826     246112   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
DFR:          0          0          0          0   Deferred Error APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:       5432       5433       5433       5433   Machine check polls
ERR:          0
MIS:          0
PIN:          0          0          0          0   Posted-interrupt notification event
NPI:          0          0          0          0   Nested posted-interrupt event
PIW:          0          0          0          0   Posted-interrupt wakeup event

Et voici le retour de la commande free -m :

                    total        used        free      shared  buff/cache   available
Mem:           7877         495         167          37        7214        7048
Swap:           511         363         148

Si je reboot le serveur, plus de problème...jusqu'à ce que ça revienne au bout de quelques temps, toujours en lien avec les téléchargements sur rtorrent.
Ca fait quelques mois que je cherche une solution mais je dois mal chercher car je ne trouve pas.

Est-ce qu'une âme charitable pourrait venir à mon secours s'il vous plaît ? 🙂
Merci

Super merci pour ta réponse hydrog3n 😉
Effectivement j'ai pu voir en traînant sur les forums ce qu'étaient les interruptions IRQ, mais dans mon cas
je n'arrive pas vraiment à savoir de quoi ça vient exactement et quel est le lien avec rtorrent
Un reboot pourra me solutionner le schmilblick rapidement mais ça m'aidera pas à comprendre

    un an plus tard

    Salut,

    Bon j'ai trouve un truc, j'avais le même soucis (je sais que je réponds a un post vieux de plus d'un an).
    En fait j'avais ce soucis avec fail2ban et Ksoftirqd. Sans fail2ban cela se passait bien, mais j'avais beaucoup d'attaque dans auth.log.
    J'ai trouve cet article, et cela a resolu mon soucis: article

    Peut etre que cela pourra servir a d'autres ...

    A+

      andresayang Super merci d'avoir relancé le post. J'ai toujours ce problème, mais plus ponctuellement. Dès que ce soucis revient j'essaierai la solution 😉

      spider1163 TLDR : faire tourner (logrotate) le fichier auth.log moins souvent (toutes les semaines au lieu de tous les jours)

      C'est pas l'inverse plutôt ? Faire tourner plus régulièrement pour alléger les fichiers de log non ? Ou alors je suis fatigué et je n'ai rien compris 😅

      [edit] je mets le sujet en résolu en attendant de tester ça dès que ça sera possible

          guibol22 a renommé le titre en [Résolu] Ksoftirqd utilise 100% du CPU quand rtorrent télécharge.

          Au temps pour moi, j'en ai profité pour faire tourner mes logs moins souvent et du coup j'ai écrit n'importe quoi ici

          16 jours plus tard

          Bon au final, la solution proposée n'a pas résolu mon problème. Ce matin mon CPU était de nouveau utilisé à 100% avec Ksoftirqd pendant des dl sur rutorrent.
          En recherchant rapidement j'ai vu que ça pouvait venir de la version de curl (7.64.0) installée via apt sur Debian 10 : https://github.com/rakshasa/rtorrent/issues/580
          J'ai donc mis à jour curl et j'ai redémarré le serveur. Je vous redirai si ça vient de ça

          PS : pour ceux qui ont besoin, j'ai suivi ce tuto pour la mise à jour de curl : https://docs.percona.com/percona-xtrabackup/8.0/xbcloud/update-curl-utility.html#update-the-curl-utility-in-debian-10

          guibol22 a renommé le titre en Ksoftirqd utilise 100% du CPU quand rtorrent télécharge.
          6 jours plus tard

          La mise à jour de curl n'a pas suffit, je continue mon investigation 🙂

          9 jours plus tard

          Bon ben à force de bricoler...mon serveur s'est mis en grève et ne voulait plus démarrer. J'en ai profité pour faire une nouvelle install propre sur debian 11. A priori je n'ai plus de soucis donc je vais mettre le sujet en résolu. Merci à tous pour l'aide apportée.
          Pour ceux qui rencontreraient ce souci sous Debian 10, regardez du côté de Curl, ça semble venir de là

          guibol22 a renommé le titre en [Résolu] Ksoftirqd utilise 100% du CPU quand rtorrent télécharge.
          Répondre…