Ajust de Linux per millorar el rendiment de PostgreSQL. Ilya Kosmodemyansky

Transcripció de l'informe de 2015 d'Ilya Kosmodemyansky "Ajust de Linux per millorar el rendiment de PostgreSQL"

Exempció de responsabilitat: Tinc nota que aquest informe té la data de novembre de 2015: han passat més de 4 anys i ha passat molt de temps. La versió 9.4 que es parla a l'informe ja no és compatible. Durant els últims 4 anys, s'han llançat 5 noves versions de PostgreSQL i s'han publicat 15 versions del nucli Linux. Si reescriu aquests passatges, acabarà amb un informe diferent. Però aquí considerem l'ajustament fonamental de Linux per a PostgreSQL, que encara és rellevant avui dia.

Em dic Ilya Kosmodemyansky. Treballo a PostgreSQL-Consulting. I ara parlaré una mica de què fer amb Linux en relació a les bases de dades en general i PostgreSQL en particular, perquè els principis són força semblants.

De què parlarem? Si us comuniqueu amb PostgreSQL, fins a cert punt haureu de ser un administrador UNIX. Què vol dir? Si comparem Oracle i PostgreSQL, a Oracle heu de ser un 80% administrador de bases de dades DBA i un 20% administrador de Linux.

Amb PostgreSQL és una mica més complicat. Amb PostgreSQL cal que entengueu molt millor com funciona Linux. I al mateix temps, córrer una mica després de la locomotora, perquè últimament tot s'ha actualitzat força bé. I s'alliberen nous nuclis, apareixen noves funcionalitats, millora el rendiment, etc.

Per què parlem de Linux? En absolut perquè estem a la conferència Linux de Sant Petersburg, sinó perquè en condicions modernes un dels sistemes operatius més justificats per utilitzar bases de dades en general i PostgreSQL en particular és Linux. Perquè FreeBSD, malauradament, s'està desenvolupant en una direcció molt estranya. I hi haurà problemes tant amb el rendiment com amb moltes altres coses. El rendiment de PostgreSQL a Windows és generalment un problema greu a part, basat en el fet que Windows no té la mateixa memòria compartida que UNIX, mentre que PostgreSQL està tot lligat a això, perquè és un sistema multiprocés.

I crec que tothom està menys interessat en exòtics com Solaris, així que anem-hi.

Una distribució de Linux moderna té més de 1 opcions syctl, depenent de com es construeix el nucli. Al mateix temps, si mirem els diferents fruits secs, podem ajustar alguna cosa de moltes maneres. Hi ha paràmetres del sistema de fitxers sobre com muntar-los. Si teniu preguntes sobre com iniciar-lo: què habiliteu a la BIOS, com configurar el maquinari, etc.

Aquest és un volum molt gran que es pot discutir durant diversos dies, i no en un informe breu, però ara em centraré en coses importants, com evitar aquells rastres que estan garantits per evitar que utilitzeu bé la vostra base de dades a Linux si no els corregiu. I al mateix temps, un punt important és que molts paràmetres predeterminats no s'inclouen a la configuració correcta per a la base de dades. És a dir, per defecte funcionarà malament o no funcionarà gens.

Quins objectius de sintonització tradicionals hi ha a Linux? Crec que com que tots esteu tractant amb l'administració de Linux, no hi ha cap necessitat particular d'explicar quins són els objectius.

Podeu afinar:

• CPUs.
• Memòria.
• Emmagatzematge.
• Altres. D'això en parlarem al final per berenar. Fins i tot, per exemple, paràmetres com la política d'estalvi energètic poden afectar el rendiment d'una manera molt imprevisible i no de la manera més agradable.

Quines són les especificitats de PostgreSQL i de la base de dades en general? El problema és que no podeu modificar cap nou individual i veure que el nostre rendiment ha millorat significativament.

Sí, hi ha aquests aparells, però una base de dades és una cosa complexa. Interacciona amb tots els recursos que té el servidor i prefereix interactuar al màxim. Si mireu les recomanacions actuals d'Oracle sobre com utilitzar un sistema operatiu amfitrió, serà com la broma sobre aquest cosmonauta mongol: alimentar el gos i no tocar res. Donem a la base de dades tots els recursos, la pròpia base de dades ho ordenarà tot.

En principi, fins a cert punt la situació és exactament la mateixa amb PostgreSQL. La diferència és que la base de dades encara no és capaç d'aconseguir tots els recursos per si mateixa, és a dir, en algun lloc del nivell de Linux cal que ho resolgueu tot vosaltres mateixos.

La idea principal no és seleccionar un únic objectiu i començar a ajustar-lo, per exemple, memòria, CPU o alguna cosa així, sinó analitzar la càrrega de treball i intentar millorar el rendiment al màxim perquè la càrrega que els bons programadors el van crear. per a nosaltres, inclosos els nostres usuaris.

Aquí teniu una imatge per explicar què és. Hi ha un buffer del sistema operatiu Linux i hi ha memòria compartida i hi ha buffers compartits de PostgreSQL. PostgreSQL, a diferència d'Oracle, funciona directament només a través del buffer del nucli, és a dir, perquè una pàgina del disc entri a la seva memòria compartida, ha de passar pel buffer del nucli i tornar, exactament la mateixa situació.

Els discs viuen sota aquest sistema. Vaig dibuixar això com a discs. De fet, pot haver-hi un controlador RAID, etc.

I aquesta entrada-sortida d'una manera o altra passa per aquest assumpte.

PostgreSQL és una base de dades clàssica. Hi ha una pàgina dins. I totes les entrades i sortides es produeixen mitjançant pàgines. Estem aixecant blocs a la memòria amb pàgines. I si no passava res, només els llegim, i poc a poc desapareixen d'aquesta memòria cau, dels buffers compartits i acaben de nou al disc.

Si substituïm alguna cosa en algun lloc, la pàgina sencera es marcarà com a bruta. Els vaig marcar aquí en blau. I això vol dir que aquesta pàgina s'ha de sincronitzar amb l'emmagatzematge en bloc. És a dir, quan el vam embrutar, vam fer una entrada a WAL. I en un moment meravellós, va arribar un fenomen anomenat checkpoint. I en aquest registre hi constava informació que havia arribat. I això vol dir que totes les pàgines brutes que hi havia aquí en aquell moment en aquests buffers compartits es van sincronitzar amb el disc d'emmagatzematge mitjançant fsync a través del buffer del nucli.

Per què es fa això? Si perdíem voltatge, no ens vam trobar en la situació que es perdessin totes les dades. La memòria persistent, de la qual tothom ens va parlar, encara es troba en la teoria de les bases de dades: aquest és un futur brillant, que, per descomptat, ens esforcem i ens agrada, però de moment viuen en menys de 20 anys. I, per descomptat, tot això s'ha de controlar.

I la tasca de maximitzar el rendiment és ajustar totes aquestes etapes perquè tot es mogui ràpidament cap endavant i cap enrere. La memòria compartida és bàsicament una memòria cau de la pàgina. A PostgreSQL vam enviar una consulta de selecció o alguna cosa, va recuperar aquestes dades del disc. Van acabar en buffers compartits. En conseqüència, perquè això funcioni millor, cal que hi hagi molta memòria.

Perquè tot això funcioni bé i ràpidament, cal configurar correctament el sistema operatiu en totes les etapes. I trieu un maquinari equilibrat, perquè si teniu un desequilibri en algun lloc, podeu crear molta memòria, però no es donarà servei a la velocitat suficient.

I repassem cadascun d'aquests punts.

Per fer que aquestes pàgines es desplacen més ràpid d'anada i tornada, heu d'aconseguir el següent:

• En primer lloc, heu de treballar de manera més eficient amb la memòria.
• En segon lloc, aquesta transició quan les pàgines de la memòria passen al disc hauria de ser més eficient.
• I en tercer lloc, hi ha d'haver bons discs.

Si teniu 512 GB de RAM al servidor i tot acaba en un disc dur SATA sense cap memòria cau, aleshores tot el servidor de bases de dades es converteix no només en una carbassa, sinó en una carbassa amb una interfície SATA. Us hi trobareu directament. I res us salvarà.

Pel que fa al primer punt amb la memòria, hi ha tres coses que poden dificultar molt la vida.

El primer d'ells és NUMA. NUMA és una cosa que està feta per millorar el rendiment. Segons la càrrega de treball, es poden optimitzar diferents coses. I en la seva nova forma actual, no és gaire bo per a aplicacions com les bases de dades que utilitzen de manera intensiva els buffers compartits de memòria cau de pàgines.

En poques paraules. Com es pot saber si alguna cosa no funciona amb NUMA? Teniu algun tipus de cop desagradable, de sobte una part de la CPU està sobrecarregada. Al mateix temps, analitzeu les consultes a PostgreSQL i comproveu que no hi ha res semblant. Aquestes consultes no haurien de ser tan intensives en CPU. Podeu agafar això durant molt de temps. És més fàcil utilitzar la recomanació correcta des del principi sobre com configurar NUMA per a PostgreSQL.

Què està passant realment? NUMA significa Accés a la memòria no uniforme. Quin és el punt? Tens una CPU, al costat hi ha la seva memòria local. I aquesta interconnexió de memòria pot extreure memòria d'altres CPU.

Si corres numactl --hardware, llavors obtindreu un full tan gran. Entre altres coses, hi haurà un camp de distàncies. Hi haurà números: del 10 al 20, alguna cosa així. Aquests números no són més que el nombre de salts per recollir aquesta memòria remota i utilitzar-la localment. En principi, una bona idea. Això accelera molt el rendiment sota una sèrie de càrregues de treball.

Ara imagineu-vos que primer teniu una CPU que intenta utilitzar la seva memòria local i després intenta treure una altra memòria mitjançant la interconnexió per a alguna cosa. I aquesta CPU obté tota la memòria cau de la pàgina PostgreSQL: això és tot, alguns gigabytes. Sempre es troba el pitjor dels casos, perquè a la CPU normalment hi ha poca memòria en aquest mòdul. I tota la memòria que es dóna servei passa per aquestes interconnexions. Resulta lent i trist. I el vostre processador que dóna servei a aquest node està constantment sobrecarregat. I el temps d'accés d'aquesta memòria és dolent, lent. Aquesta és la situació que no voleu si ho feu servir per a una base de dades.

Per tant, una opció més correcta per a la base de dades és que el sistema operatiu Linux no sàpiga en absolut què hi passa. Perquè accedeixi a la memòria tal com ho fa.

Per què això? Sembla que hauria de ser al revés. Això passa per una senzilla raó: necessitem molta memòria per a la memòria cau de la pàgina: desenes, centenars de gigabytes.

I si hem assignat tot això i hem guardat les nostres dades a la memòria cau allà, el guany de l'ús de la memòria cau serà significativament més gran que el guany d'un accés tan complicat a la memòria. I així ens beneficiarem de manera incomparable en comparació amb el fet que accedirem a la memòria de manera més eficient mitjançant NUMA.

Per tant, hi ha dos enfocaments aquí en aquest moment, fins que ha arribat el brillant futur i la base de dades en si no és capaç d'esbrinar en quines CPU s'està executant i d'on ha de treure alguna cosa.

Per tant, l'enfocament correcte és desactivar NUMA completament, per exemple, quan es reinicia. En la majoria dels casos, els guanys són d'un ordre de magnitud tal que no es planteja la qüestió de quin és millor.

Hi ha una altra opció. El fem servir més sovint que el primer, perquè quan un client ve a nosaltres per demanar suport, reiniciar el servidor és un gran problema per a ell. Hi té un negoci. I experimenten problemes a causa de NUMA. Per tant, intentem desactivar-lo de maneres menys invasives que el reinici, però aneu amb compte de comprovar que estigui desactivat. Perquè, com mostra l'experiència, és bo que desactivem NUMA al procés pare PostgreSQL, però no és gens necessari que funcioni. Hem de comprovar i veure que realment es va apagar.

Hi ha un bon post de Robert Haas. Aquest és un dels committers de PostgreSQL. Un dels desenvolupadors clau de tots els menuts de baix nivell. I si seguiu els enllaços d'aquesta publicació, descriuen diverses històries acolorides sobre com NUMA va fer la vida difícil a la gent. Mira, estudia la llista de verificació de l'administrador del sistema del que cal configurar al servidor perquè la nostra base de dades funcioni bé. Aquests paràmetres s'han d'anotar i comprovar, perquè si no, no serà molt bo.

Tingueu en compte que això s'aplica a tots els paràmetres dels quals parlaré. Però normalment les bases de dades es recullen en mode mestre-esclau per a la tolerància a errors. No t'oblidis de fer aquests paràmetres a l'esclau perquè un dia tindràs un accident i canviaràs a l'esclau i aquest es convertirà en el mestre.

En una situació d'emergència, quan tot està molt malament, el teu telèfon sona constantment i el teu cap arriba corrent amb un pal gran, no tindreu temps per pensar en comprovar-ho. I els resultats poden ser força desastrosos.

El següent punt són pàgines enormes. Les pàgines enormes són difícils de provar per separat i no té sentit fer-ho, tot i que hi ha punts de referència que ho poden fer. Són fàcils de Google.

Quin és el punt? Tens un servidor no molt car amb molta memòria RAM, per exemple, més de 30 GB. No utilitzeu pàgines grans. Això vol dir que definitivament teniu una sobrecàrrega en termes d'ús de memòria. I aquesta sobrecàrrega està lluny de ser la més agradable.

Per què això? Aleshores, què està passant? El sistema operatiu assigna la memòria en petites peces. És tan convenient, és com va passar històricament. I si entrem en detall, el sistema operatiu ha de traduir adreces virtuals a físiques. I aquest procés no és el més senzill, de manera que el sistema operatiu guarda a la memòria cau el resultat d'aquesta operació a la memòria intermèdia de traducció (TLB).

I com que el TLB és una memòria cau, en aquesta situació sorgeixen tots els problemes inherents a una memòria cau. En primer lloc, si teniu molta memòria RAM i tot està assignat en petits trossos, aquest buffer es fa molt gran. I si la memòria cau és gran, la cerca és més lenta. La sobrecàrrega és saludable i ocupa espai, és a dir, la memòria RAM està sent consumida per alguna cosa incorrecta. Aquesta vegada.

Dos: com més creixi la memòria cau en aquesta situació, més probable és que tingueu errors de memòria cau. I l'eficiència d'aquesta memòria cau disminueix ràpidament a mesura que augmenta la seva mida. Per tant, els sistemes operatius van plantejar un enfocament senzill. S'ha utilitzat a Linux durant molt de temps. Va aparèixer a FreeBSD no fa gaire. Però estem parlant de Linux. Són pàgines enormes.

I aquí cal assenyalar que les pàgines enormes, com a idea, van ser impulsades inicialment per comunitats que incloïen Oracle i IBM, és a dir, els fabricants de bases de dades van pensar fermament que això també seria útil per a bases de dades.

I com es pot fer amistat amb PostgreSQL? En primer lloc, s'han d'habilitar pàgines enormes al nucli de Linux.

En segon lloc, s'han d'especificar explícitament pel paràmetre sysctl: quants n'hi ha. Els números aquí són d'algun servidor antic. Podeu calcular quants buffers compartits teniu perquè hi cabin pàgines grans.

I si tot el vostre servidor està dedicat a PostgreSQL, un bon punt de partida és assignar el 25% de la memòria RAM als buffers compartits o el 75% si esteu segur que la vostra base de dades s'adaptarà definitivament a aquest 75%. Punt de partida 256. I tingueu en compte que si teniu 64 GB de RAM, en conseqüència, tindreu XNUMX GB de buffers grans. Calculeu aproximadament amb un marge: en què s'hauria d'establir aquesta xifra.

Abans de la versió 9.2 (si no m'equivoco, des de la versió 8.2), era possible connectar PostgreSQL amb pàgines enormes mitjançant una biblioteca de tercers. I això s'ha de fer sempre. En primer lloc, necessiteu el nucli per poder assignar pàgines enormes correctament. I, en segon lloc, perquè l'aplicació que treballa amb ells els pugui utilitzar. No només s'utilitzarà d'aquesta manera. Com que PostgreSQL va assignar memòria a l'estil del sistema 5, això es podria fer amb libhugetlbfs: aquest és el nom complet de la biblioteca.

A la 9.3, el rendiment de PostgreSQL es va millorar quan es treballava amb memòria i es va abandonar el mètode d'assignació de memòria del sistema 5. Tothom estava molt content, perquè, en cas contrari, intenteu executar dues instàncies de PostgreSQL en una màquina, i diu que no tinc prou memòria compartida. I diu que sysctl s'ha de corregir. I hi ha un sysctl que encara cal reiniciar, etc. En general, tothom estava content. Però l'assignació de memòria mmap va trencar l'ús de pàgines enormes. La majoria dels nostres clients utilitzen grans buffers compartits. I recomanem fermament no canviar a 9.3, perquè les despeses generals es van començar a calcular en bons percentatges.

Però la comunitat va prestar atenció a aquest problema i a la 9.4 van reelaborar molt bé aquest esdeveniment. I a la 9.4 va aparèixer un paràmetre a postgresql.conf en el qual podeu habilitar try, on o off.

Provar és l'opció més segura. Quan s'inicia PostgreSQL, quan assigna memòria compartida, intenta agafar aquesta memòria de les grans pàgines. I si no funciona, tornarà a la selecció normal. I si teniu FreeBSD o Solaris, podeu provar, sempre és segur.

Si està activat, simplement no s'inicia si no es pot seleccionar de les grans pàgines. Aquí ja es tracta de qui i què és més agradable. Però si ho heu provat, comproveu que realment teniu el que necessiteu ressaltat, perquè hi ha molt marge d'error. Actualment aquesta funcionalitat només funciona a Linux.

Una petita nota més abans d'anar més enllà. Les pàgines enormes transparents encara no parlen de PostgreSQL. No els pot utilitzar amb normalitat. I amb les pàgines enormes Transparent per a aquesta càrrega de treball, quan es necessita una gran part de memòria compartida, els avantatges només vénen amb volums molt grans. Si teniu terabytes de memòria, això pot entrar en joc. Si estem parlant d'aplicacions més quotidianes, quan tens 32, 64, 128, 256 GB de memòria a la teva màquina, aleshores les pàgines enormes habituals estan bé, i simplement desactivem Transparent.

I l'última cosa de la memòria no està directament relacionada amb fruitut, realment pot arruïnar-te la vida. Tot el rendiment es veurà molt afectat pel fet que el servidor canvia constantment.

I això serà molt desagradable en diversos aspectes. I el principal problema és que els nuclis moderns es comporten de manera lleugerament diferent dels antics nuclis de Linux. I això és força desagradable de trepitjar, perquè quan parlem d'algun tipus de treball amb swap, s'acaba amb l'arribada prematura de l'OOM-killer. I l'OOM-killer, que no va arribar a temps i va deixar caure PostgreSQL, és desagradable. Tothom ho sabrà, és a dir, fins a l'últim usuari.

Que està passant? Tens una gran quantitat de memòria RAM allà, tot funciona bé. Però per alguna raó el servidor es penja en l'intercanvi i s'alenteix per això. Sembla que hi ha molta memòria, però això passa.

Anteriorment, aconsellàvem establir vm.swappiness a zero, és a dir, desactivar l'intercanvi. Anteriorment, semblava que 32 GB de RAM i els corresponents buffers compartits eren una quantitat enorme. L'objectiu principal de l'intercanvi és tenir un lloc on llençar l'escorça si caiem. I ja no es va complir especialment. I llavors què faràs amb aquesta crosta? Aquesta és una tasca en la qual no està molt clar per què és necessari l'intercanvi, sobretot d'aquesta mida.

Però en les versions més modernes, és a dir, les terceres versions del nucli, el comportament ha canviat. I si poseu l'intercanvi a zero, és a dir, desactiveu-lo, tard o d'hora, encara que quedi una mica de memòria RAM, us arribarà un assassí OOM per matar els consumidors més intensius. Perquè considerarà que amb tanta càrrega de treball encara ens queda una mica i saltarem, és a dir, no per clavar el procés del sistema, sinó per clavar una cosa menys important. Aquest menys important serà el consumidor intensiu de memòria compartida, és a dir, el director de correus. I després d'això serà bo si la base no s'ha de restaurar.

Per tant, ara per defecte, pel que recordo, la majoria de les distribucions es troben al voltant de 6, és a dir, en quin moment hauríeu de començar a utilitzar l'intercanvi en funció de la quantitat de memòria que quedi. Ara aconsellem establir vm.swappiness = 1, perquè això pràcticament l'apaga, però no dóna els mateixos efectes que amb un OOM-killer que va arribar inesperadament i ho va matar tot.

Que segueix? Quan parlem del rendiment de les bases de dades i a poc a poc avancem cap als discos, tothom comença a agafar el cap. Perquè la veritat que el disc és lent i la memòria ràpida és familiar per a tothom des de la infància. I tothom sap que la base de dades tindrà problemes de rendiment del disc.

El principal problema de rendiment de PostgreSQL associat als pics de punts de control no es produeix perquè el disc és lent. Això és probablement degut al fet que la memòria i l'amplada de banda del disc no estan equilibrades. Tanmateix, és possible que no estiguin equilibrats en diferents llocs. PostgreSQL no està configurat, el sistema operatiu no està configurat, el maquinari no està configurat i el maquinari és incorrecte. I aquest problema no només passa si tot passa com hauria de ser, és a dir, o no hi ha càrrega, o bé la configuració i el maquinari estan ben seleccionats.

Què és i quin aspecte té? Normalment, les persones que treballen amb PostgreSQL han entrat en aquest assumpte més d'una vegada. Ho explicaré. Com he dit, PostgreSQL fa periòdicament punts de control per bolcar les pàgines brutes de la memòria compartida al disc. Si tenim una gran quantitat de memòria compartida, el punt de control comença a tenir un impacte intensiu en el disc, perquè bolca aquestes pàgines amb fsync. Arriba a la memòria intermèdia del nucli i s'escriu als discs mitjançant fsync. I si el volum d'aquest negoci és gran, podem observar un efecte desagradable, és a dir, una utilització molt gran dels discs.

Aquí tinc dues imatges. Ara explicaré què és. Són dos gràfics relacionats amb el temps. El primer gràfic és la utilització del disc. Aquí arriba gairebé al 90% en aquest moment. Si teniu una fallada de la base de dades amb discs físics, amb una utilització del controlador RAID al 90%, aquesta és una mala notícia. Això vol dir que una mica més i arribarà a 100 i l'E/S s'aturarà.

Si teniu una matriu de discs, llavors és una història una mica diferent. Depèn de com estigui configurat, de quin tipus de matriu sigui, etc.

I en paral·lel, aquí es configura un gràfic de la vista interna de postgres, que indica com es produeix el punt de control. I el color verd aquí mostra quants buffers, aquestes pàgines brutes, van arribar en aquell moment a aquest punt de control per a la sincronització. I això és el més important que heu de saber aquí. Veiem que aquí tenim moltes pàgines i en algun moment ens toquem la pissarra, és a dir, vam escriure i escriure, aquí el sistema de discs està clarament molt ocupat. I el nostre punt de control té un impacte molt fort en el disc. Idealment, la situació hauria de semblar més a aquesta, és a dir, hem tingut menys gravació aquí. I ho podem arreglar amb la configuració perquè segueixi sent així. És a dir, el reciclatge és petit, però en algun lloc estem escrivint alguna cosa aquí.

Què cal fer per superar aquest problema? Si heu aturat l'IO a la base de dades, això significa que tots els usuaris que han vingut a complir les seves sol·licituds esperaran.

Si mireu des del punt de vista de Linux, si heu agafat un bon maquinari, l'heu configurat correctament, heu configurat PostgreSQL amb normalitat perquè faci aquests punts de control amb menys freqüència, els distribuïu al llarg del temps entre ells, aleshores entreu als paràmetres predeterminats de Debian. Per a la majoria de distribucions de Linux, aquesta és la imatge: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Què vol dir? Va aparèixer un dimoni enrogidor del nucli 2.6. Pdglush, depenent de qui faci servir quin, que es dedica a descartar en segon pla les pàgines brutes de la memòria intermèdia del nucli i a descartar quan sigui necessari descartar pàgines brutes, sigui el que passi, quan el descart de fons no ajuda.

Quan arriba el fons? Quan el 10% de la memòria RAM total disponible al servidor està ocupada per pàgines brutes a la memòria intermèdia del nucli, s'anomena una funció especial de cancel·lació en segon pla. Per què és de fons? Com a paràmetre, té en compte quantes pàgines cal esborrar. I, diguem-ne, esborra N pàgines. I durant una estona aquesta cosa s'adorm. I després torna a copiar algunes pàgines més.

Aquesta és una història extremadament senzilla. El problema aquí és com amb una piscina, quan aboca en una canonada, desemboca en una altra. Va arribar el nostre punt de control i si va enviar unes quantes pàgines brutes per descartar-les, a poc a poc tot es resoldrà perfectament des del buffer del nucli pgflush.

Si aquestes pàgines brutes continuen acumulant-se, s'acumulen fins a un 20%, després del qual la prioritat del sistema operatiu és esborrar-ho tot al disc, perquè fallarà l'alimentació i ens anirà tot malament. Perdrem aquestes dades, per exemple.

Quin és el truc? El truc és que aquests paràmetres al món modern són el 20 i el 10% de la memòria RAM total que hi ha a la màquina, són absolutament monstruosos pel que fa al rendiment de qualsevol sistema de disc que tingueu.

Imagineu que teniu 128 GB de RAM. Arriben 12,8 GB al vostre sistema de disc. I no importa la memòria cau que tingueu allà, no importa la matriu que hi tingueu, no duraran tant.

Per tant, us recomanem que ajusteu immediatament aquests números en funció de les capacitats del vostre controlador RAID. Immediatament vaig fer una recomanació aquí per a un controlador que tingui 512 MB de memòria cau.

Tot es considera molt senzill. Podeu posar vm.dirty_background en bytes. I aquests paràmetres cancel·len els dos anteriors. O la proporció és per defecte, o les que tenen bytes estan activades, aleshores les que tinguin bytes funcionaran. Però com que sóc consultor DBA i treballo amb diferents clients, intento dibuixar palletes i, per tant, si en bytes, en bytes. Ningú va garantir que un bon administrador no afegiria més memòria al servidor, el reiniciaria i la xifra es mantindria igual. Només cal calcular aquests números perquè tot hi encaixi amb una garantia.

Què passa si no encaixes? He escrit que qualsevol enrotllament s'atura efectivament, però de fet aquesta és una figura retòrica. El sistema operatiu té un gran problema: té moltes pàgines brutes, de manera que l'IO que generen els vostres clients s'atura efectivament, és a dir, l'aplicació ha arribat a enviar una consulta sql a la base de dades, està esperant. Qualsevol entrada/sortida té la prioritat més baixa, perquè la base de dades està ocupada per un punt de control. I quan acabarà no està del tot clar. I quan hàgiu aconseguit un flux sense fons, vol dir que tota la vostra IO està ocupada per ella. I fins que acabi, no faràs res.

Hi ha dos punts més importants aquí que estan fora de l'abast d'aquest informe. Aquesta configuració hauria de coincidir amb la configuració de postgresql.conf, és a dir, la configuració dels punts de control. I el vostre sistema de disc ha d'estar configurat adequadament. Si teniu una memòria cau en un RAID, ha de tenir una bateria. La gent compra RAID amb una bona memòria cau sense bateria. Si teniu SSD en RAID, han de ser de servidor, hi ha d'haver condensadors. Aquí teniu una llista de verificació detallada. Aquest enllaç conté el meu informe sobre com configurar un disc de rendiment a PostgreSQL. Hi ha totes aquestes llistes de control allà.

Què més pot fer la vida molt difícil? Aquests són dos paràmetres. Són relativament nous. Per defecte, es poden incloure en diferents aplicacions. I poden fer la vida igual de difícil si s'encenen incorrectament.

Hi ha dues coses relativament noves. Ja han aparegut als tercers nuclis. Això és sched_migration_cost en nanosegons i sched_autogroup_enabled, que és un per defecte.

I com t'arruïnen la vida? Què és sched_migration_cost? A Linux, el planificador pot migrar un procés d'una CPU a una altra. I per a PostgreSQL, que executa consultes, la migració a una altra CPU no està del tot clar. Des del punt de vista del sistema operatiu, quan canvieu windows entre openoffice i terminal, això pot ser bo, però per a una base de dades això és molt dolent. Per tant, una política raonable és establir migration_cost en un valor gran, almenys uns quants milers de nanosegons.

Què significarà això per al planificador? Es considerarà que durant aquest temps el procés encara està calent. És a dir, si teniu una transacció de llarga durada que ha estat fent alguna cosa durant molt de temps, el planificador ho entendrà. Assumirà que fins que passi aquest temps d'espera, no cal migrar aquest procés enlloc. Si al mateix temps el procés fa alguna cosa, aleshores no es migrarà enlloc, funcionarà en silenci a la CPU que se li va assignar. I el resultat és excel·lent.

El segon punt és l'agrupament automàtic. Hi ha una bona idea per a càrregues de treball específiques que no estiguin relacionades amb les bases de dades modernes; això és agrupar els processos pel terminal virtual des del qual es llancen. Això és convenient per a algunes tasques. A la pràctica, PostgreSQL és un sistema multiprocés amb un prefork que s'executa des d'un únic terminal. Teniu un escriptor de bloqueig, un punt de control i totes les vostres sol·licituds de client s'agruparan en un programador, per CPU. I allí esperaran a l'uníson que sigui lliure, per interferir entre ells i mantenir-lo ocupat més temps. Aquesta és una història que és completament innecessària en el cas d'aquesta càrrega i, per tant, s'ha d'apagar.

El meu col·lega Alexey Lesovsky va fer proves amb un pgbench senzill, on va augmentar el cost de migració en un ordre de magnitud i va desactivar l'autogrup. La diferència amb el maquinari dolent era gairebé el 10%. Hi ha una discussió a la llista de correu de postgres on la gent dóna resultats de canvis similars a la velocitat de la consulta influït en un 50%. Hi ha moltes històries així.

I, finalment, sobre la política d'estalvi d'energia. El millor és que Linux ara es pot utilitzar en un ordinador portàtil. I suposadament utilitzarà bé la bateria. Però de sobte resulta que això també pot passar al servidor.

A més, si llogueu servidors d'algun hoster, als hostes "bons" no els importa que tingueu un millor rendiment. La seva tasca és garantir que el seu ferro s'utilitza de la manera més eficient possible. Per tant, de manera predeterminada poden habilitar el mode d'estalvi d'energia del portàtil al sistema operatiu.

Si utilitzeu aquestes coses en un servidor amb una base de dades amb molta càrrega, la vostra elecció és acpi_cpufreq + permormance. Fins i tot amb la demanda hi haurà problemes.

Intel_pstate és un controlador lleugerament diferent. I ara es dóna preferència a aquest, ja que és més tard i funciona millor.

I, en conseqüència, el governador és només el rendiment. A la carta, l'estalvi d'energia i tota la resta no són sobre tu.

Els resultats d'explicar l'anàlisi de PostgreSQL poden diferir en diversos ordres de magnitud si activeu l'estalvi d'energia, perquè pràcticament la CPU de la vostra base de dades s'executarà d'una manera completament impredictible.

Aquests elements es poden incloure de manera predeterminada. Mireu amb atenció per veure si l'han activat de manera predeterminada. Això pot ser un problema molt gran.

I al final, volia donar les gràcies als nois del nostre equip DBA de PosgreSQL-Consulting, és a dir, Max Boguk i Alexey Lesovsky, que cada dia estan avançant en aquest assumpte. I intentem fer el millor possible pels nostres clients perquè tot funcioni per a ells. És com amb les instruccions de seguretat aeronàutica. Tot aquí està escrit amb sang. Cadascuna d'aquestes fruites seques es troba en el procés d'algun tipus de problema. Estic encantat de compartir-los amb vosaltres.

Preguntes:

Gràcies! Si, per exemple, una empresa vol estalviar diners i col·locar la base de dades i la lògica de l'aplicació en un sol servidor, o si l'empresa segueix la tendència de moda de les arquitectures de microserveis, en què PostgreSQL s'executa en un contenidor. Quin és el truc? Sysctl afectarà tot el nucli globalment. No he sentit que els sysctls es virtualitzin d'alguna manera perquè funcionin per separat en un contenidor. Només hi ha un grup c i només hi ha una part del control. Com pots viure amb això? O si voleu rendiment, executeu PostgreSQL en un servidor de maquinari independent i ajusteu-lo?

Vam respondre la teva pregunta d'aproximadament tres maneres. Si no estem parlant d'un servidor de maquinari que es pugui ajustar, etc., relaxeu-vos, tot funcionarà bé sense aquests paràmetres. Si teniu una càrrega tal que necessiteu fer aquests paràmetres, arribareu al servidor de ferro abans que aquests paràmetres.

Quin és el problema? Si es tracta d'una màquina virtual, el més probable és que tingueu molts problemes, per exemple, amb el fet que a la majoria de màquines virtuals la latència del disc és força inconsistent. Fins i tot si el rendiment del disc és bo, aleshores una transacció d'E/S fallida que no afecta molt el rendiment mitjà que es va produir en el moment del punt de control o en el moment d'escriure a WAL, la base de dades patirà molt d'això. I ho notareu abans de trobar-vos amb aquests problemes.

Si teniu NGINX al mateix servidor, també tindreu el mateix problema. Lluitarà per la memòria compartida. I no arribareu als problemes descrits aquí.

Però, d'altra banda, alguns d'aquests paràmetres encara seran rellevants per a vostè. Per exemple, configureu dirty_ratio amb sysctl perquè no sigui tan boig; en qualsevol cas, això us ajudarà. D'una manera o altra, tindreu interacció amb el disc. I serà segons el patró equivocat. Això és generalment un valor predeterminat per als paràmetres que he mostrat. I en tot cas és millor canviar-los.

Però pot haver-hi problemes amb NUMA. VmWare, per exemple, funciona bé amb NUMA amb la configuració exactament oposada. I aquí heu de triar: un servidor de ferro o un que no sigui de ferro.

Tinc una pregunta relacionada amb Amazon AWS. Tenen imatges preconfigurades. Un d'ells es diu Amazon RDS. Hi ha alguna configuració personalitzada per al seu sistema operatiu?

Hi ha configuracions, però són diferents. Aquí configurem el sistema operatiu en termes de com la base de dades utilitzarà aquesta cosa. I hi ha paràmetres que determinen cap a on hem d'anar ara, com ara el modelatge. És a dir, necessitem tants recursos que ara ens els menjarem. Després d'això, Amazon RDS reforça aquests recursos i el rendiment hi baixa. Hi ha històries individuals de com la gent comença a embolicar-se amb aquest tema. De vegades fins i tot amb força èxit. Però això no té res a veure amb la configuració del sistema operatiu. És com piratejar el núvol. Això és una història diferent.

Per què les pàgines enormes Transparent no tenen cap efecte en comparació amb Huge TLB?

No donis. Això es pot explicar de moltes maneres. Però de fet simplement no ho donen. Quina és la història de PostgreSQL? A l'inici, assigna una gran part de memòria compartida. Que siguin transparents o no és completament irrellevant. El fet que destaquin al principi ho explica tot. I si hi ha molta memòria i necessiteu reconstruir el segment shared_memory, les pàgines grans transparents seran rellevants. A PostgreSQL, simplement s'assigna en un gran tros al principi i ja està, i després no hi passa res especial. Per descomptat, podeu utilitzar-lo, però hi ha la possibilitat d'aconseguir una corrupció de shared_memory quan torna a assignar alguna cosa. PostgreSQL no ho sap.

Font: www.habr.com