Differences

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

--- doc:appunti:linux:sa:ksoftirqd [2024/11/08 14:59] – [Web References] 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 45: / Line 45: @@
 Dove **f** un valore esadecimale che rappresenta una bitmask dei core CPU; tale IRQ può essere quindi servita da uno qualunque dei core.
+Dall'elenco delle interrupt si deduce che probabilmente vi è una situazione critica relativamente all'interfaccia **net0**, abbiamo una conferma constatando il gran numero di pacchetti **dropped**:
+<code>
+ifconfig net0
+net0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
+        inet 192.168.1.254  netmask 255.255.255.0  broadcast 192.168.1.255
+        inet6 fe80::2e0:4cff:fe60:11e4  prefixlen 64  scopeid 0x20<link>
+        ether 00:e0:4c:60:11:e4  txqueuelen 1000  (Ethernet)
+        RX packets 3943557  bytes 3439040842 (3.2 GiB)
+        RX errors 0  dropped 107001  overruns 0  frame 0
+        TX packets 2410528  bytes 714236244 (681.1 MiB)
+        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:
+  - Total number of processed packets (processed).
+  - Times ksoftirq ran out of quota (dropped).
+  - Times net_rx_action was rescheduled.
+  - Number of times processed all lists before quota.
+  - Number of times did not process all lists due to quota.
+  - Number of times net_rx_action was rescheduled for GRO (Generic Receive Offload) cells.
+  - Number of times GRO cells were processed.
+Per vedere la tabella in formato decimale invece che esadecimale si può ricorrere al comando:
+<code>
+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
+net.core.netdev_max_backlog = 1000
+</code>
+Quindi si può creare un file **/etc/sysctl.d/10-netdev_max_backlog.conf** con il seguente contenuto
+<file>
+net.core.netdev_max_backlog = 2000
+</file>
+e renderlo esecutivo con:
+<code>
+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 =====
-  * **[[https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000LUR3SAO|Linux VM performance troubleshooting scenario - ksofirqd process utilizes 100% of a vCPU in Linux VM due to a high number of iptables rules]]**
+  * **[[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]]**