Pertanto, l'approccio giusto \u00e8 disabilitare completamente NUMA<\/strong>, ad esempio, al riavvio. Nella maggior parte dei casi, i vantaggi sono tali da non lasciare alcun dubbio su quale sia la scelta migliore. <\/p>\n<\/p>\n
C'\u00e8 un'altra opzione. La utilizziamo pi\u00f9 spesso della prima, perch\u00e9 quando un cliente si rivolge a noi per assistenza, riavviare il server \u00e8 un grosso problema per lui. Ha un'attivit\u00e0 da gestire. E si trovano ad affrontare problemi a causa di NUMA. Pertanto, cerchiamo di disattivare il tutto in modi meno invasivi rispetto al reboot, ma qui dovete controllare attentamente che si sia realmente disattivato. Perch\u00e9, come dimostra l'esperienza, anche se disattiviamo il NUMA per il processo principale di PostgreSQL, ci\u00f2 \u00e8 buono, ma non \u00e8 affatto garantito che funzioni. \u00c8 necessario verificare e controllare che si sia effettivamente disattivato. <\/p>\n
<\/p>\n
C'\u00e8 un buon post di Robert Haas. \u00c8 uno dei committers di PostgreSQL. Uno dei principali sviluppatori di tutti i meccanismi a basso livello. E se seguite i link di quel post, troverete alcune storie colorite su come NUMA abbia complicato la vita a molte persone. Date un'occhiata, studiate la checklist per sistemisti, su cosa configurare nel server affinch\u00e9 il nostro database funzioni bene. Queste impostazioni devono essere annotate e verificate, perch\u00e9 altrimenti non andr\u00e0 affatto bene. <\/p>\n
<\/p>\n
Faccio presente che questo riguarda tutte le impostazioni di cui parler\u00f2. Ma di solito i database vengono configurati in modalit\u00e0 master-slave per garantire la resilienza. Non dimenticate di apportare queste configurazioni anche sullo slave, perch\u00e9 a un certo punto potreste subire un guasto, e passerete allo slave, che diventer\u00e0 master. <\/p>\n
<\/p>\n
In situazioni di emergenza, quando tutto va male, vi suoner\u00e0 continuamente il telefono e il vostro capo arriver\u00e0 con un grande bastone, non avrete tempo per pensare di controllare. E i risultati potrebbero essere molto disastrosi.<\/p>\n
<\/p>\n
<\/p>\n
Il punto successivo riguarda le huge pages. Le huge pages sono difficili da testare separatamente e non ha nemmeno senso farlo, anche se ci sono benchmark che sanno farlo. Si trovano facilmente su Google. <\/p>\n
<\/p>\n
Qual \u00e8 il significato? Avete un server non molto costoso, con molta RAM, ad esempio, oltre 30 GB. Non state utilizzando le huge pages. Questo significa che c'\u00e8 sicuramente un sovraccarico nell'uso della memoria. E questo sovraccarico \u00e8 tutt'altro che piacevole. <\/p>\n
<\/p>\n
<\/p>\n
Perch\u00e9 cos\u00ec? E cosa sta succedendo? Il sistema operativo assegna la memoria a piccoli pezzi. Cos\u00ec \u00e8 comodo, cos\u00ec \u00e8 storicamente avvenuto. E se approfondiamo, il sistema operativo deve tradurre gli indirizzi virtuali in indirizzi fisici. Questo processo non \u00e8 dei pi\u00f9 semplici, quindi il sistema operativo memorizza nella cache il risultato di questa operazione nel 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 viene allocata a piccoli chunk, questo buffer diventa molto grande. E se la cache \u00e8 grande, cercare in essa diventa pi\u00f9 lento. L'overhead \u00e8 significativo e occupa spazio, cio\u00e8 consuma una parte della RAM in modo inefficace. Questo \u00e8 il primo punto. <\/p>\n
<\/p>\n
Secondo \u2013 pi\u00f9 cresce la cache in questa situazione, maggiore \u00e8 la probabilit\u00e0 di avere cache misses. L'efficienza di questa cache diminuisce rapidamente all'aumentare delle sue dimensioni. Per questo motivo, i sistemi operativi hanno ideato un approccio semplice. In Linux \u00e8 utilizzato da tempo. In FreeBSD \u00e8 comparso abbastanza di recente. Ma stiamo parlando di Linux. Questi sono i huge pages.<\/p>\n
<\/p>\n
E qui va notato che i huge pages, come idea, sono stati inizialmente promossi da comunit\u00e0 che includevano Oracle e IBM, cio\u00e8 i produttori di database pensavano seriamente che potesse tornare utile anche per i database. <\/p>\n
<\/p>\n
<\/p>\n
E come si pu\u00f2 integrare con PostgreSQL? Innanzitutto, nel kernel di Linux devono essere abilitati i huge pages.<\/p>\n
<\/p>\n
In secondo luogo, devono essere esplicitamente indicati con il parametro sysctl \u2013 quanti ce ne sono. I numeri qui provengono da un vecchio server. Puoi calcolare quanti shared buffers hai circa, in modo che ci stiano i huge pages. <\/p>\n
<\/p>\n
E se hai dedicato l'intero server a PostgreSQL, un buon punto di partenza \u00e8 assegnare il 25% della RAM agli shared buffers, oppure il 75%, se sei sicuro che nel 75% ci star\u00e0 sicuramente il tuo database. Questo \u00e8 il primo punto di partenza. E calcola che, se hai 256 GB di RAM, avrai quindi circa 64 GB di shared buffers. Calcola circa con un certo margine \u2013 a quale cifra dovrebbe corrispondere.<\/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. Innanzitutto, \u00e8 fondamentale che il kernel sia in grado di allocare correttamente le huge pages. In secondo luogo, l'applicazione che lavora con queste deve poterle utilizzare. Non ci si pu\u00f2 semplicemente aspettare di utilizzarle. Poich\u00e9 PostgreSQL allocava memoria con lo stile system 5, questo era possibile grazie a libhugetlbfs \u2014 questo \u00e8 il nome completo della libreria.<\/p>\n
<\/p>\n
Nella versione 9.3 \u00e8 migliorata la gestione della memoria in PostgreSQL e si \u00e8 abbandonato il metodo di allocazione della memoria system 5. Tutti erano molto contenti, perch\u00e9 altrimenti, se provavi a lanciare due istanze di PostgreSQL sulla stessa macchina, ti diceva che la memoria condivisa era insufficiente. E ti indicava di modificare sysctl. E c'era un sysctl tale che bisognava anche riavviare, ecc. In generale, la contentezza era diffusa. Ma l'allocazione della memoria mmap ha compromesso l'uso delle huge pages. La maggior parte dei nostri clienti utilizza grandi shared buffers. E abbiamo fortemente raccomandato di non passare alla versione 9.3, perch\u00e9 l\u00ec l'overhead iniziava a essere calcolato in percentuali significative.<\/p>\n
<\/p>\n
Tuttavia, la community ha prestato attenzione a questo problema e nella versione 9.4 \u00e8 stata notevolmente rielaborata questa funzionalit\u00e0. Nella 9.4 \u00e8 stata introdotta un'opzione in postgresql.conf per abilitare try, on o off.<\/p>\n
<\/p>\n
Try \u00e8 l'opzione pi\u00f9 sicura. All'avvio di PostgreSQL, quando alloca memoria condivisa, cerca di ottenere questa memoria dalle huge pages. E se non ci riesce, torna all'allocazione normale. Se utilizzi FreeBSD o Solaris, puoi impostare try, \u00e8 sempre sicuro. <\/p>\n
<\/p>\n
Se on, semplicemente non si avvia se non riesce ad allocare dalle huge pages. Qui dipende da preferenze di ciascuno. Ma se hai impostato try, controlla che ci\u00f2 che deve essere allocato lo sia davvero, perch\u00e9 ci sono ampi margini di errore. Attualmente, questa funzionalit\u00e0 funziona solo su Linux.<\/p>\n
<\/p>\n
Un'altra piccola nota prima di procedere. Le Transparent huge pages non riguardano ancora PostgreSQL. Non possono essere utilizzate in modo adeguato. E con le Transparent huge pages, per un carico di lavoro del genere, dove \u00e8 necessario un grande blocco di memoria condivisa, i vantaggi si manifestano solo con volumi molto elevati. Se avete terabyte di memoria, allora questo pu\u00f2 avere un certo rilievo. Se parliamo di applicazioni pi\u00f9 comuni, dove avete 32, 64, 128, 256 GB di memoria sulla macchina, allora le huge pages normali vanno bene, mentre le Transparent devono essere disattivate. <\/p>\n
<\/p>\n
<\/p>\n
E l'ultima cosa riguardante la memoria, che non \u00e8 direttamente collegata al throughput, pu\u00f2 complicare molto le cose. L'intera capacit\u00e0 di throughput pu\u00f2 risentirne notevolmente se il server continua a fare swap. <\/p>\n
<\/p>\n
E questo sar\u00e0 davvero sgradevole in diverse circostanze. La difficolt\u00e0 principale \u00e8 che nei kernel moderni il comportamento \u00e8 leggermente diverso rispetto ai kernel Linux pi\u00f9 vecchi. E questa \u00e8 una problematica che pu\u00f2 essere piuttosto sgradevole, perch\u00e9 quando parliamo di un qualche lavoro con lo swap, si conclude con un'arrivo intempestivo dell'oom-killer. E l'oom-killer che arriva in ritardo e termina PostgreSQL \u00e8 davvero spiacevole. Questo lo sapranno tutti, cio\u00e8 fino all'ultimo utente. <\/p>\n
<\/p>\n
<\/p>\n
Cosa succede? Avete una grande quantit\u00e0 di memoria RAM, tutto funziona bene. Ma per qualche motivo, il server \u00e8 bloccato nello swap e ci\u00f2 causa rallentamenti. Sembrerebbe che ci sia sufficiente memoria, eppure succede. <\/p>\n
<\/p>\n
<\/p>\n
In passato consigliavamo di impostare vm.swappiness a zero, cio\u00e8 disattivare lo swap. Prima si pensava che 32 GB di memoria RAM e i relativi buffer condivisi fossero una quantit\u00e0 enorme. La principale funzione dello swap \u00e8 fornire uno spazio dove trasferire i processi se c'\u00e8 un errore. E questa funzione non veniva pi\u00f9 cos\u00ec frequentemente utilizzata. E cosa farai poi con quel processo? \u00c8 una questione non chiara sull'effettivo utilizzo dello swap, soprattutto di tali dimensioni. <\/p>\n
<\/p>\n
Ma nelle versioni pi\u00f9 moderne, ovvero nella terza versione del kernel, il comportamento \u00e8 cambiato. E se si imposta swap a zero, cio\u00e8 si disattiva, prima o poi, anche con una certa quantit\u00e0 di memoria RAM residua, l'OOM-killer arriver\u00e0 per uccidere i consumatori pi\u00f9 intensivi. Perch\u00e9 egli considerer\u00e0 che con un tale carico di lavoro ci rimane ancora un po' e noi rischiamo di esaurirci, quindi non uccider\u00e0 i processi di sistema, ma qualcosa di meno importante. Questo meno importante si riveler\u00e0 essere un consumatore intensivo di memoria condivisa, ovvero il postmaster. E dopo ci\u00f2 sar\u00e0 un bene se non sar\u00e0 necessario ripristinare il database. <\/p>\n
<\/p>\n
Quindi attualmente, se ricordo bene, la maggior parte delle distribuzioni ha un valore predefinito di circa 6, cio\u00e8 in quale momento iniziare a usare lo swap a seconda di quanta memoria \u00e8 rimasta. Adesso consigliamo di impostare vm.swappiness = 1, perch\u00e9 praticamente lo disattiva, ma non ha effetti simili a un OOM-killer che arriva inaspettatamente e termina tutto quanto.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Cosa c'\u00e8 dopo? Quando parliamo delle prestazioni dei database e ci avviciniamo progressivamente ai dischi, tutti iniziano a prendere a protezione la testa. Perch\u00e9 la verit\u00e0 che il disco \u00e8 lento e la memoria \u00e8 veloce \u00e8 conosciuta da tutti fin dall'infanzia. E tutti sanno che ci saranno problemi di prestazioni disco nel database.<\/p>\n
<\/p>\n
Il principale problema di prestazioni di PostgreSQL, legato ai picchi di checkpoint, non deriva dal fatto che il disco \u00e8 lento. \u00c8, piuttosto, che la capacit\u00e0 di memoria e disco non \u00e8 bilanciata. Inoltre, possono non essere bilanciate in modi diversi. PostgreSQL non \u00e8 configurato, il sistema operativo non \u00e8 configurato, l'hardware non \u00e8 configurato e l'hardware \u00e8 sbagliato. E questo problema non si verifica solo se tutto avviene come dovrebbe, cio\u00e8 o non ci sono carichi o le impostazioni e l'hardware sono ben scelti. <\/p>\n
<\/p>\n
<\/p>\n
Che cos'\u00e8 e come appare? Di solito, le persone che lavorano con PostgreSQL si sono gi\u00e0 imbattute in questo problema diverse volte. Spiegher\u00f2. Come ho detto, PostgreSQL esegue periodicamente dei checkpoints per scrivere le pagine sporche dalla memoria condivisa su disco. Se abbiamo un grande volume di memoria condivisa, il checkpoint inizia a influenzare intensamente il disco, poich\u00e9 scrive queste pagine utilizzando fsync. Esse arrivano nel buffer del kernel e vengono scritte sui dischi tramite fsync. E se il volume \u00e8 grande, possiamo osservare un effetto sgradevole, ovvero un'alta utilizzo dei dischi.<\/p>\n
<\/p>\n
Qui ho due immagini. Ora spiegher\u00f2 di cosa si tratta. Si tratta di due grafici correlati nel tempo. Il primo grafico rappresenta l'utilizzo del disco. A questo punto, raggiunge quasi il 90%. Se il vostro sistema di database ha dischi fisici, con un controller RAID che raggiunge un utilizzo vicino al 90%, sono brutte notizie. Significa che se continua, arriveremo al 100% e l'input-output si fermer\u00e0. <\/p>\n
<\/p>\n
Se avete un array di dischi, la storia \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 indicato il numero di buffer, queste pagine sporche, che sono arrivate in questo checkpoint per la sincronizzazione. Questo \u00e8 l'aspetto principale da sapere. Vediamo che sono arrivate molte pagine e a un certo punto ci siamo scontrati con il limite, cio\u00e8 abbiamo scritto tanto, e chiaramente il sistema disco \u00e8 molto occupato. Inoltre, il nostro checkpoint influisce notevolmente sul disco. Idealmente, la situazione dovrebbe apparire in modo diverso, cio\u00e8 con meno scritture. Possiamo ottimizzare le impostazioni per mantenere questa situazione. Cio\u00e8, un'utilizzazione bassa, ma scriviamo comunque da qualche parte. <\/p>\n
<\/p>\n
Cosa bisogna fare per risolvere questo problema? Se l'IO per il database si \u00e8 fermato, significa che tutti gli utenti che hanno tentato di eseguire le proprie query dovranno aspettare. <\/p>\n
<\/p>\n
<\/p>\n
Se si guarda dal punto di vista di Linux, se si dispone di un buon hardware, configurato correttamente, e se PostgreSQL \u00e8 impostato per eseguire i checkpoint meno frequentemente e distribuirli nel tempo, si utilizzano i parametri predefiniti di Debian. Per la maggior parte delle distribuzioni Linux, si presenta questa situazione: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Cosa significa questo? Con il kernel 2.6 \u00e8 apparso un demone per il flushing. Pdglush, a seconda di quale si utilizza, che si occupa del dumping in background delle pagine sporche dal kernel buffer e del dumping quando necessario, qualunque cosa accada, quando il dumping in background non \u00e8 pi\u00f9 utile. <\/p>\n
<\/p>\n
Quando inizia il background? Quando il 10% dell'intera memoria RAM disponibile sul server \u00e8 occupato da pagine sporche nel kernel buffer, viene chiamata una funzione speciale per il dumping in background. Perch\u00e9 \u00e8 in background? Essa accetta come parametro quante pagine dumpare. E, ad esempio, dumpa N pagine. E per un certo periodo di tempo questa funzione va in attesa. Poi ritorna e dumpa un altro certo numero di pagine. <\/p>\n
<\/p>\n
\u00c8 una storia estremamente semplice. Qui la questione \u00e8 simile a quella di una piscina, dove da un tubo esce acqua e in un altro entra. Abbiamo ricevuto un checkpoint e se ha inviato poche pagine sporche per il dumping, allora lentamente dal kernel buffer pgflush dissiperebbe tutto questo con attenzione. <\/p>\n
<\/p>\n
Se queste pagine sporche continuano ad accumularsi, si accumuleranno fino al 20%, dopo di che il sistema operativo ha la priorit\u00e0 di scriverle su disco, perch\u00e9 se si interrompe l'alimentazione, sar\u00e0 un problema. Perderemo questi dati, ad esempio. <\/p>\n
<\/p>\n
Qual \u00e8 il trucco? Il trucco \u00e8 che questi parametri nel mondo moderno, 20 e 10% dell'intera memoria RAM disponibile sulla macchina, sono assolutamente mostruosi in termini di throughput di qualsiasi sistema di archiviazione che si possieda.<\/strong> <\/p>\n<\/p>\n
Immagina di avere 128 GB di RAM. 12,8 GB arrivano al tuo sistema di archiviazione. E qualunque sia la cache o l'array che hai l\u00ec, non reggeranno cos\u00ec tanto. <\/p>\n
<\/p>\n
<\/p>\n
Pertanto, ti consigliamo di impostare immediatamente questi valori in base alle capacit\u00e0 del tuo controller RAID.<\/strong> Qui ho immediatamente fornito una raccomandazione per un controller che ha 512 MB di cache. <\/p>\n<\/p>\n
Si considera tutto molto semplice. Puoi impostare vm.dirty_background in byte. E queste impostazioni annullano le precedenti due. O il rapporto di default, oppure si attiveranno quelle che si basano sui byte, quindi funzioneranno quelle che utilizzano i byte. Ma poich\u00e9 sono un consulente DBA e lavoro con diversi clienti, cerco di prendere precauzioni e quindi, se in byte, allora in byte. Nessuno ha garantito che un buon admin non aggiunga memoria al server, non lo riavvii, e la cifra rimanga la stessa. Calcola semplicemente queste cifre, cos\u00ec da essere sicuro che tutto ci stia. <\/p>\n
<\/p>\n
Cosa succede se non riesci a rientrare? \u00c8 scritto che qualsiasi flushing si ferma efficacemente, ma in realt\u00e0 \u00e8 una figura retorica. Il sistema operativo ha un grosso problema: ha molte pagine sporche, quindi si interrompe efficacemente l'IO che generano i tuoi clienti, cio\u00e8, quando l'applicazione invia una query SQL al database, \u00e8 in attesa. Qualsiasi input-output in esso \u00e8 in priorit\u00e0 bassissima, perch\u00e9 il database \u00e8 occupato con il checkpoint. E quando lo terminer\u00e0 \u00e8 completamente incomprensibile. E quando hai raggiunto un flushing non in background, significa che tutto il tuo IO \u00e8 occupato da questo. E fino a quando non sar\u00e0 completato, non puoi fare nulla. <\/p>\n
<\/p>\n
Ci sono anche altri due aspetti importanti che esulano da questo rapporto. Queste impostazioni devono corrispondere alle impostazioni in postgresql.conf, cio\u00e8 le impostazioni dei checkpoint. E il tuo sistema di dischi deve essere adeguatamente configurato. Se hai una cache su RAID, deve avere una batteria.<\/strong> La gente acquista RAID con una buona cache senza batteria. Se hai SSD in RAID, devono essere di tipo server, e devono avere condensatori.<\/strong> Ecco una checklist dettagliata. A questo link c'\u00e8 la mia relazione su come configurare le prestazioni del disco in PostgreSQL. Ci sono tutte queste checklist. <\/p>\n<\/p>\n
<\/p>\n
Cosa pu\u00f2 rendere la vita molto pi\u00f9 complicata? Sono due parametri. Sono relativamente nuovi. Possono essere abilitati di default in diverse applicazioni. E possono complicare la vita non meno, se sono attivati in modo errato. <\/p>\n
<\/p>\n
<\/p>\n
Ci sono due elementi relativamente nuovi. Sono gi\u00e0 comparsi nei terzi kernel. Si tratta di sched_migration_cost in nanosecondi e sched_autogroup_enabled, che di default \u00e8 uno. <\/p>\n
<\/p>\n
E come rovinano la vita? Cos'\u00e8 sched_migration_cost? Il scheduler di Linux pu\u00f2 migrare un processo da una CPU all'altra. E per PostgreSQL, che esegue le query, la migrazione su un'altra CPU non \u00e8 affatto chiara. Dal punto di vista del sistema operativo, quando cambi le finestre tra OpenOffice e il terminale, questo pu\u00f2 essere positivo, ma per un database \u00e8 molto negativo.<\/strong> Quindi, \u00e8 sensato impostare migration_cost su un valore elevato, almeno alcune migliaia di nanosecondi.<\/strong> <\/p>\n<\/p>\n
Cosa significa questo per il scheduler? Considerer\u00e0 che per tutto questo tempo quel processo \u00e8 ancora \"caldo\". Cio\u00e8, se hai una transazione lunga che richiede tempo, il scheduler lo capir\u00e0. Considerer\u00e0 che fino a quando non scade il timeout, non \u00e8 necessario migrare quel processo. Se il processo sta compiendo qualche operazione, non verr\u00e0 migrato altrove, ma continuer\u00e0 a lavorare tranquillamente sulla CPU a lui assegnata. E il risultato sar\u00e0 eccellente. <\/p>\n
<\/p>\n
Un secondo punto \u00e8 l'autogroup. C'\u00e8 una buona idea per carichi di lavoro specifici che non hanno a che fare con i moderni database: raggruppare i processi in base al terminale virtuale da cui sono stati avviati. Questo \u00e8 comodo per certe attivit\u00e0. Nella pratica, PostgreSQL \u00e8 un sistema multiprocesso con prefork, che viene avviato da un unico terminale. Hai uno scrittore di lock, checkpoint e tutte le tue richieste client si raggrupperanno su un solo scheduler, su una sola CPU. E attenderanno l\u00ec amichevolmente che si liberi, per non disturbarsi a vicenda e occupare a lungo quella CPU. Questa \u00e8 una storia che non \u00e8 affatto necessaria per tale carico e quindi \u00e8 meglio disattivarla.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Il mio collega, Aleksey Lesovskiy, ha effettuato test con un semplice pgbench, dove aumentava drasticamente migration_cost e disattivava autogroup. La differenza su un hardware scadente \u00e8 stata quasi del 10%.<\/strong>C'\u00e8 una discussione nella mailing list di PostgreSQL dove le persone riportano risultati su come tali modifiche abbiano influito sulla velocit\u00e0 delle query per il 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 utilizzato su un laptop. E si dice che consuma bene la batteria. Ma improvvisamente si scopre che questo pu\u00f2 succedere anche su un server. <\/p>\n
<\/p>\n
Inoltre, se affitti server da qualche host, quegli \"amichevoli\" Inoltre, se prendi server in affitto da qualche provider di hosting, ci sono 'buoni'<\/a> non si prendono cura di far s\u00ec che tu abbia prestazioni migliori. Il loro obiettivo \u00e8 rendere il loro hardware il pi\u00f9 efficiente possibile. Pertanto, possono abilitare per impostazione predefinita la modalit\u00e0 di risparmio energetico per portatili nel sistema operativo.<\/p>\n<\/p>\n
Se utilizzi questo bene su un server con un database sottoposto a un carico intenso, la tua scelta \u00e8 acpi_cpufreq + performance. Anche con ondemand avrai problemi.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u00e8 gi\u00e0 un driver un po' diverso. Ora si d\u00e0 preferenza a questo, in quanto \u00e8 pi\u00f9 recente e funziona meglio.<\/p>\n
<\/p>\n
E, di conseguenza, il governor solo performance. Ondemand, powersave e tutto il resto non fa per te. <\/p>\n
<\/p>\n
I risultati di explain analyze di PostgreSQL possono variare di alcuni ordini di grandezza se abiliti powersave, poich\u00e9 praticamente la CPU verr\u00e0 gestita in modo del tutto imprevedibile.<\/p>\n
<\/p>\n
Queste cose possono essere abilitate per impostazione predefinita. Controlla attentamente se sono state abilitate di default. Questo pu\u00f2 rappresentare un problema davvero enorme. <\/p>\n
<\/p>\n
<\/p>\n
E alla fine volevo ringraziare i ragazzi del nostro team DBA PosgreSQL-Consulting, in particolare Max Bogu e Alexey Lesovski, che ogni giorno si imbattono in problemi in questo campo. Per i nostri clienti cerchiamo di fare il meglio possibile affinch\u00e9 tutto funzioni. \u00c8 come le istruzioni per la sicurezza aerea. Qui tutto \u00e8 scritto col sangue. Ognuno di questi bulloni \u00e8 stato scoperto in un determinato problema. Sono felice di condividerli con voi.<\/p>\n
<\/p>\n
Domande:<\/p>\n
<\/p>\n
Grazie! Se, ad esempio, un'azienda vuole risparmiare e ospitare su un unico server il database e la logica dell'applicazione, oppure se l'azienda segue la tendenza della microservizi, in cui PostgreSQL viene eseguito in un contenitore. Qual \u00e8 il problema? Sysctl influisce a livello globale su tutto il kernel. Non ho mai sentito parlare di sysctl che venga virtualizzato in modo che funzioni separatamente nel contenitore. Esistono solo cgroup e l\u00ec c'\u00e8 solo un controllo parziale. Come si pu\u00f2 convivere con questo? Oppure se vuoi prestazioni, esegui PostgreSQL su un server hardware dedicato e ottimizzalo?<\/em><\/p>\n<\/p>\n
Abbiamo risposto alla tua domanda in circa tre modi. Se non si tratta di un server fisico che pu\u00f2 essere ottimizzato, rilassati, funzioner\u00e0 bene anche senza queste impostazioni. Se ti trovi a dover gestire un carico tale da dover fare tali configurazioni, arriverai prima al server fisico che a queste impostazioni.<\/p>\n
<\/p>\n
Qual \u00e8 il problema? Se si tratta di una virtual machine, molto probabilmente avrai molti problemi, ad esempio con la latenza del disco, che \u00e8 piuttosto incoerente nella maggior parte delle virtual machine. Anche se la larghezza di banda dei dischi \u00e8 buona, un'operazione di input\/output che fallisce, che non influisce molto sulla capacit\u00e0 media, potrebbe accadere durante il checkpoint o durante la scrittura nel WAL, e il database ne risentir\u00e0. E lo noterai prima di confrontarti con questi problemi. <\/p>\n
<\/p>\n
Se hai NGINX sullo stesso server, avrai lo stesso problema. Si contender\u00e0 la memoria condivisa. E non arriverai ai problemi descritti qui.<\/p>\n
<\/p>\n
Tuttavia, alcuni di questi parametri saranno comunque rilevanti per te. Ad esempio, impostare dirty_ratio con sysctl affinch\u00e9 non sia cos\u00ec eccessivo - in ogni caso questo aiuter\u00e0. In ogni caso interagirai con il disco. E lo farai con uno schema non corretto. Questi parametri sono quelli predefiniti che ho mostrato. E in ogni caso \u00e8 meglio cambiarli. <\/p>\n
<\/p>\n
Ci possono essere problemi con NUMA. VmWare, ad esempio, funziona bene con NUMA con impostazioni esattamente opposte. Qui devi scegliere: server fisico o non fisico. <\/p>\n
<\/p>\n
Ho una domanda riguardante Amazon AWS. Hanno delle immagini preconfigurate. Una di esse si chiama Amazon RDS. Ci sono delle impostazioni personalizzate per il loro sistema operativo?<\/em><\/p>\n<\/p>\n
Ci sono delle impostazioni, ma sono altre impostazioni. Qui configuriamo il sistema operativo dal punto di vista di come il database utilizzer\u00e0 queste impostazioni. E ci sono parametri che definiscono in quale direzione procedere, come un shaping. Cio\u00e8, abbiamo bisogno di tante risorse e le utilizzeremo. Dopo ci\u00f2, Amazon RDS collega queste risorse e la prestazione diminuisce. Ci sono storie specifiche su come le persone cominciano a sperimentare con questo. A volte con successo. Ma questo non ha a che fare con le impostazioni del sistema operativo. \u00c8 una sorta di hacking del cloud. \u00c8 un'altra storia.<\/p>\n
<\/p>\n
Perch\u00e9 le Transparent huge pages non hanno effetto rispetto alle Huge TLB?<\/em><\/p>\n<\/p>\n
Non hanno effetto. Questo pu\u00f2 essere spiegato in molti modi. Ma di fatto non forniscono alcun vantaggio. Qual \u00e8 la storia di PostgreSQL? All'avvio, riserva un grande blocco di memoria condivisa. Che siano trasparenti o meno, non importa affatto. Il fatto che vengano allocate all'avvio spiega tutto. E se c'\u00e8 molta memoria e si deve ricostruire il segmento shared_memory, allora le Transparent huge pages saranno rilevanti. In PostgreSQL, sono semplicemente allocate come un grande blocco all'avvio e basta, non succede nient'altro di particolare successivamente. Certo, si pu\u00f2 usare, ma c'\u00e8 il rischio di ottenere una shared_memory corrotta quando verr\u00e0 riassegnato qualcosa. PostgreSQL non ne \u00e8 a conoscenza.<\/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