Ottimizzazione di Linux per migliorare le prestazioni di PostgreSQL. Ilya Kosmodemyansky

Trascrizione del rapporto del 2015 di Ilya Kosmodemyansky "Ottimizzazione di Linux per migliorare le prestazioni di PostgreSQL"

Dichiarazione di non responsabilità: prendo atto che questo rapporto è datato novembre 2015: sono passati più di 4 anni ed è passato molto tempo. La versione 9.4 discussa nel rapporto non è più supportata. Negli ultimi 4 anni sono state rilasciate 5 nuove versioni di PostgreSQL e 15 versioni del kernel Linux. Se riscrivi questi passaggi, ti ritroverai con un resoconto diverso. Ma qui consideriamo la messa a punto fondamentale di Linux per PostgreSQL, che è ancora attuale.

Mi chiamo Ilya Kosmodemyansky. Lavoro presso PostgreSQL-Consulting. E ora parlerò un po' di cosa fare con Linux in relazione ai database in generale e a PostgreSQL in particolare, perché i principi sono abbastanza simili.

Di cosa parleremo? Se comunichi con PostgreSQL, in una certa misura devi essere un amministratore UNIX. Cosa significa? Se confrontiamo Oracle e PostgreSQL, in Oracle devi essere l'80% amministratore del database DBA e il 20% amministratore Linux.

Con PostgreSQL è un po’ più complicato. Con PostgreSQL devi avere una comprensione molto migliore di come funziona Linux. E allo stesso tempo corri un po 'dietro alla locomotiva, perché ultimamente tutto è stato aggiornato abbastanza bene. E vengono rilasciati nuovi kernel e appaiono nuove funzionalità, le prestazioni migliorano, ecc.

Perché parliamo di Linux? Niente affatto perché siamo alla conferenza Linux Peter, ma perché nelle condizioni moderne uno dei sistemi operativi più giustificati per l'utilizzo dei database in generale e PostgreSQL in particolare è Linux. Perché FreeBSD, sfortunatamente, si sta sviluppando in una direzione molto strana. E ci saranno problemi sia con le prestazioni che con tante altre cose. Le prestazioni di PostgreSQL su Windows sono generalmente un problema serio a parte, basato sul fatto che Windows non ha la stessa memoria condivisa di UNIX, mentre PostgreSQL è tutto legato a questo, perché è un sistema multiprocesso.

E penso che tutti siano meno interessati agli esotici come Solaris, quindi andiamo.

Una moderna distribuzione Linux ha oltre 1 opzioni syctl, a seconda di come costruisci il kernel. Allo stesso tempo, se osserviamo i diversi dadi, possiamo aggiustare qualcosa in molti modi. Ci sono parametri del file system su come montarli. Se hai domande su come avviarlo: cosa abilitare nel BIOS, come configurare l'hardware, ecc.

Si tratta di un volume molto ampio che può essere discusso nell'arco di diversi giorni e non in un breve rapporto, ma ora mi concentrerò su cose importanti, come evitare quei rake che sicuramente ti impediranno di utilizzare bene il tuo database su Linux se tu non correggerli. E allo stesso tempo, un punto importante è che molti parametri predefiniti non sono inclusi nelle impostazioni corrette per il database. Cioè, per impostazione predefinita funzionerà male o per niente.

Quali obiettivi di ottimizzazione tradizionali sono presenti in Linux? Penso che dal momento che vi occupate tutti di amministrazione di Linux, non ci sia particolare bisogno di spiegare quali siano gli obiettivi.

Puoi sintonizzare:

• PROCESSORE.
• Memoria.
• Conservazione.
• Altro. Ne riparleremo alla fine a merenda. Anche, ad esempio, parametri come la politica di risparmio energetico possono influenzare le prestazioni in modo molto imprevedibile e non proprio piacevole.

Quali sono le specifiche di PostgreSQL e del database in generale? Il problema è che non puoi modificare un singolo dado e vedere che le nostre prestazioni sono migliorate in modo significativo.

Sì, esistono gadget del genere, ma un database è una cosa complessa. Interagisce con tutte le risorse di cui dispone il server e preferisce interagire al meglio. Se guardi le attuali raccomandazioni di Oracle su come utilizzare un sistema operativo host, sarà come la battuta sul cosmonauta mongolo: dai da mangiare al cane e non toccare nulla. Diamo al database tutte le risorse, il database stesso risolverà tutto.

In linea di principio, in una certa misura la situazione è esattamente la stessa con PostgreSQL. La differenza è che il database non è ancora in grado di prendere per sé tutte le risorse, ad es. da qualche parte a livello Linux devi risolvere tutto da solo.

L'idea principale non è selezionare un singolo obiettivo e iniziare a ottimizzarlo, ad esempio memoria, CPU o qualcosa del genere, ma analizzare il carico di lavoro e cercare di migliorare il più possibile il throughput in modo che il carico creato dai bravi programmatori per noi, compresi i nostri utenti.

Ecco una foto per spiegare di cosa si tratta. È presente un buffer del sistema operativo Linux, è presente una memoria condivisa e sono presenti buffer condivisi PostgreSQL. PostgreSQL, a differenza di Oracle, funziona direttamente solo attraverso il buffer del kernel, ovvero, affinché una pagina dal disco possa entrare nella sua memoria condivisa, deve passare attraverso il buffer del kernel e tornare indietro, esattamente la stessa situazione.

I dischi vivono sotto questo sistema. L'ho disegnato come dischi. In effetti, potrebbe esserci un controller RAID, ecc.

E questo input-output in un modo o nell'altro avviene attraverso questa materia.

PostgreSQL è un database classico. C'è una pagina all'interno. E tutto l'input e l'output avvengono utilizzando le pagine. Stiamo sollevando blocchi in memoria con le pagine. E se non succede nulla, li leggiamo e basta, poi gradualmente scompaiono da questa cache, dai buffer condivisi e finiscono di nuovo sul disco.

Se sostituiamo qualcosa da qualche parte, l'intera pagina verrà contrassegnata come sporca. Li ho segnati qui in blu. Ciò significa che questa pagina deve essere sincronizzata con l'archiviazione a blocchi. Cioè, quando lo abbiamo sporcato, abbiamo inserito una voce in WAL. E in un momento meraviglioso si è verificato un fenomeno chiamato checkpoint. E in questo registro è stata registrata l'informazione che era arrivato. Ciò significa che tutte le pagine sporche che erano qui in quel momento in questi buffer condivisi sono state sincronizzate con il disco di archiviazione utilizzando fsync attraverso il buffer del kernel.

Perché viene fatto questo? Se abbiamo perso la tensione, non abbiamo avuto la situazione in cui tutti i dati sono andati persi. La memoria persistente, di cui tutti ci hanno parlato, è così lontana nella teoria dei database: questo è un futuro luminoso, per il quale, ovviamente, ci sforziamo e ci piace, ma per ora vivono tra meno 20 anni. E, naturalmente, tutto ciò deve essere monitorato.

E il compito di massimizzare il throughput è quello di mettere a punto tutte queste fasi in modo che tutto si muova avanti e indietro rapidamente. La memoria condivisa è fondamentalmente una cache di pagina. In PostgreSQL abbiamo inviato una query di selezione o qualcosa del genere, ha recuperato questi dati dal disco. Sono finiti in buffer condivisi. Di conseguenza, affinché funzioni meglio, deve esserci molta memoria.

Affinché tutto ciò funzioni bene e rapidamente, è necessario configurare correttamente il sistema operativo in tutte le fasi. E scegli un hardware bilanciato, perché se hai uno squilibrio in qualche punto, puoi creare molta memoria, ma non verrà gestita a velocità sufficiente.

E analizziamo ciascuno di questi punti.

Per far sì che queste pagine viaggino avanti e indietro più velocemente, è necessario ottenere quanto segue:

• Innanzitutto, devi lavorare in modo più efficiente con la memoria.
• In secondo luogo, questa transizione quando le pagine dalla memoria passano al disco dovrebbe essere più efficiente.
• E in terzo luogo, devono esserci buoni dischi.

Se hai 512 GB di RAM nel server e finisce tutto su un disco rigido SATA senza cache, l'intero server database si trasforma non solo in una zucca, ma in una zucca con un'interfaccia SATA. Lo incontrerai direttamente. E niente ti salverà.

Per quanto riguarda il primo punto relativo alla memoria, ci sono tre cose che possono rendere la vita molto difficile.

Il primo di questi è NUMA. NUMA è una cosa creata per migliorare le prestazioni. A seconda del carico di lavoro, è possibile ottimizzare diverse cose. E nella sua nuova forma attuale, non è molto adatto per applicazioni come i database che utilizzano in modo intensivo i buffer condivisi della cache delle pagine.

In poche parole. Come puoi sapere se c'è qualcosa che non va con NUMA? Hai qualche tipo di colpo spiacevole, improvvisamente una parte della CPU è sovraccarica. Allo stesso tempo, analizzi le query in PostgreSQL e vedi che non c'è nulla di simile lì. Queste query non dovrebbero essere così impegnative per la CPU. Puoi prenderlo per molto tempo. È più semplice utilizzare fin dall'inizio i consigli corretti su come configurare NUMA per PostgreSQL.

Cosa sta succedendo veramente? NUMA sta per accesso alla memoria non uniforme. Qual e il punto? Hai una CPU, accanto ad essa c'è la sua memoria locale. E queste interconnessioni di memoria possono estrarre memoria da altre CPU.

Se corri numactl --hardware, otterrai un foglio così grande. Tra l'altro ci sarà un campo distanze. Ci saranno dei numeri: 10-20, qualcosa del genere. Questi numeri non sono altro che il numero di salti necessari per prelevare questa memoria remota e utilizzarla localmente. In linea di principio, una buona idea. Ciò accelera notevolmente le prestazioni in una vasta gamma di carichi di lavoro.

Ora immagina di avere una CPU che tenta prima di utilizzare la sua memoria locale, quindi di provare a recuperare un'altra memoria tramite interconnessione per qualcosa. E questa CPU ottiene l'intera cache delle pagine PostgreSQL: ecco, alcuni gigabyte. Si ottiene sempre il caso peggiore, perché sulla CPU di solito c'è poca memoria nel modulo stesso. E tutta la memoria utilizzata passa attraverso queste interconnessioni. Risulta lento e triste. E il tuo processore che serve questo nodo è costantemente sovraccarico. E il tempo di accesso a questa memoria è pessimo, lento. Questa è la situazione che non desideri se la utilizzi per un database.

Pertanto, un'opzione più corretta per il database è che il sistema operativo Linux non sappia affatto cosa sta succedendo lì. In modo che acceda alla memoria come fa.

Perché? Sembrerebbe che dovrebbe essere il contrario. Ciò accade per un semplice motivo: abbiamo bisogno di molta memoria per la cache delle pagine: decine, centinaia di gigabyte.

E se allochiamo tutto questo e mettiamo nella cache i nostri dati lì, il guadagno derivante dall'utilizzo della cache sarà significativamente maggiore del guadagno derivante da un accesso così complicato alla memoria. E ne trarremo quindi un vantaggio incomparabile rispetto al fatto che accederemo alla memoria in modo più efficiente utilizzando NUMA.

Pertanto, al momento ci sono due approcci, finché non arriva il futuro luminoso e il database stesso non è in grado di capire su quali CPU è in esecuzione e da dove deve estrarre qualcosa.

Pertanto, l'approccio corretto consiste nel disabilitare completamente NUMA, ad esempio, al riavvio. Nella maggior parte dei casi, le vincite sono di tale ordine di grandezza che la questione su quale sia la migliore non si pone affatto.

C'è un'altra opzione. Lo usiamo più spesso del primo, perché quando un cliente viene da noi per ricevere supporto, riavviare il server è per lui un grosso problema. Ha un'attività lì. E hanno problemi a causa della NUMA. Proviamo quindi a disattivarlo in modi meno invasivi rispetto al riavvio, facendo però attenzione a verificare che sia disattivato. Perché, come dimostra l'esperienza, è positivo disattivare NUMA sul processo PostgreSQL principale, ma non è affatto necessario che funzioni. Dobbiamo controllare e vedere che si sia davvero spenta.

C'è un buon post di Robert Haas. Questo è uno dei committer di PostgreSQL. Uno degli sviluppatori chiave di tutte le frattaglie di basso livello. E se segui i link di questo post, descrivono diverse storie pittoresche su come la NUMA ha reso la vita difficile alle persone. Guarda, studia l'elenco di controllo dell'amministratore di sistema su ciò che deve essere configurato sul server affinché il nostro database funzioni bene. Queste impostazioni devono essere annotate e controllate, altrimenti non sarà molto buona.

Tieni presente che questo vale per tutte le impostazioni di cui parlerò. Ma solitamente i database vengono raccolti in modalità master-slave per la tolleranza agli errori. Non dimenticare di effettuare queste impostazioni sullo slave perché un giorno avrai un incidente e passerai allo slave e diventerà il master.

In una situazione di emergenza, quando tutto va molto male, il tuo telefono squilla costantemente e il tuo capo arriva correndo con un grosso bastone, non avrai tempo di pensare a controllare. E i risultati possono essere piuttosto disastrosi.

Il punto successivo sono le pagine enormi. Pagine enormi sono difficili da testare separatamente e non ha senso farlo, sebbene esistano benchmark che possono farlo. Sono facili da cercare su Google.

Qual e il punto? Hai un server non molto costoso con molta RAM, ad esempio più di 30 GB. Non usi pagine enormi. Ciò significa che hai sicuramente un sovraccarico in termini di utilizzo della memoria. E questo sovraccarico non è dei più piacevoli.

Perché? Allora cosa sta succedendo? Il sistema operativo alloca la memoria in piccole parti. È così conveniente, è così che è successo storicamente. E se scendiamo nel dettaglio, il sistema operativo deve tradurre gli indirizzi virtuali in fisici. E questo processo non è dei più semplici, quindi il sistema operativo memorizza nella cache il risultato di questa operazione nel Translation Lookaside Buffer (TLB).

E poiché il TLB è una cache, in questa situazione sorgono tutti i problemi inerenti alla cache. Innanzitutto, se hai molta RAM ed è tutta allocata in piccoli blocchi, questo buffer diventa molto grande. E se la cache è grande, la ricerca al suo interno sarà più lenta. L'overhead è sano e occupa spazio, ovvero la RAM viene consumata da qualcosa di sbagliato. Questa volta.

Due: più la cache cresce in una situazione del genere, più è probabile che si verifichino errori di cache. E l'efficienza di questa cache diminuisce rapidamente all'aumentare delle sue dimensioni. Pertanto, i sistemi operativi hanno adottato un approccio semplice. È stato utilizzato in Linux per molto tempo. È apparso in FreeBSD non molto tempo fa. Ma stiamo parlando di Linux. Queste sono pagine enormi.

E qui va notato che l'idea di pagine enormi è stata inizialmente spinta da comunità che includevano Oracle e IBM, cioè i produttori di database pensavano fortemente che questo sarebbe stato utile anche per i database.

E come si può fare amicizia con PostgreSQL? Innanzitutto, le pagine enormi devono essere abilitate nel kernel Linux.

In secondo luogo, devono essere specificati esplicitamente dal parametro sysctl: quanti ce ne sono. I numeri qui provengono da qualche vecchio server. Puoi calcolare quanti buffer condivisi hai in modo che possano contenere pagine enormi.

E se l'intero server è dedicato a PostgreSQL, un buon punto di partenza è allocare il 25% della RAM ai buffer condivisi o il 75% se sei sicuro che il tuo database si adatterà sicuramente a questo 75%. Punto di partenza uno. E considera che se hai 256 GB di RAM, di conseguenza avrai 64 GB di buffer di grandi dimensioni. Calcola approssimativamente con un certo margine: su cosa dovrebbe essere impostata questa cifra.

Prima della versione 9.2 (se non sbaglio, dalla versione 8.2), era possibile connettere PostgreSQL a pagine enormi utilizzando una libreria di terze parti. E questo dovrebbe essere fatto sempre. Innanzitutto è necessario che il kernel sia in grado di allocare correttamente pagine enormi. E, in secondo luogo, affinché l'applicazione che funziona con loro possa utilizzarli. Non verrà utilizzato solo in questo modo. Poiché PostgreSQL ha allocato la memoria nello stile del sistema 5, ciò potrebbe essere fatto utilizzando libhugetlbfs: questo è il nome completo della libreria.

Nella versione 9.3, le prestazioni di PostgreSQL sono state migliorate quando si lavora con la memoria e il metodo di allocazione della memoria del sistema 5 è stato abbandonato. Tutti erano molto contenti, perché altrimenti provi a eseguire due istanze PostgreSQL su una macchina e lui dice che non ho abbastanza memoria condivisa. E dice che sysctl deve essere corretto. E c'è un tale sysctl che devi ancora riavviare, ecc. In generale, tutti erano felici. Ma l'allocazione della memoria mmap ha interrotto l'uso di pagine enormi. La maggior parte dei nostri clienti utilizza buffer condivisi di grandi dimensioni. E abbiamo fortemente consigliato di non passare a 9.3, perché le spese generali cominciavano a essere calcolate in buone percentuali.

Ma la community ha prestato attenzione a questo problema e nella 9.4 ha rielaborato molto bene questo evento. E nella versione 9.4 è apparso un parametro in postgresql.conf in cui è possibile abilitare o disabilitare la prova.

Provare è l'opzione più sicura. All'avvio di PostgreSQL, quando alloca memoria condivisa, tenta di prelevare questa memoria dalle pagine enormi. E se non funziona, torna alla selezione normale. E se hai FreeBSD o Solaris, puoi provarlo, è sempre sicuro.

Se attivo, semplicemente non si avvia se non è possibile selezionare dalle pagine enormi. Qui si tratta già di chi e cosa è più carino. Ma se ci provi, controlla di avere davvero evidenziato ciò che ti serve, perché c'è molto spazio per errori. Attualmente questa funzionalità funziona solo su Linux.

Ancora una piccola nota prima di andare oltre. Le pagine enormi e trasparenti non riguardano ancora PostgreSQL. Non può usarli normalmente. E con pagine enormi e trasparenti per un carico di lavoro di questo tipo, quando è necessaria una grande porzione di memoria condivisa, i vantaggi arrivano solo con volumi molto grandi. Se hai terabyte di memoria, questo potrebbe entrare in gioco. Se parliamo di applicazioni più quotidiane, quando hai 32, 64, 128, 256 GB di memoria sulla tua macchina, allora le solite pagine enormi vanno bene e disabilitiamo semplicemente Trasparente.

E l'ultima cosa sulla memoria non è direttamente correlata alla frutta, può davvero rovinarti la vita. Tutto il throughput sarà fortemente influenzato dal fatto che il server si scambia costantemente.

E questo sarà molto spiacevole in molti modi. E il problema principale è che i kernel moderni si comportano in modo leggermente diverso dai kernel Linux più vecchi. Ed è piuttosto spiacevole calpestare questa cosa, perché quando parliamo di qualche tipo di lavoro con lo swap, finisce con l'arrivo prematuro dell'OOM-killer. E l'OOM-killer, che non è arrivato in tempo e ha abbandonato PostgreSQL, è spiacevole. Tutti lo sapranno, cioè fino all'ultimo utente.

Cosa sta succedendo? Hai una grande quantità di RAM lì, tutto funziona bene. Ma per qualche motivo il server si blocca in swap e rallenta a causa di ciò. Sembrerebbe che ci sia molta memoria, ma questo accade.

In precedenza, avevamo consigliato di impostare vm.swappiness su zero, ovvero di disabilitare lo swap. In precedenza, sembrava che 32 GB di RAM e i corrispondenti buffer condivisi fossero una quantità enorme. Lo scopo principale dello scambio è avere un posto dove gettare la crosta se cadiamo. E non era più particolarmente soddisfatto. E poi cosa farai con questa crosta? Questo è un compito per il quale non è molto chiaro il motivo per cui sia necessario uno swap, soprattutto di tali dimensioni.

Ma nelle versioni più moderne, cioè nella terza versione del kernel, il comportamento è cambiato. E se imposti lo swap su zero, ad es. lo spegni, prima o poi, anche se rimane un po' di RAM, un killer OOM verrà da te per uccidere i consumatori più intensivi. Perché penserà che con un tale carico di lavoro ci resta ancora qualcosa e salteremo fuori, cioè non per definire il processo del sistema, ma per definire qualcosa di meno importante. Questo meno importante sarà il consumatore intensivo di memoria condivisa, vale a dire il direttore delle poste. E dopo andrà bene se la base non dovrà essere ripristinata.

Pertanto, ora l'impostazione predefinita, per quanto ricordo, la maggior parte delle distribuzioni è intorno a 6, ad es. a che punto dovresti iniziare a utilizzare lo swap a seconda della quantità di memoria rimasta. Ora consigliamo di impostare vm.swappiness = 1, perché questo praticamente lo spegne, ma non dà gli stessi effetti di un OOM-killer che è arrivato inaspettatamente e ha ucciso tutto.

Qual è il prossimo? Quando parliamo delle prestazioni dei database e ci spostiamo gradualmente verso i dischi, tutti iniziano a afferrare la testa. Perché la verità che il disco è lento e la memoria è veloce è familiare a tutti fin dall'infanzia. E tutti sanno che il database avrà problemi di prestazioni del disco.

Il principale problema di prestazioni di PostgreSQL associato ai picchi di checkpoint non si verifica perché il disco è lento. Ciò è molto probabilmente dovuto al fatto che la memoria e la larghezza di banda del disco non sono bilanciate. Tuttavia, potrebbero non essere bilanciati in luoghi diversi. PostgreSQL non è configurato, il sistema operativo non è configurato, l'hardware non è configurato e l'hardware non è corretto. E questo problema non si verifica solo se tutto avviene come dovrebbe, ovvero non c'è carico oppure le impostazioni e l'hardware sono ben selezionati.

Cos'è e che aspetto ha? Di solito le persone che lavorano con PostgreSQL sono entrate in questa questione più di una volta. Spiegherò. Come ho detto, PostgreSQL crea periodicamente dei checkpoint per scaricare su disco le pagine sporche della memoria condivisa. Se disponiamo di una grande quantità di memoria condivisa, il checkpoint inizia ad avere un impatto intenso sul disco, poiché scarica queste pagine con fsync. Arriva nel buffer del kernel e viene scritto sui dischi utilizzando fsync. E se il volume di questa attività è elevato, allora possiamo osservare un effetto spiacevole, vale a dire un utilizzo molto ampio dei dischi.

Qui ho due foto. Ora ti spiegherò di cosa si tratta. Questi sono due grafici correlati al tempo. Il primo grafico riguarda l'utilizzo del disco. Qui raggiunge quasi il 90% in questo momento. Se si verifica un guasto al database con i dischi fisici, con un utilizzo del controller RAID al 90%, questa è una brutta notizia. Ciò significa che ancora un po' e raggiungerà 100 e l'I/O si fermerà.

Se hai un array di dischi, la storia è leggermente diversa. Dipende da come è configurato, che tipo di array è, ecc.

E parallelamente, qui viene configurato un grafico dalla vista interna di Postgres, che indica come si verifica il checkpoint. E il colore verde qui mostra quanti buffer, queste pagine sporche, in quel momento sono arrivate a questo punto di controllo per la sincronizzazione. E questa è la cosa principale che devi sapere qui. Vediamo che abbiamo molte pagine qui e ad un certo punto abbiamo colpito la lavagna, cioè abbiamo scritto e scritto, qui il sistema del disco è chiaramente molto occupato. E il nostro checkpoint ha un impatto molto forte sul disco. Idealmente, la situazione dovrebbe assomigliare di più a questa, cioè abbiamo registrato meno qui. E possiamo sistemarlo con le impostazioni in modo che continui ad essere così. Cioè, il riciclaggio è piccolo, ma da qualche parte stiamo scrivendo qualcosa qui.

Cosa è necessario fare per superare questo problema? Se hai interrotto l'IO nel database, significa che tutti gli utenti che sono venuti per soddisfare le loro richieste aspetteranno.

Se guardi dal punto di vista di Linux, se hai preso un buon hardware, lo hai configurato correttamente, hai configurato PostgreSQL normalmente in modo che faccia questi checkpoint meno spesso, li distribuisca nel tempo tra loro, quindi entri nei parametri Debian predefiniti. Per la maggior parte delle distribuzioni Linux, questa è l'immagine: vm.dirty_ratio=20, vm.dirty_ background_ratio=10.

Cosa significa? Un demone di flushing è apparso dal kernel 2.6. Pdglush, a seconda di chi sta usando quale, che è impegnato nell'eliminazione in background delle pagine sporche dal buffer del kernel e nell'eliminazione quando è necessario scartare le pagine sporche, qualunque cosa accada, quando l'eliminazione del backgrouind non aiuta.

Quando arriva lo sfondo? Quando il 10% della RAM totale disponibile sul server è occupato da pagine sporche nel buffer del kernel, in background viene richiamata una speciale funzione di cancellazione. Perché è sullo sfondo? Come parametro, tiene conto di quante pagine cancellare. E, diciamo, cancella N pagine. E per un po' questa cosa si addormenta. E poi torna di nuovo e copia altre pagine.

Questa è una storia estremamente semplice. Il problema qui è come con una piscina, quando si versa in un tubo, sfocia in un altro. Il nostro checkpoint è arrivato e se ha inviato alcune pagine sporche da scartare, gradualmente l'intera faccenda verrà risolta chiaramente dal buffer del kernel pgflush.

Se queste pagine sporche continuano ad accumularsi, si accumulano fino al 20%, dopodiché la priorità del sistema operativo è cancellare tutto sul disco, perché verrà a mancare la corrente e tutto andrà male per noi. Perderemo questi dati, ad esempio.

Qual è il trucco? Il trucco è che questi parametri nel mondo moderno rappresentano il 20 e il 10% della RAM totale presente sulla macchina, sono assolutamente mostruosi in termini di produttività di qualsiasi sistema disco di cui disponi.

Immagina di avere 128 GB di RAM. Nel tuo sistema disco arrivano 12,8 GB. E non importa quale cache hai lì, non importa quale array hai lì, non dureranno così a lungo.

Pertanto, ti consigliamo di modificare immediatamente questi numeri in base alle capacità del tuo controller RAID. Ho immediatamente consigliato qui un controller con 512 MB di cache.

Tutto è considerato molto semplice. Puoi inserire vm.dirty_ background in byte. E queste impostazioni annullano le due precedenti. O il rapporto è predefinito, oppure quelli con byte sono attivati, quindi quelli con byte funzioneranno. Ma poiché sono un consulente DBA e lavoro con clienti diversi, provo a disegnare cannucce e quindi, se in byte, quindi in byte. Nessuno ha dato alcuna garanzia che un buon amministratore non avrebbe aggiunto più memoria al server, non lo avrebbe riavviato e la cifra sarebbe rimasta la stessa. Basta calcolare questi numeri in modo che tutto si adatti con una garanzia.

Cosa succede se non ti adatti? Ho scritto che qualsiasi scarico viene effettivamente interrotto, ma in realtà questo è un modo di dire. Il sistema operativo ha un grosso problema: ha molte pagine sporche, quindi l'IO generato dai tuoi client viene effettivamente interrotto, ovvero l'applicazione è arrivata per inviare una query SQL al database, è in attesa. Qualsiasi input/output ad esso ha la priorità più bassa, perché il database è occupato da un checkpoint. E quando finirà non è del tutto chiaro. E quando hai ottenuto lo svuotamento senza background, significa che tutto il tuo IO ne è occupato. E finché non finirà, non farai nulla.

Ci sono altri due punti importanti che esulano dallo scopo di questo rapporto. Queste impostazioni dovrebbero corrispondere alle impostazioni in postgresql.conf, ovvero le impostazioni dei checkpoint. E il tuo sistema disco deve essere adeguatamente configurato. Se hai una cache su un RAID, deve avere una batteria. Le persone acquistano RAID con una buona cache senza batteria. Se hai SSD in RAID, allora devono essere server, devono esserci dei condensatori lì. Ecco una lista di controllo dettagliata. Questo collegamento contiene il mio rapporto su come configurare un disco delle prestazioni in PostgreSQL. Ci sono tutte queste liste di controllo lì.

Cos'altro può rendere la vita molto difficile? Questi sono due parametri. Sono relativamente nuovi. Per impostazione predefinita, possono essere inclusi in diverse applicazioni. E possono rendere la vita altrettanto difficile se vengono accesi in modo errato.

Ci sono due cose relativamente nuove. Sono già apparsi nei terzi nuclei. Questo è sched_migration_cost in nanosecondi e sched_autogroup_enabled, che è uno per impostazione predefinita.

E come ti rovinano la vita? Cos'è sched_migration_cost? Su Linux, lo scheduler può migrare un processo da una CPU all'altra. E per PostgreSQL, che esegue query, la migrazione su un'altra CPU non è del tutto chiara. Dal punto di vista del sistema operativo, quando si passa da openoffice a terminale tra le finestre, questo può essere positivo, ma per un database questo è pessimo. Pertanto, una politica ragionevole consiste nell'impostare il costo_migrazione su un valore elevato, almeno diverse migliaia di nanosecondi.

Cosa significherà questo per lo scheduler? Si considererà che durante questo periodo il processo è ancora caldo. Cioè, se hai una transazione di lunga durata che fa qualcosa da molto tempo, lo scheduler lo capirà. Presupporrà che fino allo scadere di questo timeout, non è necessario migrare questo processo da nessuna parte. Se allo stesso tempo il processo fa qualcosa, non verrà migrato da nessuna parte, funzionerà tranquillamente sulla CPU che gli è stata assegnata. E il risultato è eccellente.

Il secondo punto è l'autogroup. Esiste una buona idea per carichi di lavoro specifici che non sono correlati ai database moderni: raggruppare i processi in base al terminale virtuale da cui vengono avviati. Questo è utile per alcune attività. In pratica PostgreSQL è un sistema multiprocesso con un prefork che viene eseguito da un singolo terminale. Hai uno scrittore di blocchi, un checkpoint e tutte le richieste dei tuoi client verranno raggruppate in uno scheduler, per CPU. E lì aspetteranno all'unisono che sia libero, per interferire tra loro e tenerlo occupato più a lungo. Questa è una storia del tutto inutile nel caso di un tale carico e quindi necessita di essere disattivata.

Il mio collega Alexey Lesovsky ha eseguito dei test con un semplice pgbench, in cui ha aumentato i costi di migrazione di un ordine di grandezza e ha disattivato l'autogroup. La differenza sull'hardware difettoso era quasi del 10%. C'è una discussione sulla mailing list di Postgres in cui le persone forniscono risultati di modifiche simili alla velocità delle query influenzato il 50%. Ci sono molte di queste storie.

E infine, sulla politica di risparmio energetico. La cosa buona è che ora Linux può essere utilizzato su un laptop. E presumibilmente consumerà bene la batteria. Ma all'improvviso si scopre che ciò può accadere anche sul server.

Inoltre, se noleggi server da qualche hoster, ai “buoni” hoster non interessa che tu abbia prestazioni migliori. Il loro compito è garantire che il ferro venga utilizzato nel modo più efficiente possibile. Pertanto, per impostazione predefinita possono abilitare la modalità di risparmio energetico del laptop sul sistema operativo.

Se usi queste cose su un server con un database sotto carico pesante, la tua scelta è acpi_cpufreq + permormance. Anche con l'ondemand ci saranno problemi.

Intel_pstate è un driver leggermente diverso. E ora la preferenza è data a questa, perché è più tardi e funziona meglio.

E, di conseguenza, il governatore è solo la performance. Ondemand, PowerSave e tutto il resto non riguardano te.

I risultati dell'analisi dettagliata di PostgreSQL potrebbero differire di diversi ordini di grandezza se si abilita il risparmio energetico, perché praticamente la CPU del database funzionerà in modo completamente imprevedibile.

Questi elementi potrebbero essere inclusi per impostazione predefinita. Guarda attentamente per vedere se l'hanno attivato per impostazione predefinita. Questo può essere davvero un grosso problema.

E alla fine, volevo ringraziare i ragazzi del nostro team DBA di PosgreSQL-Consulting, vale a dire Max Boguk e Alexey Lesovsky, che ogni giorno fanno progressi in questa materia. E cerchiamo di fare il meglio che possiamo per i nostri clienti affinché tutto funzioni per loro. È come con le istruzioni di sicurezza dell’aviazione. Tutto qui è scritto con il sangue. Ciascuno di questi dadi si trova nel processo di qualche tipo di problema. Sono felice di condividerli con voi.

Domande:

Grazie! Se, ad esempio, un'azienda vuole risparmiare denaro e collocare il database e la logica dell'applicazione su un server, o se l'azienda segue la moda delle architetture a microservizi, in cui PostgreSQL viene eseguito in un contenitore. Qual è il trucco? Sysctl influenzerà l'intero kernel a livello globale. Non ho sentito parlare di sysctl in qualche modo virtualizzati in modo che funzionino separatamente su un contenitore. C'è solo un cgroup e lì c'è solo una parte del controllo. Come puoi convivere con tutto questo? Oppure, se desideri prestazioni, esegui PostgreSQL su un server hardware separato e ottimizzalo?

Abbiamo risposto alla tua domanda in circa tre modi. Se non stiamo parlando di un server hardware che può essere sintonizzato, ecc., Tranquilli, tutto funzionerà bene senza queste impostazioni. Se hai un carico tale da dover effettuare queste impostazioni, arriverai al server di ferro prima di queste impostazioni.

Qual è il problema? Se si tratta di una macchina virtuale, molto probabilmente avrai molti problemi, ad esempio il fatto che sulla maggior parte delle macchine virtuali la latenza del disco è piuttosto incoerente. Anche se la velocità effettiva del disco è buona, quindi una transazione I/O non riuscita che non influisce notevolmente sulla velocità effettiva media avvenuta al momento del checkpoint o al momento della scrittura su WAL, il database ne risentirà notevolmente. E te ne accorgerai prima di incontrare questi problemi.

Se hai NGINX sullo stesso server, avrai lo stesso problema. Lotterà per la memoria condivisa. E non arriverai ai problemi descritti qui.

Ma d’altra parte, alcuni di questi parametri saranno comunque rilevanti per te. Ad esempio, imposta dirty_ratio con sysctl in modo che non sia così pazzo - in ogni caso, questo aiuterà. In un modo o nell'altro, interagirai con il disco. E sarà secondo lo schema sbagliato. Questo è generalmente un valore predefinito per i parametri che ho mostrato. E comunque è meglio cambiarli.

Ma potrebbero esserci problemi con la NUMA. VmWare, ad esempio, funziona bene con NUMA con impostazioni esattamente opposte. E qui devi scegliere: un server in ferro o uno non in ferro.

Ho una domanda relativa ad Amazon AWS. Hanno immagini preconfigurate. Uno di questi si chiama Amazon RDS. Esistono impostazioni personalizzate per il loro sistema operativo?

Ci sono impostazioni lì, ma sono impostazioni diverse. Qui configuriamo il sistema operativo in termini di come il database utilizzerà questa cosa. E ci sono parametri che determinano dove dovremmo andare adesso, come il modellamento. Cioè, abbiamo bisogno di così tante risorse che ora le divoreremo. Successivamente, Amazon RDS riduce queste risorse e le prestazioni diminuiscono lì. Ci sono storie individuali su come le persone stanno iniziando a incasinare questa questione. A volte anche con successo. Ma questo non ha nulla a che fare con le impostazioni del sistema operativo. È come hackerare il cloud. Questa è una storia diversa.

Perché le pagine enormi trasparenti non hanno alcun effetto rispetto a TLB enormi?

Non dare. Ciò può essere spiegato in molti modi. Ma in realtà semplicemente non lo danno. Qual è la storia di PostgreSQL? All'avvio, alloca una grande porzione di memoria condivisa. Che siano trasparenti o meno è del tutto irrilevante. Il fatto che risaltino all'inizio spiega tutto. E se c'è molta memoria ed è necessario ricostruire il segmento shared_memory, le pagine enormi trasparenti saranno rilevanti. In PostgreSQL, all’inizio viene semplicemente allocato in un blocco enorme e basta, e poi lì non succede nulla di speciale. Ovviamente puoi usarlo, ma c'è la possibilità di corrompere shared_memory quando rialloca qualcosa. PostgreSQL non lo sa.

Fonte: habr.com