Linux-tuning om de PostgreSQL-prestaties te verbeteren. Ilja Kosmodemjanski

Transcriptie van het rapport uit 2015 van Ilya Kosmodemyansky "Linux tuning om de PostgreSQL-prestaties te verbeteren"

Disclaimer: ik merk op dat dit rapport dateert van november 2015 - er zijn meer dan 4 jaar verstreken en er is veel tijd verstreken. De in het rapport besproken versie 9.4 wordt niet langer ondersteund. In de afgelopen vier jaar zijn er vijf nieuwe releases van PostgreSQL uitgebracht en zijn er vijftien versies van de Linux-kernel uitgebracht. Als je deze passages herschrijft, krijg je een ander rapport. Maar hier beschouwen we de fundamentele Linux-afstemming voor PostgreSQL, die vandaag de dag nog steeds relevant is.

Mijn naam is Ilya Kosmodemyansky. Ik werk bij PostgreSQL-Consulting. En nu zal ik het een beetje hebben over wat te doen met Linux in relatie tot databases in het algemeen en PostgreSQL in het bijzonder, omdat de principes vrij gelijkaardig zijn.

Waar zullen we het over hebben? Als u met PostgreSQL communiceert, moet u tot op zekere hoogte een UNIX-beheerder zijn. Wat betekent het? Als we Oracle en PostgreSQL vergelijken, moet je in Oracle 80% DBA-databasebeheerder en 20% Linux-beheerder zijn.

Met PostgreSQL is het iets ingewikkelder. Met PostgreSQL moet je een veel beter begrip hebben van hoe Linux werkt. En tegelijkertijd een stukje achter de locomotief aanrijden, want de laatste tijd is alles aardig bijgewerkt. En er worden nieuwe kernels uitgebracht en er verschijnt nieuwe functionaliteit, de prestaties verbeteren, enz.

Waarom hebben we het over Linux? Helemaal niet omdat we op de Linux-conferentie Peter zijn, maar omdat onder moderne omstandigheden Linux een van de meest gerechtvaardigde besturingssystemen is voor het gebruik van databases in het algemeen en PostgreSQL in het bijzonder. Omdat FreeBSD zich helaas in een heel vreemde richting ontwikkelt. En er zullen problemen zijn met zowel de prestaties als met veel andere dingen. De prestaties van PostgreSQL op Windows zijn over het algemeen een apart serieus probleem, gebaseerd op het feit dat Windows niet hetzelfde gedeelde geheugen heeft als UNIX, terwijl PostgreSQL hier allemaal aan verbonden is, omdat het een systeem met meerdere processen is.

En ik denk dat iedereen minder geïnteresseerd is in exoten als Solaris, dus laten we gaan.

Een moderne Linux-distributie heeft meer dan 1 syctl-opties, afhankelijk van hoe je de kernel bouwt. Tegelijkertijd kunnen we, als we naar de verschillende noten kijken, op veel manieren iets aanpassen. Er zijn bestandssysteemparameters over hoe u deze kunt mounten. Als u vragen heeft over hoe u het moet starten: wat u in het BIOS moet inschakelen, hoe u de hardware moet configureren, enz.

Dit is een heel groot deel dat over meerdere dagen kan worden besproken, en niet in één kort rapport, maar nu zal ik me concentreren op belangrijke dingen, hoe je die harken kunt vermijden die je gegarandeerd ervan weerhouden je database goed te gebruiken op Linux als je corrigeer ze niet. En tegelijkertijd is een belangrijk punt dat veel standaardparameters niet zijn opgenomen in de instellingen die correct zijn voor de database. Dat wil zeggen dat het standaard slecht of helemaal niet zal werken.

Welke traditionele afstemmingsdoelen zijn er in Linux? Ik denk dat, aangezien jullie allemaal te maken hebben met Linux-beheer, het niet specifiek nodig is om uit te leggen wat doelen zijn.

U kunt afstemmen:

• CPU.
• Geheugen.
• Storage.
• Ander. We praten hier aan het eind over bij een hapje. Zelfs parameters zoals het energiebesparingsbeleid kunnen de prestaties op een zeer onvoorspelbare en niet op de meest prettige manier beïnvloeden.

Wat zijn de specifieke kenmerken van PostgreSQL en de database in het algemeen? Het probleem is dat je geen individuele noot kunt aanpassen en zien dat onze prestaties aanzienlijk zijn verbeterd.

Ja, er zijn zulke gadgets, maar een database is complex. Het communiceert met alle bronnen die de server heeft en geeft er de voorkeur aan om ten volle te communiceren. Als je kijkt naar de huidige aanbevelingen van Oracle over het gebruik van een host-besturingssysteem, zal het lijken op de grap over die Mongoolse kosmonaut: voer de hond en raak niets aan. Laten we de database alle bronnen geven, de database zelf zal alles uitzoeken.

In principe is de situatie tot op zekere hoogte precies hetzelfde met PostgreSQL. Het verschil is dat de database nog niet alle bronnen voor zichzelf kan gebruiken, d.w.z. ergens op Linux-niveau moet je het allemaal zelf uitzoeken.

Het belangrijkste idee is niet om één enkel doel te selecteren en dit te gaan afstemmen, bijvoorbeeld geheugen, CPU of iets dergelijks, maar om de werklast te analyseren en te proberen de doorvoer zoveel mogelijk te verbeteren, zodat de belasting die goede programmeurs ervoor hebben gecreëerd voor ons, inclusief onze gebruikers.

Hier is een foto om uit te leggen wat het is. Er is een Linux OS-buffer, er is gedeeld geheugen en er zijn gedeelde PostgreSQL-buffers. PostgreSQL werkt, in tegenstelling tot Oracle, alleen rechtstreeks via de kernelbuffer, dat wil zeggen dat een pagina van de schijf, om in het gedeelde geheugen te komen, door de kernelbuffer moet gaan en terug, precies dezelfde situatie.

Schijven leven onder dit systeem. Ik heb dit getekend als schijven. In feite kan er een RAID-controller zijn, enz.

En deze input-output gebeurt op de een of andere manier via deze materie.

PostgreSQL is een klassieke database. Er zit een pagina in. En alle invoer en uitvoer vindt plaats via pagina's. We verhogen blokken in het geheugen met pagina's. En als er niets gebeurde, lezen we ze gewoon, waarna ze geleidelijk verdwijnen uit deze cache, uit de gedeelde buffers en weer op de schijf terechtkomen.

Als we ergens iets vervangen, wordt de hele pagina als vuil gemarkeerd. Ik heb ze hier blauw gemarkeerd. En dit betekent dat deze pagina moet worden gesynchroniseerd met blokopslag. Dat wil zeggen, toen we het vies maakten, hebben we een vermelding in WAL gemaakt. En op een prachtig moment deed zich een fenomeen voor dat checkpoint werd genoemd. En in dit logboek werd informatie vastgelegd dat hij was aangekomen. En dit betekent dat alle vuile pagina's die zich op dat moment in deze gedeelde buffers bevonden, werden gesynchroniseerd met de opslagschijf met behulp van fsync via de kernelbuffer.

Waarom wordt dit gedaan? Als we spanning verloren, kregen we niet de situatie dat alle gegevens verloren gingen. Persistent geheugen, waar iedereen ons over vertelde, is tot nu toe in de databasetheorie - dit is een mooie toekomst, waar we natuurlijk naar streven en we vinden het leuk, maar voorlopig leven ze over min 20 jaar. En dit alles moet uiteraard gemonitord worden.

En de taak van het maximaliseren van de doorvoer is om al deze fasen nauwkeurig af te stemmen, zodat alles snel heen en weer gaat. Gedeeld geheugen is in feite een paginacache. In PostgreSQL hebben we een selectiequery of zoiets verzonden, deze gegevens zijn van de schijf opgehaald. Ze kwamen in gedeelde buffers terecht. Om dit beter te laten werken, moet er dus veel geheugen zijn.

Om dit allemaal goed en snel te laten werken, moet u het besturingssysteem in alle fasen correct configureren. En kies voor gebalanceerde hardware, want als je ergens een onbalans hebt, dan kun je veel geheugen maken, maar het wordt niet met voldoende snelheid onderhouden.

En laten we elk van deze punten doornemen.

Om deze pagina's sneller heen en weer te laten reizen, moet u het volgende bereiken:

• Ten eerste moet u efficiënter met geheugen werken.
• Ten tweede zou deze overgang wanneer pagina's van het geheugen naar schijf gaan efficiënter moeten zijn.
• En ten derde moeten er goede schijven zijn.

Als je 512 GB RAM in de server hebt en dit komt allemaal op een SATA-harde schijf terecht zonder enige cache, dan verandert de hele databaseserver niet alleen in een pompoen, maar in een pompoen met een SATA-interface. Je wordt er direct mee geconfronteerd. En niets zal je redden.

Wat betreft het eerste punt met betrekking tot het geheugen: er zijn drie dingen die het leven erg moeilijk kunnen maken.

De eerste daarvan is NUMA. NUMA is iets dat is gemaakt om de prestaties te verbeteren. Afhankelijk van de werkdruk kunnen er verschillende zaken geoptimaliseerd worden. En in zijn nieuwe huidige vorm is het niet erg goed voor toepassingen zoals databases die intensief gebruik maken van gedeelde buffers voor paginacache.

In een notendop. Hoe kun je zien of er iets mis is met NUMA? Je krijgt een soort onaangename klop, plotseling wordt een CPU overbelast. Tegelijkertijd analyseer je queries in PostgreSQL en zie je dat daar niets vergelijkbaars bestaat. Deze zoekopdrachten zouden niet zo CPU-intensief moeten zijn. Je kunt dit lang opvangen. Het is gemakkelijker om vanaf het begin de juiste aanbeveling te gebruiken voor het configureren van NUMA voor PostgreSQL.

Wat is er echt aan de hand? NUMA staat voor Non-Uniform Memory Access. Wat is het punt? Je hebt een CPU, daarnaast bevindt zich het lokale geheugen. En deze geheugenverbindingen kunnen geheugen van andere CPU's ophalen.

Als je vlucht numactl --hardware, dan krijg je zo'n groot vel. Er komt onder andere een afstandenveld. Er zullen cijfers zijn - 10-20, zoiets. Deze cijfers zijn niets meer dan het aantal hops om dit externe geheugen op te halen en lokaal te gebruiken. In principe een goed idee. Dit versnelt de prestaties aanzienlijk onder verschillende werkbelastingen.

Stel je nu voor dat je een CPU hebt die eerst zijn lokale geheugen probeert te gebruiken en vervolgens via een interconnect voor iets een ander geheugen probeert op te halen. En deze CPU krijgt je volledige PostgreSQL-paginacache - dat is alles, enkele gigabytes. Je krijgt altijd het ergste geval, omdat er op de CPU meestal weinig geheugen in die module zelf zit. En al het geheugen dat wordt bediend, gaat via deze verbindingen. Het blijkt langzaam en verdrietig. En uw processor die dit knooppunt bedient, wordt voortdurend overbelast. En de toegangstijd van dit geheugen is slecht, traag. Dit is de situatie die u niet wilt als u dit voor een database gebruikt.

Daarom is een correctere optie voor de database dat het Linux-besturingssysteem helemaal niet weet wat daar aan de hand is. Zodat het toegang krijgt tot het geheugen zoals het dat doet.

Waarom is dat? Het lijkt erop dat het andersom zou moeten zijn. Dit gebeurt om een ​​simpele reden: we hebben veel geheugen nodig voor de paginacache - tientallen, honderden gigabytes.

En als we dit allemaal zouden toewijzen en onze gegevens daar in de cache zouden opslaan, zal de winst uit het gebruik van de cache aanzienlijk groter zijn dan de winst uit zo'n lastige toegang tot het geheugen. En we zullen dus onvergelijkbaar profiteren van het feit dat we efficiënter toegang krijgen tot het geheugen met behulp van NUMA.

Daarom zijn er momenteel twee benaderingen, totdat de mooie toekomst is aangebroken en de database zelf niet in staat is om erachter te komen op welke CPU's hij draait en waar hij iets uit moet halen.

Daarom is de juiste aanpak om NUMA helemaal uit te schakelenbijvoorbeeld bij het opnieuw opstarten. In de meeste gevallen zijn de winsten zo groot dat de vraag wat beter is helemaal niet rijst.

Er is nog een andere optie. We gebruiken het vaker dan de eerste, omdat wanneer een klant bij ons komt voor ondersteuning, het opnieuw opstarten van de server een groot probleem voor hem is. Hij heeft daar een bedrijf. En zij ondervinden problemen door NUMA. Daarom proberen we het op minder invasieve manieren uit te schakelen dan opnieuw opstarten, maar zorg ervoor dat u controleert of het is uitgeschakeld. Omdat het, zoals de ervaring leert, goed is dat we NUMA uitschakelen op het bovenliggende PostgreSQL-proces, maar het is helemaal niet nodig dat het werkt. We moeten controleren of ze echt is uitgeschakeld.

Er is een goed bericht van Robert Haas. Dit is een van de PostgreSQL-committers. Een van de belangrijkste ontwikkelaars van alle low-level ingewanden. En als je de links uit dit bericht volgt, beschrijven ze verschillende kleurrijke verhalen over hoe NUMA het leven van mensen moeilijk maakte. Kijk, bestudeer de checklist voor de systeembeheerder van wat er op de server moet worden geconfigureerd om onze database goed te laten werken. Deze instellingen moeten worden opgeschreven en gecontroleerd, omdat het anders niet zo goed is.

Houd er rekening mee dat dit geldt voor alle instellingen waar ik het over zal hebben. Maar meestal worden databases verzameld in de master-slave-modus voor fouttolerantie. Vergeet niet deze instellingen op de slave te maken, want op een dag krijg je een ongeluk en schakel je over naar de slave en wordt deze de master.

In een noodsituatie, als alles heel slecht is, je telefoon voortdurend rinkelt en je baas met een grote stok aan komt rennen, heb je geen tijd om na te denken over het controleren. En de gevolgen kunnen behoorlijk desastreus zijn.

Het volgende punt zijn enorme pagina's. Enorme pagina's zijn moeilijk afzonderlijk te testen, en dat heeft geen zin, hoewel er benchmarks zijn die dit wel kunnen. Ze zijn gemakkelijk te Googlen.

Wat is het punt? Je hebt een niet heel dure server met veel RAM, bijvoorbeeld meer dan 30 GB. Je gebruikt geen grote pagina's. Dit betekent dat je zeker overhead hebt op het gebied van geheugengebruik. En deze overhead is verre van de meest aangename.

Waarom is dat? Dus wat is er aan de hand? Het besturingssysteem wijst geheugen in kleine stukjes toe. Het is zo handig, het is hoe het historisch gebeurde. En als we in detail treden, moet het besturingssysteem virtuele adressen vertalen naar fysieke. En dit proces is niet het eenvoudigste, dus slaat het besturingssysteem het resultaat van deze bewerking op in de Translation Lookaside Buffer (TLB).

En aangezien de TLB een cache is, ontstaan ​​in deze situatie alle problemen die inherent zijn aan een cache. Ten eerste: als je veel RAM hebt en dit allemaal in kleine stukjes is toegewezen, wordt deze buffer erg groot. En als de cache groot is, gaat het zoeken er langzamer doorheen. Overhead is gezond en neemt zelf ruimte in beslag, d.w.z. RAM wordt verbruikt door iets dat niet klopt. Deze keer.

Twee: hoe meer de cache in een dergelijke situatie groeit, hoe waarschijnlijker het is dat je cache-missers zult hebben. En de efficiëntie van deze cache neemt snel af naarmate de omvang ervan toeneemt. Daarom bedachten besturingssystemen een eenvoudige aanpak. Het wordt al heel lang in Linux gebruikt. Het verscheen nog niet zo lang geleden in FreeBSD. Maar we hebben het over Linux. Dit zijn enorme pagina's.

En hier moet worden opgemerkt dat enorme pagina's, als idee, aanvankelijk werden gepromoot door gemeenschappen waartoe ook Oracle en IBM behoorden, dat wil zeggen dat databasefabrikanten er sterk van overtuigd waren dat dit ook nuttig zou zijn voor databases.

En hoe kan dit vrienden worden met PostgreSQL? Ten eerste moeten grote pagina's worden ingeschakeld in de Linux-kernel.

Ten tweede moeten ze expliciet worden gespecificeerd door de parameter sysctl - hoeveel er zijn. De cijfers hier zijn van een oude server. Je kunt berekenen hoeveel gedeelde buffers je hebt, zodat daar enorme pagina's in passen.

En als je hele server is toegewijd aan PostgreSQL, dan is een goed uitgangspunt om 25% van het RAM-geheugen toe te wijzen aan gedeelde buffers, of 75% als je zeker weet dat je database zeker in deze 75% zal passen. Uitgangspunt één. En bedenk: als je 256 GB RAM hebt, dan heb je dienovereenkomstig 64 GB aan grote buffers. Bereken ongeveer met enige marge waar dit cijfer op moet worden ingesteld.

Vóór versie 9.2 (als ik me niet vergis, sinds versie 8.2) was het mogelijk om PostgreSQL te verbinden met grote pagina's met behulp van een bibliotheek van derden. En dit moet altijd gedaan worden. Ten eerste heb je de kernel nodig om grote pagina's correct toe te kunnen wijzen. En ten tweede zodat de applicatie die ermee werkt, ze kan gebruiken. Het zal niet alleen op die manier worden gebruikt. Omdat PostgreSQL geheugen toewees in de systeem 5-stijl, kon dit worden gedaan met behulp van libhugetlbfs - dit is de volledige naam van de bibliotheek.

In 9.3 waren de prestaties van PostgreSQL verbeterd bij het werken met geheugen en werd de geheugentoewijzingsmethode van systeem 5 verlaten. Iedereen was heel blij, want anders probeer je twee PostgreSQL-instanties op één machine te draaien, en hij zegt dat ik niet genoeg gedeeld geheugen heb. En hij zegt dat sysctl gecorrigeerd moet worden. En er is zo'n sysctl dat je nog steeds opnieuw moet opstarten, enz. Over het algemeen was iedereen blij. Maar mmap-geheugentoewijzing verbrak het gebruik van grote pagina's. De meeste van onze klanten maken gebruik van grote gedeelde buffers. En we raden ten zeerste aan om niet over te stappen naar 9.3, omdat de overhead daar in goede percentages begon te worden berekend.

Maar de gemeenschap besteedde aandacht aan dit probleem en in 9.4 hebben ze deze gebeurtenis heel goed herwerkt. En in 9.4 verscheen er een parameter in postgresql.conf waarin je try aan of uit kunt zetten.

Proberen is de veiligste optie. Wanneer PostgreSQL start en gedeeld geheugen toewijst, probeert het dit geheugen van de enorme pagina's te halen. En als het niet werkt, keert het terug naar de normale selectie. En als u FreeBSD of Solaris heeft, kunt u het proberen, het is altijd veilig.

Indien ingeschakeld, start het simpelweg niet als het niet kan selecteren uit de enorme pagina's. Hier gaat het al over wie en wat leuker is. Maar als je het hebt geprobeerd, controleer dan of je echt hebt wat je nodig hebt, omdat er veel ruimte is voor fouten. Momenteel werkt deze functionaliteit alleen op Linux.

Nog een kleine opmerking voordat we verder gaan. Transparante grote pagina's gaan nog niet over PostgreSQL. Hij kan ze niet normaal gebruiken. En met transparante grote pagina's voor zo'n werklast, wanneer een groot stuk gedeeld geheugen nodig is, komen de voordelen alleen met zeer grote volumes. Als je terabytes aan geheugen hebt, kan dit een rol spelen. Als we het hebben over meer alledaagse applicaties, als je 32, 64, 128, 256 GB geheugen op je machine hebt, dan zijn de gebruikelijke grote pagina's oké, en schakelen we eenvoudigweg Transparent uit.

En het laatste aan geheugen heeft niet direct te maken met fruit, het kan je leven echt verpesten. Alle doorvoer zal sterk worden beïnvloed door het feit dat de server voortdurend aan het wisselen is.

En dit zal in een aantal opzichten zeer onaangenaam zijn. En het grootste probleem is dat moderne kernels zich enigszins anders gedragen dan oudere Linux-kernels. En dit ding is nogal onaangenaam om op te stappen, want als we het hebben over een soort werk met swap, eindigt het met de vroegtijdige aankomst van de OOM-moordenaar. En de OOM-killer, die niet op tijd arriveerde en PostgreSQL liet vallen, is onaangenaam. Iedereen zal hiervan op de hoogte zijn, dat wil zeggen tot de laatste gebruiker.

Wat is er gaande? Je hebt daar een grote hoeveelheid RAM, alles werkt goed. Maar om de een of andere reden blijft de server in swap hangen en wordt hierdoor langzamer. Het lijkt erop dat er veel geheugen is, maar dit gebeurt.

Voorheen adviseerden we om vm.swappiness op nul in te stellen, d.w.z. swap uit te schakelen. Voorheen leek het erop dat 32 GB RAM en bijbehorende gedeelde buffers een enorme hoeveelheid was. Het belangrijkste doel van de ruil is om een ​​plek te hebben waar we de korst kunnen weggooien als we eraf vallen. En het werd niet langer bijzonder vervuld. En wat ga je dan met deze korst doen? Dit is een taak waarbij het niet erg duidelijk is waarom een ​​swap nodig is, vooral als deze van een dergelijke omvang is.

Maar in modernere, d.w.z. derde versies van de kernel, is het gedrag veranderd. En als je swap op nul zet, dat wil zeggen uitzet, dan zal vroeg of laat, zelfs als er nog wat RAM over is, een OOM-killer naar je toe komen om de meest intensieve consumenten te vermoorden. Omdat hij zal bedenken dat we met zo'n werklast nog een klein beetje over hebben en eruit zullen springen, dat wil zeggen niet om het systeemproces vast te leggen, maar om iets minder belangrijks vast te leggen. Deze minder belangrijke persoon zal de intensieve gebruiker van het gedeelde geheugen zijn, namelijk de postmeester. En daarna is het goed als de basis niet hersteld hoeft te worden.

Daarom liggen de meeste distributies nu, voor zover ik me herinner, standaard ergens rond de 6, dat wil zeggen op welk punt je swap moet gaan gebruiken, afhankelijk van hoeveel geheugen er nog over is. We raden nu aan om vm.swappiness = 1 in te stellen, omdat dit het praktisch uitschakelt, maar niet dezelfde effecten geeft als bij een OOM-killer die onverwachts arriveerde en het hele ding doodde.

Wat is het volgende? Als we het hebben over de prestaties van databases en geleidelijk richting schijven gaan, begint iedereen naar zijn hoofd te grijpen. Omdat de waarheid dat de schijf langzaam is en het geheugen snel is, iedereen al vanaf zijn kindertijd bekend is. En iedereen weet dat de database schijfprestatieproblemen zal hebben.

Het belangrijkste PostgreSQL-prestatieprobleem dat verband houdt met pieken in de controlepunten treedt niet op omdat de schijf traag is. Dit komt waarschijnlijk doordat de geheugen- en schijfbandbreedte niet in evenwicht zijn. Het is echter mogelijk dat ze op verschillende plaatsen niet in evenwicht zijn. PostgreSQL is niet geconfigureerd, het besturingssysteem is niet geconfigureerd, de hardware is niet geconfigureerd en de hardware is onjuist. En dit probleem doet zich niet alleen voor als alles gebeurt zoals het zou moeten, d.w.z. er is geen belasting, of de instellingen en hardware zijn goed geselecteerd.

Wat is het en hoe ziet het eruit? Meestal zijn mensen die met PostgreSQL werken meer dan eens met deze kwestie bezig geweest. Ik zal het uitleggen. Zoals ik al zei, maakt PostgreSQL periodiek controlepunten om vuile pagina's in gedeeld geheugen naar schijf te dumpen. Als we een grote hoeveelheid gedeeld geheugen hebben, begint checkpoint een intensieve impact op de schijf te hebben, omdat het deze pagina's met fsync dumpt. Het arriveert in de kernelbuffer en wordt met behulp van fsync naar schijven geschreven. En als het volume van dit bedrijf groot is, kunnen we een onaangenaam effect waarnemen, namelijk een zeer groot gebruik van schijven.

Hier heb ik twee foto's. Ik zal nu uitleggen wat het is. Dit zijn twee tijdsgecorreleerde grafieken. De eerste grafiek is het schijfgebruik. Hier bereikt het op dit moment bijna 90%. Als u een databasestoring heeft met fysieke schijven, met een RAID-controllergebruik van 90%, dan is dit slecht nieuws. Dit betekent dat nog iets meer en de 100 wordt bereikt en de I/O stopt.

Als je een disk-array hebt, is het een iets ander verhaal. Het hangt af van hoe het is geconfigureerd, wat voor soort array het is, enz.

En parallel wordt hier een grafiek uit de interne postgres-weergave geconfigureerd, die vertelt hoe het controlepunt plaatsvindt. En de groene kleur hier laat zien hoeveel buffers, deze vuile pagina's, op dat moment bij dit controlepunt zijn aangekomen voor synchronisatie. En dit is het belangrijkste dat u hier moet weten. We zien dat we hier veel pagina's hebben en op een gegeven moment kwamen we op het bord, dat wil zeggen, we schreven en schreven, hier is het schijfsysteem duidelijk erg druk. En ons controlepunt heeft een zeer sterke impact op de schijf. Idealiter zou de situatie er meer zo uit moeten zien, dat wil zeggen dat we hier minder opnames hadden. En we kunnen het repareren met de instellingen, zodat het zo blijft. Dat wil zeggen, de recycling is klein, maar ergens schrijven we hier iets.

Wat moet er gedaan worden om dit probleem te overwinnen? Als u IO onder de database hebt gestopt, betekent dit dat alle gebruikers die aan hun verzoeken zijn gekomen, zullen wachten.

Als je vanuit het standpunt van Linux kijkt, als je goede hardware hebt genomen, deze correct hebt geconfigureerd, PostgreSQL normaal hebt geconfigureerd zodat deze controlepunten minder vaak worden gemaakt en ze in de loop van de tijd onder elkaar worden verspreid, dan stap je over naar de standaard Debian-parameters. Voor de meeste Linux-distributies is dit het plaatje: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Wat betekent het? Eén blozende demon verscheen uit kernel 2.6. Pdglush, afhankelijk van wie welke gebruikt, houdt zich bezig met het verwijderen van vuile pagina's op de achtergrond uit de kernelbuffer en het weggooien wanneer het nodig is om vuile pagina's te verwijderen, wat er ook gebeurt, wanneer het weggooien van de achtergrond niet helpt.

Wanneer komt de achtergrond? Wanneer 10% van het totale beschikbare RAM op de server wordt ingenomen door vuile pagina's in de kernelbuffer, wordt op de achtergrond een speciale afschrijvingsfunctie aangeroepen. Waarom is het achtergrond? Als parameter houdt deze rekening met het aantal pagina's dat moet worden afgeschreven. En laten we zeggen dat hij N pagina's afschrijft. En een tijdje valt dit ding in slaap. En dan komt ze weer en kopieert nog een paar pagina's.

Dit is een uiterst eenvoudig verhaal. Het probleem hier is als bij een zwembad: wanneer het in de ene buis stroomt, stroomt het in een andere. Ons controlepunt arriveerde en als het een paar vuile pagina's stuurde om te verwijderen, dan zal het geheel geleidelijk netjes worden opgelost vanuit de kernelbuffer pgflush.

Als deze vuile pagina's zich blijven ophopen, stapelen ze zich op tot 20%, waarna de prioriteit van het besturingssysteem is om het hele ding naar de schijf te schrijven, omdat de stroom uitvalt en alles slecht voor ons zal zijn. Deze gegevens raken wij bijvoorbeeld kwijt.

Wat is de truc? De truc is dat deze parameters in de moderne wereld 20 tot 10% uitmaken van het totale RAM-geheugen dat op de machine staat, ze zijn absoluut monsterlijk in termen van de doorvoer van elk schijfsysteem dat je hebt.

Stel je voor dat je 128 GB RAM hebt. Er arriveert 12,8 GB op uw schijfsysteem. En welke cache je daar ook hebt, welke array je daar ook hebt, ze zullen niet zo lang meegaan.

Daarom raden wij u aan deze cijfers direct aan te passen op basis van de mogelijkheden van uw RAID-controller. Ik heb hier meteen een aanbeveling gedaan voor een controller met 512 MB cache.

Alles wordt als heel eenvoudig beschouwd. Je kunt vm.dirty_background in bytes plaatsen. En deze instellingen annuleren de vorige twee. Beide verhoudingen zijn standaard, of die met bytes zijn geactiveerd, dan zullen die met bytes werken. Maar aangezien ik een DBA-consultant ben en met verschillende klanten werk, probeer ik strootjes te trekken en daarom, als het in bytes is, dan in bytes. Niemand gaf enige garantie dat een goede beheerder niet meer geheugen aan de server zou toevoegen, deze opnieuw zou opstarten en dat het cijfer hetzelfde zou blijven. Bereken deze cijfers maar eens zodat alles daar met garantie in past.

Wat gebeurt er als je er niet bij past? Ik heb geschreven dat elke spoeling effectief wordt gestopt, maar in feite is dit bij wijze van spreken. Het besturingssysteem heeft een groot probleem: het heeft veel vuile pagina's, dus de IO die uw klanten genereren, wordt effectief gestopt, dat wil zeggen dat de applicatie een SQL-query naar de database komt sturen en wacht. Elke invoer/uitvoer ernaar heeft de laagste prioriteit, omdat de database bezet is door een controlepunt. En wanneer ze klaar zal zijn, is volkomen onduidelijk. En als u niet-achtergronddoorspoelen hebt bereikt, betekent dit dat al uw IO hierdoor wordt bezet. En totdat het eindigt, doe je niets.

Er zijn nog twee belangrijke punten die buiten de reikwijdte van dit rapport vallen. Deze instellingen moeten overeenkomen met de instellingen in postgresql.conf, d.w.z. de controlepuntinstellingen. En uw schijfsysteem moet adequaat zijn geconfigureerd. Als u een cache op een RAID hebt, moet deze een batterij hebben. Mensen kopen RAID met goede cache zonder batterij. Als je SSD's in RAID hebt, dan moeten het server-exemplaren zijn, er moeten condensatoren aanwezig zijn. Hier vindt u een gedetailleerde checklist. Deze link bevat mijn rapport over het configureren van een prestatieschijf in PostgreSQL. Daar staan ​​al deze checklists.

Wat kan het leven nog meer erg moeilijk maken? Dit zijn twee parameters. Ze zijn relatief nieuw. Standaard kunnen ze in verschillende toepassingen worden opgenomen. En ze kunnen het leven net zo moeilijk maken als ze verkeerd worden ingeschakeld.

Er zijn twee relatief nieuwe dingen. Ze zijn al verschenen in de derde kernen. Dit is sched_migration_cost in nanoseconden en sched_autogroup_enabled, wat standaard één is.

En hoe ruïneren ze je leven? Wat zijn sched_migration_cost? Op Linux kan de planner een proces van de ene CPU naar de andere migreren. En voor PostgreSQL, dat queries uitvoert, is het migreren naar een andere CPU volkomen onduidelijk. Vanuit het oogpunt van het besturingssysteem kan dit goed zijn als u van venster wisselt tussen openoffice en terminal, maar voor een database is dit erg slecht. Daarom is het een redelijk beleid om de migratiekosten op een grote waarde in te stellen, op zijn minst enkele duizenden nanoseconden.

Wat betekent dit voor de planner? Er zal rekening mee worden gehouden dat het proces gedurende deze tijd nog steeds heet is. Dat wil zeggen: als u een langlopende transactie heeft die al heel lang iets doet, zal de planner dit begrijpen. Hij gaat ervan uit dat totdat deze time-out voorbij is, het niet nodig is dit proces ergens anders te migreren. Als het proces tegelijkertijd iets doet, wordt het nergens naartoe gemigreerd, maar werkt het stilletjes op de CPU die eraan is toegewezen. En het resultaat is uitstekend.

Het tweede punt is autogroep. Er is een goed idee voor specifieke werkbelastingen die geen verband houden met moderne databases: dit is het groeperen van processen op basis van de virtuele terminal van waaruit ze worden gestart. Voor sommige taken is dit handig. In de praktijk is PostgreSQL een multi-processysteem met een prefork die vanaf één terminal draait. U beschikt over een slotschrijver en een controlepunt, en al uw klantverzoeken worden per CPU gegroepeerd in één planner. En daar zullen ze in koor wachten tot hij vrij is, om zich met elkaar te bemoeien en hem langer bezig te houden. Dit is een verhaal dat bij een dergelijke belasting totaal overbodig is en daarom uitgeschakeld moet worden.

Mijn collega Alexey Lesovsky deed tests met een eenvoudige pgbench, waarbij hij de migratiekosten met een orde van grootte verhoogde en autogroup uitschakelde. Het verschil op slechte hardware was bijna 10%. Er is een discussie op de postgres-mailinglijst waar mensen resultaten geven van soortgelijke wijzigingen in de zoeksnelheid beïnvloed 50%. Er zijn nogal wat van dergelijke verhalen.

En tot slot over het energiebesparingsbeleid. Het mooie is dat Linux nu op een laptop gebruikt kan worden. En het zal de batterij vermoedelijk goed verbruiken. Maar ineens blijkt dat dit ook op de server kan gebeuren.

Bovendien, als je servers huurt bij een of andere host, dan maakt het de ‘goede’ hosters niet uit dat je betere prestaties levert. Hun taak is ervoor te zorgen dat hun ijzer zo efficiënt mogelijk wordt gebruikt. Daarom kunnen ze standaard de energiebesparende modus van de laptop inschakelen op het besturingssysteem.

Als je dit spul gebruikt op een server met een database die zwaar wordt belast, dan is je keuze acpi_cpufreq + permormance. Zelfs met on-demand zullen er problemen zijn.

Intel_pstate is een iets andere driver. En nu wordt de voorkeur gegeven aan deze, omdat deze later is en beter werkt.

En dienovereenkomstig is gouverneur alleen maar prestatie. Ondemand, powersave en al het andere gaan niet over jou.

De resultaten van de uitleg-analyse van PostgreSQL kunnen verschillende ordes van grootte verschillen als u powersave inschakelt, omdat praktisch de CPU onder uw database op een volledig onvoorspelbare manier zal werken.

Deze items kunnen standaard worden meegeleverd. Kijk goed of ze dit standaard hebben ingeschakeld. Dit kan een heel groot probleem zijn.

En uiteindelijk wilde ik de jongens van ons PosgreSQL-Consulting DBA-team bedanken, namelijk Max Boguk en Alexey Lesovsky, die elke dag vooruitgang boeken in deze kwestie. En we proberen ons best te doen voor onze klanten, zodat het allemaal voor hen werkt. Het is net als met veiligheidsinstructies voor de luchtvaart. Alles hier is met bloed geschreven. Elk van deze noten wordt aangetroffen tijdens een of ander probleem. Ik deel ze graag met u.

Vragen:

Bedankt! Als een bedrijf bijvoorbeeld geld wil besparen en de database en applicatielogica op één server wil plaatsen, of als het bedrijf de modieuze trend volgt van microservice-architecturen, waarbij PostgreSQL in een container draait. Wat is de truc? Sysctl zal wereldwijd de gehele kernel beïnvloeden. Ik heb nog nooit gehoord dat sysctls op de een of andere manier gevirtualiseerd zijn, zodat ze afzonderlijk op een container werken. Er is slechts een cgroep en daar is slechts een deel van de controle. Hoe kun je hiermee leven? Of als u prestaties wilt, voer dan PostgreSQL uit op een aparte hardwareserver en stem deze af?

We hebben uw vraag op ongeveer drie manieren beantwoord. Als we het niet hebben over een hardwareserver die kan worden afgestemd, enz., wees dan gerust, alles zal prima werken zonder deze instellingen. Als je zo'n belasting hebt dat je deze instellingen moet maken, dan kom je eerder naar de ijzerserver dan naar deze instellingen.

Wat is het probleem? Als dit een virtuele machine is, zul je hoogstwaarschijnlijk veel problemen ondervinden, bijvoorbeeld met het feit dat op de meeste virtuele machines de latentie van de schijf behoorlijk inconsistent is. Zelfs als de schijfdoorvoer goed is, zal één mislukte I/O-transactie die geen grote invloed heeft op de gemiddelde doorvoer die plaatsvond op het moment van het controlepunt of op het moment van schrijven naar WAL, de database hier enorm onder lijden. En dat merk je al voordat je tegen deze problemen aanloopt.

Als je NGINX op dezelfde server hebt, zul je ook hetzelfde probleem hebben. Hij zal vechten voor een gedeelde herinnering. En dan kom je niet bij de hier beschreven problemen.

Maar aan de andere kant zullen sommige van deze parameters nog steeds relevant voor u zijn. Stel bijvoorbeeld dirty_ratio in met sysctl zodat het niet zo gek wordt - dit zal in ieder geval helpen. Op de een of andere manier zul je interactie hebben met de schijf. En het zal volgens het verkeerde patroon zijn. Dit is over het algemeen een standaard voor de parameters die ik heb laten zien. En in ieder geval is het beter om ze te veranderen.

Maar er kunnen problemen zijn met NUMA. VmWare werkt bijvoorbeeld goed samen met NUMA met precies de tegenovergestelde instellingen. En hier moet je kiezen: een ijzeren server of een niet-ijzeren server.

Ik heb een vraag met betrekking tot Amazon AWS. Ze hebben vooraf geconfigureerde afbeeldingen. Een daarvan heet Amazon RDS. Zijn er aangepaste instellingen voor hun besturingssysteem?

Er zijn daar instellingen, maar het zijn verschillende instellingen. Hier configureren we het besturingssysteem in termen van hoe de database dit ding zal gebruiken. En er zijn parameters die bepalen waar we nu heen moeten, zoals shaping. Dat wil zeggen, we hebben zoveel hulpbronnen nodig dat we ze nu opeten. Hierna scherpt Amazon RDS deze bronnen aan, en de prestaties dalen daar. Er zijn individuele verhalen over hoe mensen zich met deze kwestie beginnen te bemoeien. Soms zelfs behoorlijk succesvol. Maar dit heeft niets te maken met de instellingen van het besturingssysteem. Het is alsof je de cloud hackt. Dat is een ander verhaal.

Waarom hebben transparante grote pagina's geen effect vergeleken met enorme TLB?

Geef niet. Dit kan op vele manieren worden verklaard. Maar in feite geven ze het gewoon niet. Wat is de geschiedenis van PostgreSQL? Bij het opstarten wijst het een groot deel van het gedeelde geheugen toe. Of ze transparant zijn of niet, doet er totaal niet toe. Dat ze in het begin opvallen, verklaart alles. En als er veel geheugen is en u het shared_memory-segment opnieuw moet opbouwen, dan zijn transparante grote pagina's relevant. In PostgreSQL wordt het in het begin eenvoudigweg in een groot deel toegewezen en dat is alles, en dan gebeurt er niets bijzonders. Je kunt het natuurlijk gebruiken, maar er is een kans op beschadiging van gedeeld geheugen wanneer het iets opnieuw toewijst. PostgreSQL weet hier niets van.

Bron: www.habr.com