rigacci.org

User Tools

Site Tools

Trace:
doc:appunti:linux:sa:ksoftirqd

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
doc:appunti:linux:sa:ksoftirqd [2024/11/08 16:39] – [ksoftirqd process utilizes 100% of a CPU] niccolodoc:appunti:linux:sa:ksoftirqd [2024/11/08 17:22] (current) – [ksoftirqd process utilizes 100% of a CPU] niccolo
Line 4: Line 4:
  
 <code> <code>
-ps uax | grep ksoftir | grep -v grep+ps uax | grep ksoftirqd | grep -v grep
 root          14  0.0  0.0      0     0 ?        S    Nov07   0:00 [ksoftirqd/0] root          14  0.0  0.0      0     0 ?        S    Nov07   0:00 [ksoftirqd/0]
 root          21  1.4  0.0      0     0 ?        S    Nov07  21:43 [ksoftirqd/1] root          21  1.4  0.0      0     0 ?        S    Nov07  21:43 [ksoftirqd/1]
Line 59: Line 59:
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 </code> </code>
 +
 +===== softnet_stat =====
  
 Grazie al contenuto di **/proc/net/softnet_stat** è possibile avere statistiche sulla gestione da parte delle softirq dei pacchetti network. Ogni riga si riferisce ad un CPU core, le colonne indicano: Grazie al contenuto di **/proc/net/softnet_stat** è possibile avere statistiche sulla gestione da parte delle softirq dei pacchetti network. Ogni riga si riferisce ad un CPU core, le colonne indicano:
Line 75: Line 77:
 awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
 </code> </code>
 +
 +===== netdev_max_backlog =====
  
 Se il numero nella **seconda colonna** cresce costantemente (frame persi a causa di una coda backlog piena), è possibile incrementare la dimensione del buffer. Il valore corrente si vede con: Se il numero nella **seconda colonna** cresce costantemente (frame persi a causa di una coda backlog piena), è possibile incrementare la dimensione del buffer. Il valore corrente si vede con:
  
 <code> <code>
-# sysctl net.core.netdev_max_backlog+sysctl net.core.netdev_max_backlog
 net.core.netdev_max_backlog = 1000 net.core.netdev_max_backlog = 1000
 </code> </code>
Line 95: Line 99:
 </code> </code>
  
-Anche la **terza colonna** se cresce costantemente può indicare un problema. In questo caso significa che il budget dedicato a gestire il traffico ricevuto è esaurito e la softirq viene rischedulata. Il budget assegnato è dato dal parametro **netdev_max_backlog**.+===== netdev_budget ===== 
 + 
 +Anche la **terza colonna** di **/proc/net/softnet_stat**, se cresce costantemente, può indicare un problema. In questo caso significa che il budget dedicato a gestire il traffico ricevuto è esaurito e la softirq viene rischedulata. Si tratta in pratica del numero di volte che un processo softirqd non è riuscito a processare tutti i pacchetti da una interfaccia durante un ciclo di polling NAPI. 
 + 
 +Il budget assegnato è dato dai parametri **netdev_budget** e **netdev_budget_usecs** che sono consultabili con i comandi: 
 + 
 +<code> 
 +sysctl net.core.netdev_budget 
 +net.core.netdev_budget = 300 
 + 
 +sysctl net.core.netdev_budget_usecs 
 +net.core.netdev_budget_usecs = 8000 
 +</code> 
 + 
 +In questo caso softirqd ha, per ogni ciclo di polling, 8000 microsecondi di tempo massimo per processare fino a 300 messaggi dalla scheda di rete. Possiamo aumentarli creando un file **/etc/sysctl.d/10-netdev_budget.conf** con: 
 + 
 +<file> 
 +net.core.netdev_budget = 600 
 +net.core.netdev_budget_usecs = 24000 
 +</file> 
 + 
 +ed eseguendo 
 + 
 +<code> 
 +sysctl -p /etc/sysctl.d/10-netdev_budget.conf 
 +</code> 
 + 
 +===== Shorewall (netfilter) logging ===== 
 + 
 +Purtroppo nel nostro caso **non si sono ottenuti risultati incrementando il budget** per la softirq. L'host in questione è un firewall GNU/Linux con due schede di rete, il problema era associato all'interfaccia di rete esterna, protetta da **regole netfilter** tramite il software **Shorewall**. Il numero di regole complessivamente impostate era assolutamente modesto (157 regole): 
 + 
 +<code> 
 +iptables -S | wc -l 
 +157 
 +</code> 
 + 
 +Il problema si manifestava in condizioni di portscan intensi, intorno ai 3 pacchetti/secondo. In questo caso il logging dei pacchetti dropped (tramite syslog venivano scritti su **/var/log/syslog** e su **/var/log/kern.log**) causava una perdita apprezzabile di pacchetti di rete.
  
 +Avendo **eliminato il logging dei pacchetti dropped** il problema pare risolto.
  
 ===== Web References ===== ===== Web References =====
Line 102: Line 143:
   * **[[https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000LUR3SAO|Linux VM performance: ksofirqd process utilizes 100% of a vCPU ...]]**   * **[[https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000LUR3SAO|Linux VM performance: ksofirqd process utilizes 100% of a vCPU ...]]**
   * **[[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/tuning-the-network-performance_monitoring-and-managing-system-status-and-performance|Tuning the network performance]]**   * **[[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/tuning-the-network-performance_monitoring-and-managing-system-status-and-performance|Tuning the network performance]]**
 +  * **[[https://jsevy.com/network/Linux_network_stack_walkthrough.html|Linux Network Stack Walkthrough]]**
   * **[[https://learn.netdata.cloud/docs/collecting-metrics/linux-systems/network/softnet-statistics|Softnet Statistics]]**   * **[[https://learn.netdata.cloud/docs/collecting-metrics/linux-systems/network/softnet-statistics|Softnet Statistics]]**
  
doc/appunti/linux/sa/ksoftirqd.1731080380.txt.gz · Last modified: by niccolo