Ho appena fatto una serie di aggiornamenti e ho deciso che il modo più semplice per risolvere gli errori di memoria era semplicemente raddoppiare lo swap a 4 GB. Lo svantaggio è che su un droplet da 1 GB ci sono solo 25 GB di SSD, quindi perderne 4 per lo swap è una quantità significativa di spazio, ed è già un po’ stretto con soli 25 GB.
Quindi, dovremmo cambiare discourse-setup per rendere il valore predefinito 3 GB?
Cosa ne pensi, @Falco?
Se questo risolve il problema, sono completamente d’accordo.
Posso suggerire vivamente che lo script di installazione imposti anche le due configurazioni del kernel che influenzano la gestione della memoria? Sarebbe utile sapere che tutti coloro che apparentemente hanno un problema hanno almeno un punto di partenza per una buona configurazione del kernel.
Mi sembra un’idea sensata. Non riesco a immaginare dove THP possano essere utili su un’istanza di discourse dedicata, e l’overcommit può aiutare a evitare OOM.
Potrebbe considerare di offrire di fare ciascuna di queste cose separatamente, impostandole come risposta predefinita, con l’opzione non predefinita per disattivare?
Inoltre, lo script può utilizzare sysctl per scoprire se le impostazioni devono essere modificate in primo luogo prima di apportare una modifica. Se qualcuno ha già apportato queste modifiche con file diversi, sarebbe potenzialmente fonte di confusione creare override duplicati. Penso che non tutte le distribuzioni Linux spediscano con la memoria overcommit disattivata in primo luogo.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
A rischio di diluire l’importante messaggio sui parametri del kernel, c’è una seconda considerazione: lo script attuale crea lo swap solo su una macchina con poca RAM. Penso che sia un errore, sia perché lo swap è ancora utile per massimizzare l’utilità della RAM, sia, cosa più importante, perché causerà problemi se qualcuno crea il proprio Discourse su una macchina con molta RAM, per velocità o comodità, e poi la ridimensiona a poca RAM.
La configurazione dovrebbe creare lo swap in tutti i casi (a meno che non ce ne sia già abbastanza). È valido e talvolta utile avere più file di swap.
Non sono io a decidere, e le imposto sulle macchine che configuro, ma questo è uno script di shell che viene eseguito da (la maggior parte) tutti coloro che installano Discourse. Deve essere il più semplice possibile, e siamo sicuri che queste impostazioni funzionino su Raspberry Pi e Mac e su qualsiasi altra cosa la gente cerchi di fare? E qualsiasi metodo tu usi per verificare se è già impostato funziona su tutte queste piattaforme? Sembra difficile.
Ho scritto discourse-setup e trovo un po’ spaventoso apportare modifiche.
Offrire sempre di creare swap non è una cattiva idea. Forse offrire sempre di impostare 3 o 4 GB di swap? Ma allora quanta? Una regola empirica che una volta conoscevo era avere swap delle stesse dimensioni della RAM. E in questo momento, se non crei swap, la tua unica opzione è interrompere con control-c. Quindi o costringeremo le persone a creare swap o aggiungeremo un’altra domanda Sì/No (che mi farà modificare i miei script che eseguono discourse-setup 
) Oh! Oppure possiamo controllarlo con un interruttore --skip-swap. Questo mi sembra a posto. Se sei abbastanza intelligente da conoscere lo swap, puoi trovare l’interruttore per saltarlo; possiamo aggiungere una nota sull’interruttore in quel messaggio di AVVISO.
E forse aggiungere anche una nota su --skip-connection-test quando fallisce.
Penso che se hanno già impostato lo swap, si può presumere che sappiano cosa stanno facendo.
Grazie! E sì, pienamente compreso, mi sentirei allo stesso modo. Richiede un’attenta riflessione e test, di sicuro. E questo sarebbe su almeno un paio di macchine economiche di provider di hosting, e anche su Pi. Non sono sicuro riguardo a Windows o Mac - se ci si aspetta che siano supportati, allora suppongo di sì. Mi aspetterei che vengano utilizzati più probabilmente come macchine di sviluppo, che è una storia diversa.
Infatti. Qualunque cosa sembri necessaria al momento, forse. Sembra che abbia fatto un passo avanti. Ma mi rattrista molto non sapere se questi report includono o non includono la modifica dell’overcommit. Sono abbastanza sicuro che sappiamo da discussioni precedenti che l’overcommit fa la differenza.
E sappiamo che su un’istanza da 25G e ancora di più su un’istanza da 20G lo spazio su disco è limitato. Sto eseguendo su tali macchine: disco da 25G e RAM da 1G, che richiede già 2G di swap e probabilmente di più in questi giorni; e disco da 20G con RAM da 2G dove attualmente ho 1G di swap.
Non consiglierei altre domande Sì/No. Le opzioni da riga di comando sembrano una strada migliore.
Se dobbiamo cambiare questo script, penso che consiglierei diversi swapfile da 1G, perché massimizza la flessibilità, non spreca nulla ed è il momento più facile per prendere quella decisione.
Non ne sono così sicuro. Se la più piccola istanza con Ubuntu o Debian “nudo” ha già un po’ di swap - questo dovrebbe essere verificato - allora iniziamo ad avere problemi se non è sufficiente. Molto meglio misurare RAM+swap usando free, regolare come al solito per le configurazioni inferiori a 1G disponibili (AWS credo, forse Oracle), e poi aggiungere swapfile da 1G fino a un certo numero concordato, qualunque esso sia al momento. Si spera che un totale di 4G sia sufficiente, con il kernel overcommit impostato in modo appropriato.
Sono felice di aiutare.
Hmm. Sì. Vorrei aver pensato di controllare questo aspetto su quelli che ho appena modificato.
Hmm. Sono dell’idea che uno sia meglio, ma più di uno aggiunge flessibilità e potrebbe quindi essere possibile far aggiungere a discourse-setup un altro file di swap se è necessario più swap, il che significa che potremmo dire a tutti di eseguire discourse-setup per “risolvere” il loro problema di swap. E forse anche il problema dell’overcommit, beh, forse provare esplicitamente a farlo solo per Linux, dato che è tutto ciò che ci interessa.
Non sono d’accordo. Lo swap non è un bene universale. In passato era importante per rendere il codice della VM più uniforme anche quando non si effettuava lo swap in determinate circostanze, ma gli algoritmi della VM sono cambiati.
Ciò si basava su euristiche del codice del kernel molto vecchie che non si applicano più.
Inoltre, quando si considera la misurazione: non so nemmeno cosa vorresti fare per misurare lo swap e la memoria quando zswap è in uso. Questo è probabilmente un caso di “primum non nocere”, però.
Sono abbastanza sicuro che l’unico svantaggio di “troppo swap” sia l’utilizzo di più spazio su disco del necessario. È uno dei motivi per cui sarebbe preferibile avere diversi file di swap di dimensioni modeste: si può fare lo swap-off e rimuoverli progressivamente, se c’è la necessità di recuperare spazio su disco. Inoltre, penso che Linux faccia un lavoro ragionevole nell’utilizzarli progressivamente:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
La situazione in cui ci troviamo è che le istanze economiche sono piuttosto limitate sia in RAM che in spazio su disco, e Discourse ne utilizza sempre di più, man mano che i molti pacchetti al suo interno evolvono. Ma ancora, penso che ci siano modi per navigare saggiamente in questa situazione, per aiutare coloro che non sono in una posizione tale da potersi semplicemente arrendere e raddoppiare o quadruplicare la loro fattura mensile.
Lo swapping è abbastanza lento da non considerare “quasi esaurito ora” come motivo per aggiungere più di 1 GB al suggerimento predefinito a questo punto. Ogni 1 GB è una notevole quantità di swap, come sperimentato su un’istanza Discourse dedicata.
Sì, per impostazione predefinita Linux utilizza lo swap in ordine di priorità, ed è possibile utilizzare la stessa priorità su più dispositivi per eseguire esplicitamente lo striping dello swap. Ma aggiungere molto swap per piccoli siti non è particolarmente utile, suggerirei.
Quindi, se dopo circa un decennio le persone incontrano occasionalmente problemi con 2 GB, suggerirei di passare a 3 GB anziché 4 GB come impostazione predefinita. E la quantità necessaria di swap per un’istanza Discourse dedicata non dovrebbe aumentare particolarmente con la memoria, perché il contenuto che verrebbe effettivamente scambiato non cambia particolarmente molto.
L’idea di aumentare lo swap con più memoria proviene principalmente dall’informatica generalista, basata su un’ipotesi generalizzata che maggiore è la RAM necessaria, maggiore è la domanda probabile. Ma la pressione dello swap su un’istanza Discourse specializzata non è probabile che segua questo schema, penso.
THP sono specifici per le piattaforme che supportano le huge pages, che non sono tutte le piattaforme. Il modo generico per gestirlo è vedere se esiste. Su un Raspberry Pi che ho:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
Al contrario, l’overcommit è un parametro generale della VM per Linux da alcuni decenni. Sullo stesso Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Analizzare l’output di free in shell è un po’ complicato. Parlando come autore originale di procps, per questo cercherei solo SwapFree in /proc/meminfo. 
Concordo sul fatto che nei nostri mondi con costi vincolati, lo scaling dello swap per dimensione della RAM non sia più un buon piano. L’idea successiva storicamente sembra essere stata che la RAM è enorme e non hai bisogno di swap. Dopo di che arriva la saggezza che un po’ di swap è utile perché consente un migliore utilizzo della RAM. (In un mondo senza vincoli avremmo enormi quantità di RAM, ma questa è una nicchia.)
Quello che stiamo vedendo negli ultimi due mesi è che più persone hanno problemi di memoria insufficiente e fallimenti nella ricostruzione. Più persone trovano che gli aggiornamenti web falliscono, ma la riga di comando funziona. Da una semplice prospettiva di supporto, e dalla prospettiva della reputazione del prodotto, penso che abbiamo bisogno di un cambiamento nel solito consiglio e nella solita configurazione. Penso che 3G di swap sia il cambiamento più semplice e piccolo e dovremmo farlo se non facciamo nient’altro.
Ma penso ancora che più file di swap più piccoli siano una scelta più saggia - e abbiamo visto thread di supporto qui che puntano a questo. E penso ancora che sarebbe meglio cercare di dimensionare RAM+swap perché questo è il fattore limitante, la cosa che causa problemi alle persone. Potrebbe essere che ci siano modi diversi di fare quel calcolo. Si applicano le solite avvertenze su quali tattiche siano mantenibili, comprensibili, avranno longevità.
Per quanto riguarda le pagine enormi trasparenti, la mia comprensione è che sia il “trasparente” che causa problemi: il kernel può agitarsi, unendo e disunendo, per un calo delle prestazioni e nessun grande beneficio. Sono abbastanza sicuro che le hugepages siano sconsigliate per sistemi più piccoli.
Riguarda più le caratteristiche del carico di lavoro che la dimensione del sistema. Su un sistema con 1 GB di RAM con processi abbastanza stabili con blocchi di RAM, gli hugepages predefiniti da 2 MB possono ridurre il TLB thrashing e migliorare le prestazioni; il TLB non inizia a coprire le mappature per 1 GB di RAM. È generalmente solo un compromesso tra la CPU impiegata nella ricerca di memoria da coalescere e le cache miss del TLB, e ci sono molti carichi di lavoro su macchine da 1 GB che possono trarre notevoli vantaggi da THP. (Molte raccomandazioni per disabilitarlo risalgono all’inizio della sua implementazione; è stato sostanzialmente migliorato da allora.) La raccomandazione di disabilitare THP per Discourse non è dovuta alla dimensione di 1 GB di RAM, ma è specifica per l’uso di redis con persistenza su disco, che è qualcosa che Discourse utilizza:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
Sfortunatamente, quando un kernel Linux ha abilitato le pagine trasparenti di grandi dimensioni, Redis incorre in una forte penalità di latenza dopo la chiamata
forkutilizzata per persistere su disco. Le pagine di grandi dimensioni sono la causa del seguente problema:
…