Perché kswapd0 è in esecuzione su un computer senza scambio?

Ho un server cloud con ~ 14G di RAM e nessuno scambio. Tuttavia, ogni tanto vedo kswapd0 occupare un po 'di CPU quando corro top. Perché kswapd0 sarebbe in esecuzione se non ci fosse spazio di swap per gestirlo?

Ha ancora un processo per verificare se c'è qualche scambio. Per ridurlo, devi impostare la tua swappiness -

modifica "/etc/sysctl.conf" come root, quindi modifica (o aggiungi)

vm.swappiness = 0

Lo spazio di scambio viene utilizzato solo per i dati non supportati da nessun altro file. I dati mappati da altri file su disco (come programmi eseguibili) vengono comunque scambiati con i rispettivi file anche se non si dispone di un dispositivo di scambio.

È un problema ben noto che quando Linux esaurisce la memoria, può entrare in cicli di scambio invece di fare ciò che dovrebbe fare, uccidendo i processi per liberare ram. Esiste un killer OOM (memoria esaurita) che lo fa, ma solo se Swap e RAM sono pieni.

Tuttavia, questo non dovrebbe essere davvero un problema. Se ci sono un sacco di processi offensivi, ad esempio Firefox e Chrome, ognuno con schede che utilizzano e catturano la memoria, questi processi causeranno la rilettura dello swap. Linux entra quindi in un ciclo in cui la stessa memoria viene spostata avanti e indietro tra memoria e disco rigido. Questo a sua volta causa un'inversione di priorità in cui lo scambio di alcuni processi avanti e indietro rende il sistema non rispondente.

Se disabiliti lo scambio, peggiori questo problema poiché kswapd0 ora non ha altra opzione che scambiare la memoria mappata come gli eseguibili. Se si sostituiscono gli eseguibili, è ancora più probabile che vengano scambiati di nuovo abbastanza rapidamente.

Ho provato a innescare questo comportamento in NetBSD per i test e quello che è successo lì è che il processo offensivo è diventato incredibilmente lento mentre il sistema operativo stesso era molto reattivo. Ciò significa che si verifica il problema di scambio ma non vi è inversione di priorità. Tuttavia NetBSD non ha i driver AMDGPU, quindi per il momento mi attengo a Linux. Forse NetBSD non memorizza la mappa degli eseguibili ed è per questo che non inserisce i cicli di scambio, ma non so davvero abbastanza sulla sua implementazione per dire perché non risponde.

Anche Facebook ha avuto questo problema e ha creato l'OOMD che è il demone Out Of Memory. Questo è un demone che rileva l'attività di kswapd0 e avvia i processi di uccisione. E secondo Facebook questo ha quasi completamente rimosso il problema dei server Linux che non rispondono. Tuttavia non l'ho testato e non so quanto funzionerà su altri server o desktop / laptop. In modo attraente OOMD ha una logica che decide quali processi uccidere per primi al fine di preservare i processi di sistema e la parte del loro sistema server che sono responsabili del riavvio di qualunque cosa sia stata uccisa.

Tuttavia, non è così che dovrebbe essere risolto. OOMD è un brutto hack. La vera soluzione è correggere l'inversione di priorità causata da un ciclo di scambio e rendere il kernel OOM Killer più aggressivo nell'uccidere i processi per liberare memoria. La correzione appartiene al kernel perché è l'unico posto in cui possiamo essere sicuri che il problema venga rilevato in tempo e che i processi vengano eliminati correttamente.

L'impostazione di swappiness = 0 non è una soluzione perché quando il sistema ha esaurito la RAM libera inizia a scambiare, non importa quale. Non ci sono opzioni per garantire che il sistema non inizi a scambiare.

E anche riparare le applicazioni offensive non è una soluzione. Soprattutto se un utente vuole sfruttare questo bug per rendere il sistema operativo non reattivo. Essere reattivi è la responsabilità del kernel. Se Firefox non risponde, la correzione è per l'applicazione. Tuttavia non si sta solo rendendo non rispondente, ma sta rendendo l'intero sistema operativo molto lento e non rispondente. Al livello che può richiedere mezz'ora per accedere a SSH. L'SSH non ha nulla a che fare con e se non riesce a funzionare è un bug nel kernel, non in qualsiasi altra parte del sistema. E non è un bug, sono due bug. Un bug è l'inversione di priorità in cui un ciclo di scambio off the rails può interferire con altri processi oltre ai processi offensivi e ciò di per sé è negativo. L'altro bug è che non t rilevare che si trova in un loop di swap e che causa un'usura folle sull'HDD / SSD o su qualsiasi memoria che supporti lo swap. Quando si scambia il file eseguibile, questo è meno un problema in quanto vengono letti solo mappe di memoria che non vengono riscritte sui dischi, ma kswapd0 viene comunque bloccato leggendo ciò che allo stesso tempo vengono eliminati dalla memoria.

Oh e c'è un terzo bug. Il fatto che non ci sia modo di proteggere il disco CACHE dall'essere mangiato quando le applicazioni affamate di memoria inghiottono tutta la memoria disponibile. Questo è uno dei motivi per cui kswapd0 non risponde al sistema. I dati mappati con la memoria più calda sono generalmente memorizzati nella cache del disco ma quando firefox ha consumato quella cache, ovviamente significa che dovranno avvenire le letture del disco.

Non è necessariamente Firefox a causare il tuo problema, ma è il browser predefinito, non Chrome. Ed entrambi sono ampiamente noti per innescare questo problema poiché trattano la memoria disponibile come qualcosa che viene sprecata, inclusa la cache e la memoria di swap che in Linux conta come "memoria disponibile". Quindi, per non ottenere "memoria disponibile", va sprecato, usalo per la memorizzazione nella cache e altre cose. Ovviamente l'utilizzo di SWAP per DISK CACHE è un'IDEA MOLTO MALE ma i colleghi di Firefox e Chrome rispondono a quello con "la memoria libera è memoria sprecata".

Quindi quello che abbiamo qui sono tre bug del kernel che il team del kernel non sembra prendere in considerazione i bug. E un bug in Firefox, Chrome e tutti i derivati ​​che non considerano un bug. Ho provato a costruire Firefox sul mio laptop Fedora per esaminare questo problema e forse correggerlo. Indovina un po. La creazione di Firefox con GCC su una CPU a 4 core con ram da 4 GB attiva un LOOP SWAP con INVERSIONE PRIORITARIA. Quindi una delle applicazioni che deve essere riscritta è GCC. Su NetBSD ciò che accade è che solo le 4 istanze in esecuzione di GCC diventano più lente dell'esecuzione di un'istanza ma non congela il sistema.

Sì, questo è un po 'strano, ma spero che chiarisca l'attuale problema con i sottosistemi di memoria di Linux e le applicazioni che lo causano.

Se non hai swap ed kswapd0è in esecuzione, il tuo sistema sta effettivamente utilizzando quasi tutta la RAM in quel momento. È tempo di ottenere strumenti migliori per monitorare l'utilizzo della memoria (o memoria libera / disponibile nel sistema).

La vera soluzione è ridurre l'utilizzo della memoria (eseguire processi con meno perdite di memoria, eseguire meno processi, saltare l'esecuzione di alcuni processi, limitare il numero di processi figlio / lavoratore di alcuni software server) o ottenere più RAM. Se la necessità di RAM è causata da perdite di memoria, è possibile scegliere invece di utilizzare lo scambio. Linux dovrebbe essere piuttosto intelligente nel far scambiare le parti trapelate, dato il tempo sufficiente. Avere lo scambio è meglio di niente ma non è un vero sostituto per avere una quantità adeguata di RAM.