Differences

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

--- doc:appunti:linux:sa:ksoftirqd [2024/11/08 16:29] – [ksoftirqd process utilizes 100% of a CPU] niccolo
+++ doc:appunti:linux:sa:ksoftirqd [2024/11/08 17:22] (current) – [ksoftirqd process utilizes 100% of a CPU] niccolo
@@ Line 4: / Line 4: @@
 <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          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
 </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:
@@ Line 75: / Line 77: @@
 awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
 </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:
 <code>
-# sysctl net.core.netdev_max_backlog
+sysctl net.core.netdev_max_backlog
 net.core.netdev_max_backlog = 1000
 </code>
@@ Line 94: / Line 98: @@
 sysctl -p /etc/sysctl.d/10-netdev_max_backlog.conf
 </code>
+===== 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
+</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 =====
@@ Line 99: / Line 143: @@
   * **[[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://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]]**