Trascrizione di u rapportu 2015 di Ilya Kosmodemyansky "L'accordu di Linux per migliurà u rendiment di PostgreSQL"
Disclaimer: Aghju nutatu chì stu rapportu hè di nuvembre 2015 - più di 4 anni sò passati è assai tempu hè passatu. A versione 9.4 discutata in u rapportu ùn hè più supportata. In l'ultimi 4 anni, 5 novi versioni di PostgreSQL sò stati liberati, è 15 versioni di u kernel Linux sò stati liberati. Sè vo riscrive sti passaghji, vi finiscinu cu un rapportu differente. Ma quì cunsideremu sintonizzazioni Linux fundamentali per PostgreSQL, chì hè sempre pertinente oghje.
Mi chjamu Ilya Kosmodemyansky. U travagliu in PostgreSQL-Consulting. È avà parraraghju un pocu di ciò chì fà cù Linux in relazione à basa di dati in generale è PostgreSQL in particulare, perchè i principii sò assai simili.
Di chì parleremu ? Se cumunicate cù PostgreSQL, allora in qualchì puntu avete bisognu à esse un amministratore UNIX. Cosa significa? Se paragunemu Oracle è PostgreSQL, allora in Oracle avete bisognu à esse 80% amministratore di basa di dati DBA è 20% amministratore Linux.
Cù PostgreSQL hè un pocu più complicatu. Cù PostgreSQL, avete bisognu di capisce assai megliu cumu funziona Linux. È à u stessu tempu, corre un pocu dopu à a locomotiva, perchè ultimamente tuttu hè stata aghjurnata abbastanza bè. E novi kernel sò liberati, è appare una nova funziunalità, u rendiment migliurà, etc.
Perchè parlemu di Linux? Micca à tuttu perchè simu in a cunferenza Linux Petru, ma perchè in e cundizioni muderni unu di i sistemi operativi più ghjustificati per l'usu di basa di dati in generale è PostgreSQL in particulare hè Linux. Perchè FreeBSD, sfurtunatamenti, si sviluppa in una direzzione assai strana. È ci saranu prublemi sia cù u rendiment sia cù parechje altre cose. U funziunamentu di PostgreSQL in Windows hè in generale un problema seriu separatu, basatu annantu à u fattu chì Windows ùn hà micca a stessa memoria cumuna cum'è UNIX, mentri PostgreSQL hè tuttu ligatu à questu, perchè hè un sistema multi-processu.
E pensu chì tutti sò menu interessati à l'esotiche cum'è Solaris, allora andemu.
Una distribuzione Linux muderna hà più di 1 opzioni syctl, secondu cumu custruisce u kernel. À u listessu tempu, se fighjemu i diversi noci, pudemu aghjustà qualcosa in parechje manere. Ci sò paràmetri di u sistema di fugliale nantu à cumu si stallanu. Sè vo avete dumande nantu à cumu inizià: ciò chì attivà in u BIOS, cumu cunfigurà u hardware, etc.
Questu hè un voluminu assai grande chì pò esse discutitu annantu à parechji ghjorni, è micca in un rapportu brevi, ma avà mi fucalizza nantu à e cose impurtanti, cumu per evità quelli razzi chì sò garantiti per impediscenu di utilizà a vostra basa di dati bè in Linux si ùn li corregge micca. È à u listessu tempu, un puntu impurtante hè chì parechji paràmetri predeterminati ùn sò micca inclusi in i paràmetri chì sò curretti per a basa di dati. Questu hè, per difettu, travaglià pocu o micca in tuttu.
Chì miri di tuning tradiziunali ci sò in Linux? Pensu chì, postu chì tutti avete trattatu cù l'amministrazione Linux, ùn ci hè micca bisognu particulare di spiegà ciò chì i miri sò.
Pudete sintonizà:
- CPU.
- Memoria.
- Storage.
- Altru. Parlaremu di questu à a fine per un snack. Ancu, per esempiu, paràmetri cum'è a pulitica di risparmiu d'energia pò influenzà u rendiment in un modu assai imprevisible è micca u più piacevule.
Chì sò e specifiche di PostgreSQL è a basa di dati in generale? U prublema hè chì ùn pudete micca aghjustà alcuna noce individuale è vede chì u nostru rendimentu hà migliuratu significativamente.
Iè, ci sò tali gadgets, ma una basa di dati hè una cosa cumplessa. Interagisce cù tutte e risorse chì u servitore hà è preferisce interagisce à u massimu. Se fighjate à e raccomandazioni attuali di Oracle nantu à cumu utilizà un OS d'ospiti, serà cum'è u scherzu annantu à quellu cosmonauta mongolicu - alimenta u cane è ùn tocca nunda. Demu à a basa di dati tutte e risorse, a basa di dati stessu risolverà tuttu.
In principiu, in una certa misura a situazione hè esattamente a stessa cù PostgreSQL. A diffarenza hè chì a basa di dati ùn hè ancu capace di piglià tutte e risorse per ellu stessu, vale à dì in un locu à u nivellu di Linux chì avete bisognu di risolve tuttu.
L'idea principale ùn hè micca di selezziunà un unicu mira è cumincià à sintonizà, per esempiu, memoria, CPU o qualcosa cusì, ma per analizà a carica di travagliu è pruvate à migliurà u throughput quantu pussibule per chì a carica chì i boni programatori l'hà creatu. per noi, cumpresi i nostri utilizatori.
Eccu una stampa per spiegà ciò chì hè. Ci hè un buffer Linux OS è ci hè una memoria sparta è ci sò buffers spartuti PostgreSQL. PostgreSQL, à u cuntrariu di l'Oracle, travaglia direttamente solu à traversu u buffer di u kernel, vale à dì, per chì una pagina da u discu per entra in a so memoria cumuna, deve passà per u buffer di u kernel è torna, esattamente a stessa situazione.
I dischi campanu sottu à stu sistema. Aghju disegnatu questu cum'è dischi. In fatti, pò esse un controller RAID, etc.
È questu input-output in un modu o un altru passa per questa materia.
PostgreSQL hè una basa di dati classica. Ci hè una pagina dentru. È tutte l'input è u output si faci cù e pagine. Rilevamu blocchi in memoria cù pagine. È s'ellu ùn hè accadutu nunda, l'avemu lettu, dopu à pocu à pocu spariscenu da questa cache, da i buffers spartuti è finiscinu torna nantu à u discu.
Se rimpiazzamu qualcosa in qualchì locu, allora a pagina sana hè marcata cum'è brutta. I marcati quì in blu. È questu significa chì sta pagina deve esse sincronizata cù u almacenamentu di bloccu. Hè, quandu avemu fattu brutta, avemu fattu una entrata in WAL. È in un mumentu maravigliosu in u tempu, hè ghjuntu un fenomenu chjamatu checkpoint. È l'infurmazione hè stata arregistrata in questu logu chì era ghjuntu. È questu significa chì tutte e pagine brutte chì eranu quì à quellu mumentu in questi buffers spartuti sò stati sincronizati cù u discu di almacenamento cù fsync attraversu u buffer di u kernel.
Perchè questu hè fattu? Sè avemu persu voltage, tandu ùn avemu micca a situazione chì tutti i dati hè statu persu. A memoria persistente, chì tutti ci anu parlatu, hè finu à quì in a teoria di a basa di dati - questu hè un futuru brillanti, chì avemu, sicuru, strive for and we like it, ma per avà campanu in minus 20 anni. E, sicuru, tuttu questu deve esse monitoratu.
È u compitu di maximizà u throughput hè di fine-tune in tutte queste tappe per chì tuttu si move avanti è avanti rapidamente. A memoria sparta hè basicamente una cache di pagina. In PostgreSQL avemu mandatu una ricerca selezziunata o qualcosa, hà recuperatu questi dati da u discu. Finivanu in buffers spartuti. Per quessa, per questu per travaglià megliu, ci deve esse assai memoria.
Per fà tuttu questu per travaglià bè è rapidamente, avete bisognu di cunfigurà currettamente u sistema operatore in tutte e tappe. È sceglite un hardware equilibratu, perchè s'è vo avete un sbilanciamentu in un locu, pudete fà assai memoria, ma ùn serà micca servitu à una veloce abbastanza.
È andemu per ognunu di sti punti.
Per fà queste pagine viaghjà più veloce è avanti, avete bisognu di ottene u seguente:
- Prima, avete bisognu di travaglià più efficace cù a memoria.
- Siconda, sta transizione quandu e pagine da a memoria vanu à u discu deve esse più efficace.
- E terzu, ci deve esse boni dischi.
Se tenete 512 GB di RAM in u servitore è tuttu finisce nantu à un discu duru SATA senza cache, u servitore di basa di dati tutale diventa micca solu una zucca, ma una zucca cù una interfaccia SATA. Vi curriri in lu direttamente. È nunda ùn vi salverà.
Riguardu à u primu puntu cù a memoria, ci sò trè cose chì ponu fà a vita assai difficiule.
U primu di elli hè NUMA. NUMA hè una cosa chì hè fatta per migliurà u rendiment. Sicondu a carica di travagliu, diverse cose ponu esse ottimisate. È in a so nova forma attuale, ùn hè micca assai bonu per l'applicazioni cum'è e basa di dati chì utilizanu intensivamente i buffers spartuti di cache di pagina.
In poche parole. Cumu pudete sapè se qualcosa hè sbagliatu cù NUMA? Avete qualchì tipu di colpu spiacevoli, di colpu qualchì CPU hè sovraccaricatu. À u listessu tempu, analizà e dumande in PostgreSQL è vede chì ùn ci hè nunda di simile. Queste dumande ùn devenu esse cusì intensive in CPU. Pudete catturà questu per un bellu pezzu. Hè più faciule d'utilizà a ricunniscenza curretta da u principiu di cumu cunfigurà NUMA per PostgreSQL.
Chì succede veramente ? NUMA significa Accessu à Memoria Non Uniforme. Chì hè u puntu? Avete un CPU, vicinu à ellu ci hè a so memoria lucale. È questa interconnessione di memoria pò piglià memoria da altre CPU.
Si corre numactl --hardware, allora vi uttene un fogliu cusì grande. Frà altre cose, ci sarà un campu di distanze. Ci saranu numeri - 10-20, qualcosa cusì. Questi numeri ùn sò nunda di più cà u numeru di salpi per piglià sta memoria remota è l'utilizanu in u locu. In principiu, una bona idea. Questu accelerà a prestazione bè sottu una gamma di carichi di travagliu.
Avà imaginate chì avete una CPU prima chì prova d'utilizà a so memoria lucale, dopu pruvà à tirà una altra memoria via interconnessione per qualcosa. È questu CPU riceve tutta a vostra cache di pagina PostgreSQL - questu hè, alcuni gigabyte. Avete sempre u peghju casu, perchè in u CPU ci hè generalmente pocu memoria in quellu modulu stessu. È tutta a memoria chì hè servita passa per queste interconnessioni. Risulta lentu è tristu. È u vostru processatore chì serve stu node hè constantemente sovraccaricatu. È u tempu d'accessu di sta memoria hè male, lento. Questa hè a situazione chì ùn vulete micca sè vo aduprate questu per una basa di dati.
Per quessa, una opzione più curretta per a basa di dati hè per u sistema operatore Linux per ùn sapè micca ciò chì succede quì. Cusì chì accede à a memoria cum'è.
Perchè hè questu? Sembra chì deve esse l'inversu. Questu succede per un mutivu simplice: avemu bisognu di assai memoria per a cache di a pagina - decine, centinaie di gigabytes.
E se avemu attribuitu tuttu questu è cached i nostri dati quì, allora u guadagnu da l'usu di u cache serà significativamente più grande di u guadagnu da un accessu cusì complicatu à a memoria. È andemu cusì benefiziu incomparabilmente paragunatu à u fattu chì avemu da accede à a memoria più efficace cù NUMA.
Per quessa, ci sò dui avvicinamenti quì à u mumentu, finu à chì u futuru brillanti hè ghjuntu, è a basa di dati stessu ùn hè micca capaci di calculà quale CPU hè in esecuzione è induve deve tirà qualcosa.
Dunque, l'approcciu currettu hè di disattivà NUMA in tuttu, per esempiu, quandu rebooting. In a maiò parte di i casi, i winnings sò di tali ordini di grandezza chì a quistione di quale hè megliu ùn hè micca in tuttu.
Ci hè una altra opzione. Avemu aduprà più spessu di u primu, perchè quandu un cliente vene à noi per supportu, rebooting u servitore hè un grande affare per ellu. Hà un affari quì. È anu avutu prublemi per via di NUMA. Per quessa, pruvemu di disattivà in modi menu invasivi di reboot, ma attente à verificà chì hè disattivatu. Perchè, cum'è l'esperienza mostra, hè bonu chì disattivemu NUMA nantu à u prucessu parent PostgreSQL, ma ùn hè micca necessariu chì hà da travaglià. Avemu bisognu di verificà è vede chì ella hè veramente spenta.
Ci hè un bonu postu di Robert Haas. Questu hè unu di i committers PostgreSQL. Unu di i sviluppatori chjave di tutti i giblets di livellu bassu. E se seguite i ligami da questu post, descrizanu parechje storie culurite nantu à cumu NUMA hà fattu a vita difficiule per e persone. Fighjate, studià a lista di cuntrollu di l'amministratore di u sistema di ciò chì deve esse cunfiguratu nantu à u servitore per chì a nostra basa di dati funziona bè. Queste paràmetri deve esse scritte è verificate, perchè altrimente ùn serà micca assai bonu.
Per piacè nutate chì questu hè applicà à tutti i paràmetri chì vi parleraghju. Ma di solitu e basa di dati sò cullate in modu maestru-slave per a tolleranza di difetti. Ùn vi scurdate di fà sti paràmetri nantu à u schiavu perchè un ghjornu averete un accidentu è vi cambià à u schiavu è diventerà u maestru.
In una situazione d'urgenza, quandu tuttu hè assai male, u vostru telefunu sona in permanenza è u vostru capu vene in corsa cù un bastone grossu, ùn avete micca tempu per pensà à verificà. È i risultati ponu esse assai disastruosi.
U puntu dopu hè pagine enormi. E pagine enormi sò difficiuli di pruvà separatamente, è ùn ci hè nunda di fà, ancu s'ellu ci sò benchmarks chì ponu fà questu. Sò faciuli à Google.
Chì hè u puntu? Avete un servitore micca assai caru cù assai RAM, per esempiu, più di 30 GB. Ùn aduprate micca pagine enormi. Questu significa chì avete definitu sopra in termini di usu di memoria. È questu sopra hè luntanu da u più piacevule.
Perchè hè questu? Allora chì passa ? U sistema operatore allocate memoria in picculi pezzi. Hè cusì cunvene, hè cumu hè accadutu storicamente. È se andemu in dettagliu, u SO deve traduce l'indirizzi virtuali in quelli fisici. È questu prucessu ùn hè micca u più simplice, cusì u SO cache u risultatu di sta operazione in u Translation Lookaside Buffer (TLB).
E postu chì u TLB hè un cache, tutti i prublemi inerenti in un cache si sviluppanu in questa situazione. Prima, sè vo avete assai RAM è tuttu hè attribuitu in picculi pezzi, allora stu buffer diventa assai grande. È se u cache hè grande, allora a ricerca à traversu hè più lenta. Overhead hè sanu è ellu stessu occupa u spaziu, vale à dì chì a RAM hè cunsumata da qualcosa incorrecte. Sta volta.
Dui - u più u cache cresce in una tale situazione, u più prubabile hè chì avete a cache miss. È l'efficienza di sta cache diminuisce rapidamente cum'è a so dimensione aumenta. Dunque, i sistemi operativi sò stati cun un accostu simplice. Hè stata utilizata in Linux per un bellu pezzu. Hè apparsu in FreeBSD pocu tempu fà. Ma parlemu di Linux. Quessi sò pagine enormi.
È quì deve esse nutatu chì e pagine enormi, cum'è una idea, hè stata inizialmente spinta da e cumunità chì includenu Oracle è IBM, vale à dì i pruduttori di basa di dati pensanu fermamente chì questu seria utile ancu per e basa di dati.
E cumu si pò fà amici cù PostgreSQL? Prima, e pagine enormi deve esse attivate in u kernel Linux.
Siconda, devenu esse esplicitamente specificate da u paràmetru sysctl - quantu ci sò. I numeri quì sò da qualchì vechju servitore. Pudete calculà quanti buffers spartuti avete in modu chì e pagine enormi ponu adattà quì.
È se u vostru servitore tutale hè dedicatu à PostgreSQL, allora un bonu puntu di partenza hè di assignà o 25% di a RAM à i buffers spartuti, o 75% s'ellu hè sicuru chì a vostra basa di dati s'adattarà definitivamente in questu 75%. Puntu di partenza unu. E cunzidira, sè vo avete 256 GB di RAM, allora, per quessa, avete 64 GB di grande buffer. Calculate apprussimatamente cù un pocu di margine - ciò chì sta figura deve esse stabilita.
Prima di a versione 9.2 (se ùn sò micca sbagliatu, da a versione 8.2), era pussibule di cunnette PostgreSQL cù pagine enormi cù una biblioteca di terzu. È questu deve esse sempre fattu. Prima, avete bisognu di u kernel per esse capace di assignà e pagine enormi currettamente. È, in segundu, cusì chì l'applicazione chì travaglia cun elli ponu aduprà. Ùn serà micca solu utilizatu cusì. Siccomu PostgreSQL hà attribuitu memoria in u sistema 5 stile, questu puderia esse fattu cù libhugetlbfs - questu hè u nome cumpletu di a biblioteca.
In 9.3, u rendiment PostgreSQL hè statu migliuratu quandu u travagliu cù a memoria è u metudu di allocazione di memoria di u sistema 5 hè stata abbandunata. Tutti eranu assai cuntenti, perchè altrimenti pruvate à eseguisce duie istanze PostgreSQL in una macchina, è dice chì ùn aghju micca abbastanza memoria sparta. È dice chì sysctl deve esse currettu. È ci hè un tali sysctl chì avete sempre bisognu di reboot, etc. In generale, tutti eranu cuntenti. Ma l'allocazione di memoria mmap hà rottu l'usu di pagine enormi. A maiò parte di i nostri clienti utilizanu grandi buffer spartuti. È ricumandemu fermamente di ùn passà à 9.3, perchè u sopratuttu hà cuminciatu à esse calculatu in boni percentuali.
Ma a cumunità hà prestatu attenzione à questu prublema è in 9.4 anu riformulatu stu avvenimentu assai bè. È in 9.4 un paràmetru apparsu in postgresql.conf in quale pudete attivà pruvà, on o off.
Pruvate hè l'opzione più sicura. Quandu PostgreSQL principia, quandu attribuisce a memoria spartuta, prova à catturà sta memoria da e pagine enormi. È s'ellu ùn viaghja micca, allora torna à a selezzione normale. È se avete FreeBSD o Solaris, pudete pruvà, hè sempre sicuru.
Sì, allora simpricimenti ùn principia micca s'ellu ùn pudia micca selezziunate da e pagine enormi. Quì si tratta digià di quale è ciò chì hè più bellu. Ma s'è vo avete pruvatu, allora verificate chì avete veramente ciò chì avete bisognu, perchè ci hè assai spaziu per errore. Attualmente sta funziunalità funziona solu in Linux.
Una altra piccula nota prima di andà più in là. E pagine enormi trasparenti ùn sò micca ancora nantu à PostgreSQL. Ùn pò micca aduprà normalmente. È cù e pagine enormi trasparenti per una tale carica di travagliu, quandu un grande pezzu di memoria sparta hè necessariu, i benefici sò solu cù volumi assai grande. Sì avete terabyte di memoria allora questu pò entra in ghjocu. Se parlemu di più applicazioni di ogni ghjornu, quandu avete 32, 64, 128, 256 GB di memoria in a vostra macchina, allora u solitu pagine enormi hè Ok, è simpricimenti disattivemu Trasparente.
È l'ultima cosa di a memoria ùn hè micca direttamente ligata à fruitut, pò veramente arruvinà a vostra vita. Tuttu u throughput serà assai affettatu da u fattu chì u servitore hè constantemente scambiatu.
È questu serà assai dispiacevule in parechje manere. È u prublema principali hè chì i kernels muderni si cumportanu un pocu sfarente da i kernels Linux più vechji. E sta cosa hè abbastanza sgradevule per passà, perchè quandu parlemu di qualchì tipu di travagliu cù swap, finisce cù l'arrivu prematuru di l'OOM-killer. È l'OOM-killer, chì ùn hè micca ghjuntu in tempu puntuale è abbandunò PostgreSQL, hè sgradevule. Tuttu u mondu sanu di questu, vale à dì, finu à l'ultimu utilizatore.
Chì succede ? Avete una grande quantità di RAM quì, tuttu funziona bè. Ma per una certa ragione u servitore si ferma in swap è rallenta per quessa. Sembra chì ci hè assai memoria, ma questu succede.
In precedenza, avemu cunsigliatu di stabilisce vm.swappiness à zero, vale à dì disattivà u swap. Prima, pareva chì 32 GB di RAM è buffers spartuti currispondenti era una quantità enorme. U scopu principale di u swap hè di avè un locu per scaccià a crosta si cadiamu. È ùn era più particularmente cumpletu. È tandu chì ai da fà cù sta crosta ? Questu hè un compitu induve ùn hè micca chjaru perchè u scambiu hè necessariu, in particulare di una tale dimensione.
Ma in più muderni, vale à dì, a terza versione di u kernel, u cumpurtamentu hà cambiatu. È se mette u swap à zero, vale à dì disattivallu, allora prima o dopu, ancu s'ellu ci hè un pocu di RAM, un assassinu OOM vi venerà per tumbà i cunsumatori più intensivi. Perchè ellu hà da cunsiderà chì cù una tale carica di travagliu avemu sempre un pocu è saltaremu fora, vale à dì, micca per chjappà u prucessu di u sistema, ma per chjappà qualcosa di menu impurtante. Questu menu impurtante serà u cunsumadore intensivu di memoria spartuta, vale à dì u postmaster. È dopu chì serà bonu se a basa ùn deve esse restaurata.
Dunque, avà u predeterminatu, per quantu mi ricordu, a maiò parte di e distribuzioni sò in un locu intornu à 6, vale à dì à quale puntu duvete principià à aduprà swap secondu a quantità di memoria chì resta. Avà ricumandemu di stabilisce vm.swappiness = 1, perchè questu praticamenti l'apaga, ma ùn dà micca i stessi effetti cum'è cù un OOM-killer chì hè ghjuntu inesperu è uccisu tuttu.
Chì ci hè dopu ? Quandu parlemu di u funziunamentu di e basa di dati è pocu à pocu versu i dischi, tutti cumincianu à piglià a testa. Perchè a verità chì u discu hè lento è a memoria hè rapida hè familiar à tutti da a zitiddina. È ognunu sapi chì a basa di dati avarà prublemi di rendiment di discu.
U principale prublema di prestazione di PostgreSQL assuciatu à i punti di cuntrollu ùn si trova micca perchè u discu hè lento. Questu hè più prubabile per u fattu chì a memoria è a larghezza di banda di u discu ùn sò micca equilibrati. Tuttavia, ùn ponu micca esse equilibrati in parechji posti. PostgreSQL ùn hè micca cunfiguratu, u SO ùn hè micca cunfiguratu, u hardware ùn hè micca cunfiguratu è u hardware hè incorrectu. È stu prublema ùn succede micca solu s'ellu tuttu succede cum'è duverebbe, vale à dì o ùn ci hè micca carica, o i paràmetri è u hardware sò ben scelti.
Chì ghjè è ciò chì pare ? Di solitu e persone chì travaglianu cù PostgreSQL sò entrati in questa materia più di una volta. Spiegheraghju. Cumu l'aghju dettu, PostgreSQL periodicamente fa checkpoints per dump pagine brutte in memoria sparta à u discu. Se avemu una grande quantità di memoria sparta, allora u checkpoint principia à avè un impattu intensivu nantu à u discu, perchè dumps sti pagine cù fsync. Arriva in u buffer di u kernel è hè scrittu à i dischi cù fsync. È se u voluminu di questu affari hè grande, allora pudemu osservà un effettu dispiacevule, vale à dì una utilizazione assai grande di discu.
Quì aghju dui ritratti. Avà spiegheraghju ciò chì hè. Quessi sò dui grafici correlati in u tempu. U primu graficu hè l'utilizazione di u discu. Quì righjunghji quasi 90% à questu puntu in u tempu. Sì avete un fallimentu di basa di dati cù dischi fisici, cù un usu di u controller RAID à 90%, allora questu hè una mala nutizia. Questu significa chì un pocu più è ghjunghje à 100 è l'I / O si ferma.
Sì avete un array di discu, allora hè una storia un pocu sfarente. Dipende da cumu hè cunfiguratu, chì tipu di array hè, etc.
È in parallelu, un graficu da a vista interna di postgres hè cunfiguratu quì, chì dice cumu si verifica u puntu di cuntrollu. È u culore verde quì mostra quanti buffers, sti pagine brutte, in quellu mumentu ghjuntu à questu puntu di cuntrollu per a sincronizazione. È questu hè u principale chì avete bisognu di sapè quì. Videmu chì avemu assai pagine quì è in un certu puntu avemu culpitu u tavulu, vale à dì, avemu scrittu è scrittu, quì u sistema di discu hè chjaramente assai occupatu. È u nostru puntu di cuntrollu hà un impattu assai forte nantu à u discu. Ideale, a situazione duveria vede più cusì, vale à dì chì avemu avutu menu arregistramentu quì. È pudemu riparà cù i paràmetri per chì continuà à esse cusì. Vale à dì, u riciclamentu hè chjucu, ma in qualchì locu scrivemu qualcosa quì.
Chì ci vole à fà per superà stu prublema? Se avete firmatu IO sottu a basa di dati, questu significa chì tutti l'utilizatori chì sò ghjunti à cumpiendu e so dumande aspittàranu.
Se guardate da u puntu di vista di Linux, se avete pigliatu un bonu hardware, cunfiguratu currettamente, cunfiguratu PostgreSQL nurmalmente in modu chì faci questi punti di cuntrollu menu spessu, sparghje cù u tempu trà l'altri, allora entre in i paràmetri predeterminati di Debian. Per a maiò parte di e distribuzioni Linux, questu hè a stampa: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Cosa significa? Un dimòniu lampatu hè apparsu da u kernel 2.6. Pdglush, secondu quale hè usà quale, chì hè impegnatu in u sfondate di scartà di e pagine brutte da u buffer di u kernel è di scartà quandu hè necessariu di scaccià e pagine brutte ùn importa ciò chì, quandu u backgrouind discarding ùn aiuta micca.
Quandu vene u fondu? Quandu u 10% di a RAM tutale dispunibule nantu à u servitore hè occupatu da pagine brutte in u buffer di u kernel, una funzione speciale di scrittura hè chjamata in u fondu. Perchè hè u fondu? Cum'è un paràmetru, piglia in contu quante pagine per scrive. È, dicemu, scrive N pagine. È per un pezzu sta cosa s'addormenta. E poi torna torna è copia altre pagine.
Questa hè una storia estremamente simplice. U prublema quì hè cum'è cù una piscina, quandu si versa in una pipa, scorri in un altru. U nostru puntu di cuntrollu hè ghjuntu è s'ellu hà mandatu uni pochi di pagine brutte per scartà, dopu à pocu à pocu tuttu sarà risoltu bè da u buffer di kernel pgflush.
Se queste pagine brutte cuntinueghjanu à accumulà, accumulanu finu à u 20%, dopu chì a priorità OS hè di scrive tuttu u discu à u discu, perchè u putere falla è tuttu serà male per noi. Perdemu sti dati, per esempiu.
Chì hè u truccu ? U truccu hè chì questi paràmetri in u mondu mudernu sò 20 è 10% di a RAM tutale chì hè nantu à a macchina, sò assolutamente monstruosi in quantu à u throughput di qualsiasi sistema di discu chì avete.
Imagine chì avete 128 GB di RAM. 12,8 GB vene in u vostru sistema di discu. È ùn importa ciò chì cache avete quì, ùn importa ciò chì array avete quì, ùn durà micca tantu.
Dunque, ricumandemu chì aghjustate immediatamente questi numeri in basa di e capacità di u vostru controller RAID. Aghju fattu immediatamente una raccomandazione quì per un controller chì hà 512 MB di cache.
Tuttu hè cunsideratu assai simplice. Pudete mette vm.dirty_background in bytes. E sti paràmetri annullanu i dui precedenti. Sia u rapportu hè predeterminatu, o quelli chì anu byte sò attivati, allora quelli chì anu byte funzioneranu. Ma postu chì sò un cunsultante DBA è travaglià cù diversi clienti, pruvate di disegnà paglia è per quessa, se in byte, allora in byte. Nimu hà datu alcuna guaranzia chì un bon amministratore ùn aghjunghje micca più memoria à u servitore, reboot, è a figura ferma a stessa. Basta à calculà questi numeri in modu chì tuttu si mette in quì cù una guaranzia.
Chì succede s'ellu ùn ci si mette micca? Aghju scrittu chì ogni flussu hè efficacemente fermatu, ma in fattu hè una figura di discorsu. U sistema operatore hà un grande prublema - hà parechje pagine brutte, cusì l'IO chì i vostri clienti generanu hè efficacemente fermatu, vale à dì chì l'applicazione hè ghjunta à mandà una dumanda sql à a basa di dati, hè aspittendu. Ogni input / output à questu hè di a priorità più bassa, perchè a basa di dati hè occupata da un puntu di cuntrollu. È quandu ella finirà ùn hè micca chjaru. È quandu avete ottinutu un flussu senza fondo, significa chì tuttu u vostru IO hè occupatu da questu. È finu à ch'ella finisci, ùn fate nunda.
Ci sò dui punti più impurtanti quì chì sò fora di u scopu di stu rapportu. Queste paràmetri duveranu currisponde à i paràmetri in postgresql.conf, vale à dì i paràmetri di i punti di cuntrollu. È u vostru sistema di discu deve esse cunfiguratu bè. Se tenete una cache in un RAID, allora deve avè una bateria. A ghjente cumprà RAID cù una bona cache senza una bateria. Sì avete SSD in RAID, allora devenu esse servitori, ci anu da esse capacitori. Eccu una lista di cuntrollu detallata. Stu ligame cuntene u mo rapportu nantu à cumu cunfigurà un discu di rendiment in PostgreSQL. Ci sò tutte queste liste di cuntrollu.
Chì altru pò fà a vita assai difficiule? Quessi sò dui paràmetri. Sò relativamente novi. Per automaticamente, ponu esse inclusi in diverse applicazioni. È ponu fà a vita cum'è difficiule s'ellu sò attivati in modu incorrectu.
Ci sò dui cose relativamente novi. Sò digià apparsu in u terzu core. Questu hè sched_migration_cost in nanosecondi è sched_autogroup_enabled, chì hè unu per difettu.
E cumu arruvinanu a vostra vita ? Cosa hè sched_migration_cost? In Linux, u pianificatore pò migrà un prucessu da una CPU à l'altru. È per PostgreSQL, chì eseguisce dumande, a migrazione à un altru CPU ùn hè micca chjaru. Da u puntu di vista di u sistema operatore, quandu cambiate Windows trà openoffice è terminal, questu pò esse bonu, ma per una basa di dati questu hè assai male. Per quessa, una pulitica raghjone hè di stabilisce migration_cost à qualchì grande valore, almenu parechji milla nanosecondi.
Chì significà questu per u pianificatore? Ci sarà cunsideratu chì durante stu tempu u prucessu hè sempre calda. Questu hè, sè vo avete una transazzione longa chì hà fattu qualcosa per un bellu pezzu, u pianificatore capisce questu. Ellu assumerà chì, finu à questu tempu, ùn ci hè bisognu di migrà stu prucessu in ogni locu. Se à u stessu tempu u prucessu faci qualcosa, allora ùn serà micca migratu in ogni locu, travaglià in silenziu nantu à u CPU chì hè stata attribuita. È u risultatu hè eccellente.
U sicondu puntu hè autogroup. Ci hè una bona idea per carichi di travagliu specifichi chì ùn sò micca ligati à basa di dati muderni - questu hè di raggruppà i prucessi da u terminal virtuale da quale sò lanciati. Questu hè convenientu per certi travaglii. In pratica, PostgreSQL hè un sistema multi-processu cù un prefork chì corre da una sola terminal. Avete un scrittore di serratura, un puntu di cuntrollu, è tutte e vostre richieste di u cliente seranu raggruppati in un pianificatore, per CPU. È aspittàranu quì à l'unisonu ch'ellu sia liberu, per interferiscenu l'un à l'altru è mantenelu occupatu più longu. Questa hè una storia chì hè cumplettamente inutile in u casu di una tale carica è per quessa deve esse disattivata.
U mo cullega Alexey Lesovsky hà fattu teste cù un pgbench simplice, induve hà aumentatu migration_cost per un ordine di grandezza è hà disattivatu l'autogroup. A diffarenza nantu à u hardware cattivu era quasi 10%. Ci hè una discussione nantu à a lista di mailing postgres induve a ghjente dà risultati di cambiamenti simili à a velocità di dumanda influenzatu à 50%. Ci sò assai di tali storie.
È infine, nantu à a pulitica di risparmiu di energia. U bonu hè chì Linux pò avà esse usatu in un laptop. È suppostamente aduprà a bateria bè. Ma di colpu si trova chì questu pò ancu accade in u servitore.
Inoltre, se affittate servitori da qualchì hoster, allora i "boni" hosters ùn importa micca chì avete un rendimentu megliu. U so compitu hè di assicurà chì u so ferru hè utilizatu u più efficacemente pussibule. Dunque, per automaticamente, ponu attivà u modu di risparmiu di energia di u laptop in u sistema operatore.
Sè vo aduprate sta roba in un servitore cù una basa di dati sottu carica pesante, allora a vostra scelta hè acpi_cpufreq + permormance. Ancu cù a dumanda ci saranu prublemi.
Intel_pstate hè un driver un pocu sfarente. È avà a preferenza hè datu à questu, postu chì hè più tardi è travaglia megliu.
È, dunque, u guvernatore hè solu performance. Ondemand, powersave è tuttu u restu ùn sò micca nantu à voi.
I risultati di spiegà l'analisi PostgreSQL pò differisce da parechji ordini di grandezza se attivate u risparmiu di energia, perchè praticamenti u CPU sottu a vostra basa di dati serà in esecuzione in modu completamente imprevisible.
Questi elementi ponu esse inclusi per automaticamente. Fighjate attentamente per vede s'ellu l'anu attivatu per automaticamente. Questu pò esse un prublema veramente grande.
È à a fine, aghju vulsutu ringrazià à i ragazzi di a nostra squadra DBA di PosgreSQL-Consulting, à dì Max Boguk è Alexey Lesovsky, chì facenu progressi in questa materia ogni ghjornu. E pruvemu di fà u megliu chì pudemu per i nostri clienti in modu chì tuttu funziona per elli. Hè cum'è cù l'urdinamentu di sicurità di l'aviazione. Tuttu quì hè scrittu in sangue. Ognunu di sti noci si trova in u prucessu di qualchì tipu di prublema. Sò felice di sparte cun voi.
Domande:
Grazie! Se, per esempiu, una cumpagnia vole risparmià soldi è mette a basa di dati è a logica di l'applicazione nantu à un servitore, o se a cumpagnia seguita a tendenza di moda di l'architetture di microserviziu, in quale PostgreSQL corre in un containeru. Chì ghjè u truccu ? Sysctl affetterà tuttu u kernel in u mondu. Ùn aghju micca intesu parlà di i sysctls chì sò in qualchì modu virtualizatu in modu chì travaglianu separatamente in un containeru. Ci hè solu un cgroup è ci hè solu una parte di u cuntrollu. Cumu pudete campà cun questu? O se vulete u rendiment, allora eseguite PostgreSQL in un servitore hardware separatu è sintonizzalu?
Avemu rispostu a vostra dumanda in circa trè manere. Se ùn parlemu micca di un servitore hardware chì pò esse sintonizatu, etc., allora rilassate, tuttu funziona bè senza questi paràmetri. Sè vo avete una tale carica chì vi tuccherà à fà sti paràmetri, allura vi vene à u servore di ferru prima chè à sti paràmetri.
Chì ghjè u prublema ? S'ellu hè una macchina virtuale, u più prubabilmente avete assai prublemi, per esempiu, cù u fattu chì in a maiò parte di e macchine virtuale a latenza di u discu hè abbastanza inconsistente. Ancu s'è u passaghju di u discu hè bonu, allora una transazzione I / O falluta chì ùn hà micca influenzatu assai u throughput mediu chì hè accadutu à u mumentu di u checkpoint o à u mumentu di a scrittura à WAL, allora a basa di dati soffre assai da questu. È avete nutatu questu prima di andà in questi prublemi.
Sì avete NGINX in u stessu servitore, avete ancu avè u stessu prublema. Luttarà per a memoria spartuta. È ùn avete micca ghjunghje à i prublemi descritti quì.
Ma d'altra parte, certi di sti paràmetri seranu sempre pertinenti per voi. Per esempiu, stabilisce dirty_ratio cù sysctl in modu chì ùn hè micca cusì loca - in ogni casu, questu aiuterà. In un modu o un altru, avete interazzione cù u discu. È serà secondu u mudellu sbagliatu. Questu hè generalmente un default per i paràmetri chì aghju dimustratu. È in ogni casu, hè megliu cambià.
Ma ci ponu esse prublemi cù NUMA. VmWare, per esempiu, travaglia bè cù NUMA cù esattamente i paràmetri opposti. È quì avete a sceglie - un servitore di ferru o un servitore micca di ferru.
Aghju una quistione ligata à Amazon AWS. Hanu imagine pre-configurate. Unu di elli hè chjamatu Amazon RDS. Ci sò paràmetri persunalizati per u so sistema operatore?
Ci sò paràmetri, ma sò diverse paràmetri. Quì avemu cunfigurà u sistema operatore in quantu a basa di dati aduprà sta cosa. E ci sò paràmetri chì determinanu induve duvemu andà avà, cum'è a furmazione. Vale à dì, avemu bisognu di tanti risorsi, avemu avà da manghjà. Dopu questu, Amazon RDS stringe queste risorse, è u rendiment cala quì. Ci sò storii individuali di cumu a ghjente cumincianu à scherzà cù questa materia. Calchì volta ancu abbastanza successu. Ma questu ùn hà nunda di fà cù i paràmetri OS. Hè cum'è pirate u nuvulu. Hè una storia diversa.
Perchè e pagine enormi trasparenti ùn anu micca effettu cumparatu cù Huge TLB?
Ùn dà micca. Questu pò esse spiegatu in parechje manere. Ma in fatti, simpricimenti ùn dà micca. Chì ghjè a storia di PostgreSQL? À l'iniziu, attribuisce un grande pezzu di memoria sparta. Ch'elli sò trasparenti o micca, hè completamente irrilevante. U fattu chì si distinguenu à u principiu spiega tuttu. È s'ellu ci hè assai memoria è avete bisognu di ricustruisce u segmentu shared_memory, allora e pagine enormi trasparenti seranu pertinenti. In PostgreSQL, hè simpricimenti attribuitu in un pezzu enormu à l'iniziu è questu hè, è allora nunda di speciale succede quì. Pudete, sicuru, aduprà, ma ci hè una chance di ottene una corruzzione di shared_memory quandu ri-allocate qualcosa. PostgreSQL ùn sapi micca di questu.
Source: www.habr.com