Dunque, l'approccio corretto \u00e8 disabilitare completamente NUMA<\/strong>, ad esempio, al riavvio. Nella maggior parte dei casi, i guadagni sono cos\u00ec significativi che non si pone nemmeno la questione di quale sia la soluzione migliore. <\/p>\n<\/p>\n
C'\u00e8 un'altra opzione. La utilizziamo pi\u00f9 spesso della prima, perch\u00e9 quando un cliente richiede supporto, riavviare il server \u00e8 un grande problema per lui. L\u00ec c'\u00e8 il suo business che gira. E tendono a sperimentare problemi legati a NUMA. Perci\u00f2 cerchiamo di disattivarlo in modi meno invasivi rispetto al riavvio, ma qui bisogna essere pi\u00f9 cauti nel controllare che sia effettivamente disattivato. Perch\u00e9, come dimostra l'esperienza, disattivare NUMA sul processo principale di PostgreSQL va bene, ma non \u00e8 affatto garantito che funzioni. \u00c8 necessario controllare e assicurarsi che sia davvero disattivato. <\/p>\n
<\/p>\n
C'\u00e8 un buon post di Robert Haas. \u00c8 uno dei collaboratori di PostgreSQL. Uno dei principali sviluppatori di tutto il funzionamento a basso livello. E se segui i link di questo post, l\u00ec vengono raccontate diverse storie colorite su come NUMA abbia complicato la vita alle persone. Guarda, studia la checklist degli amministratori di sistema, che cosa bisogna configurare sul server affinch\u00e9 il nostro database funzioni bene. Queste impostazioni devono essere annotate e controllate, altrimenti la situazione non sar\u00e0 molto buona. <\/p>\n
<\/p>\n
Vorrei sottolineare che questo riguarda tutte le impostazioni di cui parler\u00f2. Di solito, i database vengono configurati in modalit\u00e0 master-slave per garantire la resilienza. Non dimenticate di applicare queste impostazioni anche sullo slave, perch\u00e9 a un certo punto avrete un guasto e passerete allo slave, che diventer\u00e0 il master. <\/p>\n
<\/p>\n
In una situazione di emergenza, quando tutto va male, il telefono suoner\u00e0 continuamente e il capo arriver\u00e0 con un grosso bastone; non avrete tempo per pensare a controllare. E i risultati potrebbero essere molto deludenti.<\/p>\n
<\/p>\n
<\/p>\n
Il prossimo punto riguarda le huge pages. \u00c8 difficile testare le huge pages separatamente, e non ha molto senso farlo, anche se ci sono dei benchmark capaci di farlo. Si trovano facilmente online. <\/p>\n
<\/p>\n
Qual \u00e8 il punto? Avete un server non molto costoso con molta RAM, ad esempio, pi\u00f9 di 30 GB. Non state utilizzando le huge pages. Questo significa che avete sicuramente un overhead nell'uso della memoria. E questo overhead non \u00e8 affatto piacevole. <\/p>\n
<\/p>\n
<\/p>\n
Perch\u00e9 succede tutto ci\u00f2? E cosa sta accadendo? Il sistema operativo allocca la memoria in piccole porzioni. \u00c8 comodo e storicamente cos\u00ec. E se entriamo nei dettagli, il SO deve tradurre indirizzi virtuali in fisici. Questo processo non \u00e8 semplice, quindi il SO memorizza i risultati di questa operazione nella Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
E poich\u00e9 il TLB \u00e8 una cache, in questa situazione sorgono tutti i problemi tipici delle cache. In primo luogo, se hai molta memoria RAM e questa \u00e8 tutta allocata in piccole porzioni, allora questo buffer diventa molto grande. E se la cache \u00e8 grande, la ricerca in essa diventa pi\u00f9 lenta. Il sovraccarico \u00e8 significativo e occupa spazio, ovvero la memoria operativa consuma ci\u00f2 che non \u00e8 corretto. Questo \u00e8 uno. <\/p>\n
<\/p>\n
Due: pi\u00f9 si espande la cache in questa situazione, maggiore \u00e8 la probabilit\u00e0 di avere cache misses. L'efficienza di questa cache diminuisce rapidamente con l'aumento delle sue dimensioni. Per questo motivo, nei sistemi operativi \u00e8 stato ideato un approccio semplice. In Linux \u00e8 utilizzato da tempo. In FreeBSD \u00e8 comparso non molto tempo fa. Ma stiamo parlando di Linux. Si tratta di huge pages.<\/p>\n
<\/p>\n
\u00c8 importante notare che l'idea delle huge pages \u00e8 stata inizialmente promossa da comunit\u00e0 che comprendevano Oracle e IBM, cio\u00e8 i produttori di database hanno pensato seriamente che ci\u00f2 sarebbe stato utile anche per i database. <\/p>\n
<\/p>\n
<\/p>\n
E come collegarlo a PostgreSQL? Innanzitutto, nel kernel di Linux devono essere abilitate le huge pages.<\/p>\n
<\/p>\n
In secondo luogo, devono essere specificate esplicitamente tramite il parametro sysctl \u2013 quante sono. I numeri qui provengono da un vecchio server. Puoi calcolare quanti shared buffers hai approssimativamente, affinch\u00e9 le huge pages possano adattarsi. <\/p>\n
<\/p>\n
E se l'intero server \u00e8 dedicato a PostgreSQL, un buon punto di partenza \u00e8 assegnare il 25 % della memoria RAM ai shared buffers, oppure il 75 %, se sei sicuro che la tua base di dati ci entrer\u00e0. Ecco il primo punto di partenza. Se hai 256 GB di RAM, avrai quindi 64 GB di shared buffers. Calcola approssimativamente con un certo margine \u2013 quale dovrebbe essere impostata questa cifra.<\/p>\n
<\/p>\n
Fino alla versione 9.2 (se non sbaglio, dalla versione 8.2) era possibile integrare PostgreSQL con huge pages tramite una libreria di terze parti. E questo \u00e8 sempre necessario fare. Innanzitutto, \u00e8 necessario che il kernel sappia allocare correttamente le huge pages. In secondo luogo, l'applicazione che lavora con esse deve essere in grado di utilizzarle. Non pu\u00f2 farlo cos\u00ec, senza ulteriori passaggi. Poich\u00e9 PostgreSQL allocava memoria secondo lo stile system 5, questo poteva essere fatto utilizzando libhugetlbfs \u2014 questo \u00e8 il nome completo della libreria.<\/p>\n
<\/p>\n
Nella versione 9.3 \u00e8 stata migliorata la gestione della memoria in PostgreSQL e si \u00e8 abbandonato il metodo system 5 per l'allocazione della memoria. Tutti erano molto felici, perch\u00e9 altrimenti si provava a far funzionare due istanze di PostgreSQL sulla stessa macchina e lui diceva che mancavano memoria condivisa. E diceva che bisognava correggere sysctl. E c'era un tale sysctl che bisognava anche riavviarsi e cos\u00ec via. Insomma, tutti furono contenti. Ma l'allocazione della memoria mmap ha rotto l'uso delle huge pages. La maggior parte dei nostri clienti utilizza grandi shared buffers. E abbiamo fortemente raccomandato di non passare alla 9.3, perch\u00e9 l\u00ec l'overhead iniziava a calcolarsi in buoni percentuali.<\/p>\n
<\/p>\n
Tuttavia, la community ha prestato attenzione a questo problema e nella versione 9.4 ha notevolmente migliorato questa funzione. In 9.4 \u00e8 stato aggiunto un parametro in postgresql.conf, che consente di attivare try, on o off.<\/p>\n
<\/p>\n
Try \u00e8 il parametro pi\u00f9 sicuro. All'avvio di PostgreSQL, quando viene allocata la memoria condivisa, tenta di ottenere da huge pages questa memoria. Se non riesce, torna all'allocazione standard. Se utilizzate FreeBSD o Solaris, potete impostare try, \u00e8 sempre sicuro. <\/p>\n
<\/p>\n
Se \u00e8 impostato on, non si avvia semplicemente se non riesce a ottenere da huge pages. Qui entra in gioco la preferenza personale. Ma se utilizzate try, verificate che sia stata effettivamente allocata la memoria corretta, poich\u00e9 ci sono molte possibilit\u00e0 di errore. Attualmente, questa funzionalit\u00e0 funziona solo su Linux.<\/p>\n
<\/p>\n
Un'ultima nota prima di procedere. Le Transparent huge pages non riguardano PostgreSQL per ora. Non possono essere utilizzate a dovere. Con le Transparent huge pages, per un carico di lavoro che richiede grandi porzioni di memoria condivisa, i vantaggi si manifestano solo con volumi molto elevati. Se hai terabyte di memoria, allora potrebbe avere importanza. Se parliamo di utilizzi pi\u00f9 quotidiani, quando hai 32, 64, 128 o 256 GB di memoria sulla macchina, allora le huge pages normali vanno bene, mentre le Transparent possono essere semplicemente disabilitate. <\/p>\n
<\/p>\n
<\/p>\n
E l'ultima cosa riguardante la memoria, sebbene non direttamente collegata alla larghezza di banda, pu\u00f2 complicare molto la situazione. L'intera capacit\u00e0 di trasferimento dati ne risentir\u00e0 se il server continua a effettuare il swap. <\/p>\n
<\/p>\n
E questo sar\u00e0 molto sgradevole in diverse situazioni. Il problema principale \u00e8 che nei kernel moderni il comportamento \u00e8 leggermente diverso rispetto ai kernel Linux pi\u00f9 vecchi. \u00c8 una questione su cui \u00e8 difficile mettere i piedi, perch\u00e9 quando parliamo di lavoro con lo swap, finiamo con l'arrivo intempestivo dell'OOM-killer. E avere un OOM-killer che non arriva in tempo e termina PostgreSQL \u00e8 sgradevole. Questo si riflette su tutti, ovvero fino all'ultimo utente. <\/p>\n
<\/p>\n
<\/p>\n
Cosa sta succedendo? Hai una grande quantit\u00e0 di memoria RAM, tutto funziona bene. Ma per qualche motivo, il server si blocca nello swap e rallenta a causa di questo. Sembrerebbe che ci sia molta memoria, eppure accade. <\/p>\n
<\/p>\n
<\/p>\n
Un tempo consigliavamo di impostare vm.swappiness a zero, ovvero di disattivare lo swap. In passato sembrava che 32 GB di RAM e i corrispondenti buffer condivisi fossero una quantit\u00e0 enorme. La funzione principale dello swap \u00e8 avere uno spazio in cui spingere i dati quando c'\u00e8 un problema. E questo non veniva pi\u00f9 eseguito. E poi, che ne fai di quei dati? \u00c8 un compito in cui non \u00e8 chiaro se lo swap sia davvero necessario, specialmente in una quantit\u00e0 cos\u00ec grande. <\/p>\n
<\/p>\n
Ma nelle versioni pi\u00f9 moderne del kernel, cio\u00e8 nelle terze, il comportamento \u00e8 cambiato. E se si imposta lo swap a zero, cio\u00e8 si disattiva, prima o poi, anche con un certo quantitativo di memoria RAM rimasta, il processo OOM-killer arriver\u00e0 per uccidere i consumatori pi\u00f9 intensivi. Questo perch\u00e9 considerer\u00e0 che, con un carico di lavoro del genere, ci resta ancora poco e non uccider\u00e0 i processi di sistema, ma qualcosa di meno importante. Questo meno importante sar\u00e0 un consumatore intensivo di memoria condivisa, ovvero il postmaster. E dopo questo sar\u00e0 un bene se non sar\u00e0 necessario ripristinare il database. <\/p>\n
<\/p>\n
Quindi, attualmente, se non ricordo male, la maggior parte delle distribuzioni ha un valore predefinito di circa 6, cio\u00e8 in quale momento iniziare a utilizzare lo swap in base a quanta memoria \u00e8 rimasta. Attualmente, consigliamo di impostare vm.swappiness = 1, perch\u00e9 praticamente lo disattiva, ma non produce effetti come l'arrivo inaspettato dell'OOM-killer che ha gi\u00e0 eliminato tutto.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Cosa succede adesso? Quando parliamo delle performance dei database e ci avviciniamo gradualmente ai dischi, tutti si prendono la testa tra le mani. Perch\u00e9 la verit\u00e0 che i dischi sono lenti e la memoria \u00e8 veloce \u00e8 conosciuta da tutti fin dall'infanzia. Tutti sanno che ci saranno problemi di prestazioni del disco nei database.<\/p>\n
<\/p>\n
Il principale problema di prestazioni di PostgreSQL, legato ai picchi dei checkpoint, non \u00e8 causato dalla lentezza del disco. Piuttosto, deriva dal fatto che la larghezza di banda della memoria e del disco non \u00e8 bilanciata. Possono essere sbilanciate in diversi modi. PostgreSQL non \u00e8 configurato correttamente, il sistema operativo non \u00e8 ottimizzato, l'hardware non \u00e8 impostato bene e l'hardware \u00e8 inadeguato. Questo problema non si verifica solo se tutto funziona come dovrebbe, cio\u00e8 se non ci sono carichi o se le configurazioni e l'hardware sono ben selezionati. <\/p>\n
<\/p>\n
<\/p>\n
Cos'\u00e8 e come appare? Di solito, le persone che lavorano con PostgreSQL hanno affrontato questo problema pi\u00f9 volte. Lasciate che spieghi. Come accennato, PostgreSQL effettua periodicamente dei checkpoint per trasferire le pagine sporche dalla memoria condivisa al disco. Se abbiamo una grande quantit\u00e0 di memoria condivisa, i checkpoint cominciano a influenzare intensamente il disco, poich\u00e9 dumpano queste pagine tramite fsync. Arrivano nel buffer del kernel e vengono scritte sui dischi grazie a fsync. E se il volume di questa operazione \u00e8 elevato, possiamo osservare un effetto indesiderato, ovvero un utilizzo molto elevato dei dischi.<\/p>\n
<\/p>\n
Qui ho due immagini. Ora spiegher\u00f2 cosa sono. Si tratta di due grafici correlati nel tempo. Il primo grafico mostra l'utilizzo del disco. Qui quasi raggiunge il 90 % in quel momento. Se il vostro database fallisce con dischi fisici e un controller RAID, un utilizzo vicino al 90 % \u00e8 una brutta notizia. Questo significa che a breve si raggiunger\u00e0 il 100 % e l'input-output si fermer\u00e0. <\/p>\n
<\/p>\n
Se avete un array di dischi, la situazione \u00e8 un po' diversa. Dipende da come \u00e8 configurato, che tipo di array si tratta, ecc. <\/p>\n
<\/p>\n
Parallelamente, qui \u00e8 configurato un grafico da una vista interna di postgres, che mostra come avviene il checkpoint. In verde \u00e8 evidenziata la quantit\u00e0 di buffer, queste pagine sporche che in questo momento sono arrivate in questo checkpoint per la sincronizzazione. Questa \u00e8 la cosa principale da sapere. Vediamo che qui sono arrivate molte pagine e a un certo punto siamo rimasti bloccati, cio\u00e8 abbiamo continuato a scrivere, qui chiaramente il sistema disco \u00e8 molto occupato. E il nostro checkpoint ha un forte impatto sul disco. Idealmente, la situazione dovrebbe apparire cos\u00ec, cio\u00e8 qui ci sono stati meno scritti. E possiamo risolvere questo con delle impostazioni, affinch\u00e9 in futuro rimanga cos\u00ec. Cio\u00e8, l'utilizzo \u00e8 ridotto, ma da qualche parte stiamo comunque scrivendo. <\/p>\n
<\/p>\n
Cosa fare per risolvere questo problema? Se si \u00e8 fermato l'IO sotto il database, significa che tutti gli utenti che sono arrivati per eseguire le loro query dovranno aspettare. <\/p>\n
<\/p>\n
<\/p>\n
Se guardiamo dal punto di vista di Linux, se hai preso un buon hardware, lo hai configurato correttamente, e hai impostato PostgreSQL in modo che faccia questi checkpoint meno frequentemente, distribuendoli nel tempo, allora si fatica con le impostazioni predefinite di Debian. Per la maggior parte delle distribuzioni Linux, la situazione \u00e8 cos\u00ec: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Cosa significa questo? Dalla versione 2.6 del kernel \u00e8 apparso un demonio per il flushing. Pdglush dipende da chi lo utilizza, ed \u00e8 responsabile dello svuotamento in background delle pagine sporche dal buffer del kernel e dello svuotamento quando necessario, senza eccezioni per liberare le pagine sporche, quando lo svuotamento in background non \u00e8 pi\u00f9 efficace. <\/p>\n
<\/p>\n
Quando avviene il background? Quando il 10% della memoria RAM totale presente sul server \u00e8 occupato da pagine sporche nel buffer del kernel, viene chiamata una funzione speciale di scrittura in background. Perch\u00e9 \u00e8 in background? Essa accetta come parametro quanti page scrivere. E, ad esempio, scrive N pagine. E per un certo periodo di tempo, questa cosa va in pausa. E poi torna e scrive ancora un certo numero di pagine. <\/p>\n
<\/p>\n
\u00c8 una storia estremamente semplice. La situazione \u00e8 come quella di una piscina, dove in un tubo si versa e nell'altro si immette. Abbiamo ricevuto un checkpoint e se ha inviato poche pagine sporche per l'eliminazione, queste si assorbiranno gradualmente dal kernel buffer pgflush. <\/p>\n
<\/p>\n
Se queste pagine sporche continuano ad accumularsi, si accumulano fino al 20%, dopodich\u00e9 il sistema operativo d\u00e0 priorit\u00e0 per scriverle su disco, perch\u00e9 se si interrompe l'alimentazione, avremo problemi. Ad esempio, perderemo questi dati. <\/p>\n
<\/p>\n
Qual \u00e8 il trucco? Il trucco consiste nel fatto che questi parametri, nel mondo moderno, del 20 e 10% della totale memoria RAM della macchina, sono totalmente spaventosi dal punto di vista della capacit\u00e0 di qualsiasi sistema di archiviazione che possediate.<\/strong> <\/p>\n<\/p>\n
Immaginate di avere 128 GB di RAM. 12,8 GB arrivano al vostro sistema di archiviazione. E qualunque cache o array abbiate, non ce la faranno a reggere. <\/p>\n
<\/p>\n
<\/p>\n
Pertanto, vi consigliamo di impostare immediatamente questi valori in base alle capacit\u00e0 del vostro controller RAID.<\/strong> Qui ho subito fornito una raccomandazione per un controller che ha 512 MB di cache. <\/p>\n<\/p>\n
\u00c8 tutto molto semplice. Puoi impostare vm.dirty_background in byte. Queste impostazioni annullano le due precedenti. O utilizzi il ratio di default, oppure se attivi quelli in byte, funzioneranno quelli in byte. Ma poich\u00e9 sono un consulente DBA e lavoro con diversi clienti, cerco sempre di essere prudente; quindi, se in byte, allora in byte. Nessuno ha garantito che un buon amministratore non aggiunga memoria al server, non lo riavvii, mentre il numero rimane lo stesso. Calcola semplicemente queste cifre, per essere sicuro che tutto ci stia. <\/p>\n
<\/p>\n
Cosa succede se non si riesce a entrare? \u00c8 scritto che qualsiasi flushing si ferma in modo efficace, ma in realt\u00e0 \u00e8 un modo di dire. Il sistema operativo ha un grosso problema: ha molte pagine sporche, quindi si ferma in modo efficace l'IO che generano i vostri clienti, cio\u00e8, quando un'applicazione invia una query SQL al database, essa aspetta. Qualsiasi input-output in esso ha la priorit\u00e0 pi\u00f9 bassa perch\u00e9 il database \u00e8 occupato con il checkpoint. E quando finir\u00e0 non \u00e8 chiaro. E quando raggiungete uno stato di flushing non in background, significa che tutto il vostro IO \u00e8 occupato da esso. E finch\u00e9 non termina, non farete nulla. <\/p>\n
<\/p>\n
Ci sono anche altri due punti importanti che vanno oltre questa relazione. Queste impostazioni devono corrispondere alle impostazioni in postgresql.conf, cio\u00e8 le impostazioni dei checkpoint. E il vostro sistema di dischi deve essere adeguatamente configurato. Se avete una cache su RAID, deve avere una batteria.<\/strong> La gente acquista RAID con una buona cache senza batteria. Se avete SSD in RAID, devono essere server-oriented e devono avere condensatori.<\/strong> Ecco un elenco di controlli dettagliati. A questo link trovi la mia presentazione su come configurare le prestazioni del disco in PostgreSQL. L\u00ec ci sono tutte queste liste di controllo. <\/p>\n<\/p>\n
<\/p>\n
Cosa pu\u00f2 complicare ulteriormente la vita? Ci sono due parametri. Sono relativamente nuovi. Possono essere attivati di default in diverse applicazioni. E possono rendere la vita molto pi\u00f9 difficile se non sono attivati correttamente. <\/p>\n
<\/p>\n
<\/p>\n
Ci sono due novit\u00e0. Sono gi\u00e0 presenti nei recenti kernel. Si tratta di sched_migration_cost in nanosecondi e sched_autogroup_enabled, che per default \u00e8 impostato su uno. <\/p>\n
<\/p>\n
E come rovinano la situazione? Cosa significa sched_migration_cost? Il gestore dei processi di Linux pu\u00f2 migrare un processo da una CPU a un'altra. E per PostgreSQL, che esegue query, la migrazione su un'altra CPU non ha assolutamente senso. Dal punto di vista del sistema operativo, quando si passa da OpenOffice al terminale, potrebbe anche andare bene, ma per un database \u2013 \u00e8 molto male.<\/strong> Pertanto, \u00e8 sensato impostare migration_cost su un valore piuttosto alto, almeno alcune migliaia di nanosecondi.<\/strong> <\/p>\n<\/p>\n
Cosa significher\u00e0 questo per il scheduler? Si considerer\u00e0 che durante questo tempo il processo sia ancora attivo. Cio\u00e8, se hai qualche transazione lunga che richiede tempo, il scheduler lo comprender\u00e0. Fino a quando non scade questo timeout, non sar\u00e0 necessario migrare questo processo altrove. Se il processo sta svolgendo un'attivit\u00e0, non verr\u00e0 migrato; continuer\u00e0 a funzionare sul CPU a cui \u00e8 stato assegnato. Il risultato sar\u00e0 eccellente. <\/p>\n
<\/p>\n
Il secondo aspetto \u00e8 l'autogruppo. \u00c8 una buona idea per workload specifici che non riguardano i database moderni: raggruppare i processi in base al terminale virtuale da cui sono stati avviati. Questo \u00e8 pratico per alcune attivit\u00e0. Nella pratica, PostgreSQL \u00e8 un sistema multiprocessore con prefork, avviato da un unico terminale. Avrai lock writer, checkpoint e tutte le tue richieste client saranno raggruppate su un unico scheduler, su un'unica CPU. Attendono insieme che questa si liberi, per non ostacolarsi a vicenda e rimanere occupati pi\u00f9 a lungo. Questa situazione non \u00e8 affatto necessaria in caso di questo tipo di carico di lavoro, quindi \u00e8 necessario disattivarla.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Il mio collega Alexey Lesovski ha condotto dei test con un semplice pgbench, aumentando di un ordine di grandezza il migration_cost e disattivando l'autogroup. La differenza su hardware scadente \u00e8 stata quasi del 10%.<\/strong>C'\u00e8 una discussione nella mailing list di Postgres, dove le persone riportano i risultati di come tali modifiche abbiano influito sulla velocit\u00e0 delle query. Hanno influito sul 50%.<\/strong>Ci sono molte storie simili.<\/p>\n<\/p>\n
<\/p>\n
E infine, riguardo alla politica di risparmio energetico. \u00c8 positivo che ora Linux possa essere usato su un laptop, promettendo di utilizzare bene la batteria. Ma si scopre che la stessa cosa pu\u00f2 valere anche per i server. <\/p>\n
<\/p>\n
Inoltre, se affittate server da qualche provider, i \"buoni\" provider<\/a> non si preoccupano di garantirvi prestazioni superiori. Il loro obiettivo \u00e8 massimizzare l'utilizzo dell'hardware. Pertanto, possono attivare per impostazione predefinita la modalit\u00e0 risparmio energetico del portatile sul sistema operativo.<\/p>\n<\/p>\n
Se usate sul server con un database ad alta intensit\u00e0 questo sistema, la vostra scelta deve essere acpi_cpufreq + performance. Anche con ondemand avrete gi\u00e0 dei problemi.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u2013 \u00e8 un driver leggermente diverso. Attualmente, si preferisce questo, in quanto \u00e8 pi\u00f9 recente e funziona meglio.<\/p>\n
<\/p>\n
Pertanto, il governor \u00e8 solo performance. Ondemand, powersave e simili non sono per voi. <\/p>\n
<\/p>\n
I risultati di explain analyze PostgreSQL possono variare di diversi ordini di grandezza se attivate powersave, poich\u00e9 praticamente il CPU sar\u00e0 schedulato in modo del tutto imprevedibile.<\/p>\n
<\/p>\n
Queste impostazioni possono essere attivate di default. Controllate attentamente se sono state abilitate di default. Questo pu\u00f2 essere davvero un grande problema. <\/p>\n
<\/p>\n
<\/p>\n
Infine, vorrei ringraziare i ragazzi del nostro team DBA PosgreSQL-Consulting, in particolare Max Boguk e Alexey Lesovsky, che ogni giorno imparano a gestire queste questioni. Cerchiamo di fare del nostro meglio per i nostri clienti, affinch\u00e9 tutto funzioni. \u00c8 come con le istruzioni di sicurezza aeree. Qui tutto \u00e8 scritto col sangue. Ogni dado \u00e8 stato scoperto durante un problema. Sono felice di condividerli con voi.<\/p>\n
<\/p>\n
Domande:<\/p>\n
<\/p>\n
Grazie! Se, ad esempio, un'azienda desidera risparmiare e ospitare su un unico server sia il database che la logica applicativa, o se segue la tendenza attuale verso architetture a microservizi in cui PostgreSQL viene eseguito in un container. Qual \u00e8 il vantaggio? Sysctl influisce globalmente su tutto il kernel. Non ho sentito parlare di sysctl che venga virtualizzato in modo che funzioni separatamente nei container. Esistono solo cgroup e l\u00ec il controllo \u00e8 limitato. Come si pu\u00f2 convivere con questo? Oppure, se desiderate performance, allora eseguite PostgreSQL su un server fisico dedicato e ottimizzatelo?<\/em><\/p>\n<\/p>\n
Abbiamo risposto alla vostra domanda in circa tre modi. Se non si tratta di un server fisico che pu\u00f2 essere ottimizzato, state tranquilli, tutto funzioner\u00e0 bene anche senza queste impostazioni. Se la vostra carico di lavoro \u00e8 tale da richiedere queste configurazioni, arriverete a un server fisico prima di dovervi preoccupare di queste impostazioni.<\/p>\n
<\/p>\n
Qual \u00e8 il problema? Se si tratta di una macchina virtuale, probabilmente avrai molti problemi, come ad esempio un'latency del disco piuttosto incoerente su molte macchine virtuali. Anche se la banda passante dei dischi \u00e8 buona, una transazione di input\/output che ha avuto problemi, che non incide molto sulla banda media, ma si verifica durante un checkpoint o durante la scrittura nel WAL, causer\u00e0 molti danni al database. E lo noterai prima di affrontare questi problemi. <\/p>\n
<\/p>\n
Se hai NGINX sullo stesso server, avrai lo stesso problema. Si contenderanno la memoria condivisa. E non arriverai ai problemi descritti qui.<\/p>\n
<\/p>\n
D'altra parte, alcuni di questi parametri saranno comunque rilevanti per te. Ad esempio, impostare dirty_ratio con sysctl per non avere un valore eccessivo \u2013 in ogni caso questo aiuter\u00e0. In ogni caso, avrai interazioni con il disco. E seguiranno uno schema errato. Questi sono i parametri default che ho mostrato. In ogni caso, \u00e8 meglio modificarli. <\/p>\n
<\/p>\n
Ci possono essere problemi con NUMA. VmWare, ad esempio, funziona bene con NUMA con impostazioni esattamente opposte. Qui si deve scegliere: server fisico o non fisico. <\/p>\n
<\/p>\n
Ho una domanda riguardo ad Amazon AWS. Hanno immagini preimpostate. Una di queste si chiama Amazon RDS. Ci sono impostazioni personalizzate per il loro sistema operativo?<\/em><\/p>\n<\/p>\n
Ci sono impostazioni, ma sono impostazioni diverse. Qui configuriamo il sistema operativo dal punto di vista di come il database utilizzer\u00e0 il tutto. L\u00ec ci sono parametri che determinano la direzione in cui dobbiamo andare, un tipo di shaping. Cio\u00e8, abbiamo bisogno di queste risorse, e ora le consumeremo. Dopo di che, Amazon RDS integra queste risorse e l\u00ec la performance diminuisce. Ci sono storie su come le persone iniziano a lavorare su questo. A volte anche con successo. Ma ci\u00f2 non riguarda le impostazioni del sistema operativo. \u00c8 come fare hacking sul cloud. \u00c8 un'altra storia.<\/p>\n
<\/p>\n
Perch\u00e9 le Transparent huge pages non producono effetti rispetto a Huge TLB?<\/em><\/p>\n<\/p>\n
Non lo danno. Si pu\u00f2 spiegare in molti modi, ma di fatto non lo danno. Qual \u00e8 la storia di PostgreSQL? All'avvio, riserva un grande pezzo di memoria condivisa. Se sono trasparenti o meno \u00e8 completamente irrilevante. Il fatto che vengano allocati all'avvio spiega tutto. E se c'\u00e8 molta memoria e bisogna ristrutturare il segmento di memoria condivisa, allora le Transparent huge pages diventano rilevanti. In PostgreSQL, questa memoria \u00e8 semplicemente allocata in un grande blocco all'avvio e basta, e poi non succede nulla di particolare. Si pu\u00f2 usare, certo, ma c'\u00e8 il rischio di ottenere una corruzione della memoria condivisa quando viene riallocato qualcosa. PostgreSQL non sa niente di questo.<\/p>\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Ottimizzazione](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n