Ik stel voor dat u het transcript leest van het rapport van Alexey Lesovsky van Data Egret “Fundamentals of PostgreSQL monitoring”
In dit rapport zal Alexey Lesovsky praten over de belangrijkste punten van post-gress-statistieken, wat ze betekenen en waarom ze aanwezig zouden moeten zijn in de monitoring; over welke grafieken in de monitoring moeten staan, hoe u ze moet toevoegen en hoe u ze moet interpreteren. Het rapport zal nuttig zijn voor databasebeheerders, systeembeheerders en ontwikkelaars die geïnteresseerd zijn in het oplossen van problemen met Postgres.
Mijn naam is Alexey Lesovsky, ik vertegenwoordig het bedrijf Data Egret.
Een paar woorden over mezelf. Ik ben lang geleden begonnen als systeembeheerder.
Ik beheerde allerlei verschillende Linux-systemen, werkte aan verschillende dingen die met Linux te maken hadden, zoals virtualisatie, monitoring, werkte met proxy's, enz. Maar op een gegeven moment begon ik meer met databases, PostgreSQL, te werken. Ik vond hem erg leuk. En op een gegeven moment begon ik het grootste deel van mijn werktijd aan PostgreSQL te werken. En zo werd ik geleidelijk een PostgreSQL DBA.
En gedurende mijn hele carrière ben ik altijd geïnteresseerd geweest in de onderwerpen statistiek, monitoring en telemetrie. En toen ik systeembeheerder was, werkte ik heel nauw samen met Zabbix. En ik schreef een kleine set scripts zoals . Hij was in zijn tijd behoorlijk populair. En daar was het mogelijk om heel verschillende belangrijke dingen te monitoren, niet alleen Linux, maar ook verschillende componenten.
Nu werk ik aan PostgreSQL. Ik ben al iets anders aan het schrijven waarmee je met PostgreSQL-statistieken kunt werken. Het heet (artikel over Habré - ).
Een kleine inleidende opmerking. Welke situaties hebben onze klanten, onze cliënten? Er is een ongeluk gebeurd met de database. En als de database al hersteld is, komt het hoofd van de afdeling of het hoofd ontwikkeling en zegt: “Vrienden, we moeten de database in de gaten houden, want er is iets ergs gebeurd en we moeten voorkomen dat dit in de toekomst gebeurt.” En hier begint het interessante proces van het kiezen van een monitoringsysteem of het aanpassen van een bestaand monitoringsysteem zodat u uw database kunt monitoren - PostgreSQL, MySQL of andere. En collega's beginnen te suggereren: “Ik heb gehoord dat er zo'n en die database is. Laten we het gebruiken." Collega's beginnen ruzie met elkaar te maken. En uiteindelijk blijkt dat we een soort database selecteren, maar de PostgreSQL-monitoring wordt daarin nogal slecht gepresenteerd en we moeten altijd iets toevoegen. Neem een aantal repositories van GitHub, kloon ze, pas scripts aan en pas ze op de een of andere manier aan. En uiteindelijk wordt het een soort handwerk.
Daarom zal ik in deze lezing proberen u wat kennis te geven over hoe u monitoring kunt kiezen, niet alleen voor PostgreSQL, maar ook voor de database. En u de kennis geven waarmee u uw monitoring kunt voltooien om er enig voordeel uit te halen, zodat u uw database met voordeel kunt monitoren, om eventuele toekomstige noodsituaties die zich kunnen voordoen, onmiddellijk te voorkomen.
En de ideeën in dit rapport kunnen rechtstreeks worden aangepast aan elke database, of het nu een DBMS of noSQL is. Daarom is er niet alleen PostgreSQL, maar er zullen ook veel recepten zijn over hoe je dit in PostgreSQL kunt doen. Er zullen voorbeelden zijn van queries, voorbeelden van entiteiten die PostgreSQL heeft voor monitoring. En als uw DBMS dezelfde dingen heeft waarmee u ze in monitoring kunt zetten, kunt u ze ook aanpassen, toevoegen en het zal goed zijn.
Ik zal niet in het rapport staan
praten over hoe u statistieken kunt leveren en opslaan. Over het nabewerken van de gegevens en het presenteren aan de gebruiker ga ik niets zeggen. En ik zal niets zeggen over alarmeren.
Maar naarmate het verhaal vordert, zal ik verschillende screenshots van bestaande monitoring laten zien en deze op de een of andere manier bekritiseren. Maar toch zal ik proberen geen merken te noemen om geen reclame of anti-reclame voor deze producten te creëren. Daarom zijn alle toevalligheden willekeurig en worden ze aan je verbeelding overgelaten.
Laten we eerst eens kijken wat monitoring is. Monitoring is een heel belangrijk ding om te hebben. Iedereen begrijpt dit. Maar tegelijkertijd heeft monitoring geen betrekking op een zakelijk product en heeft het geen directe invloed op de winst van het bedrijf, dus wordt er altijd tijd besteed aan monitoring op een residuele basis. Als we tijd hebben, doen we aan monitoring; als we geen tijd hebben, oké, dan zetten we het in de backlog en op een dag zullen we terugkeren naar deze taken.
Daarom is vanuit onze praktijk, wanneer we bij klanten komen, de monitoring vaak onvolledig en bevat deze geen interessante dingen die ons zouden kunnen helpen beter werk te leveren met de database. En daarom moet de monitoring altijd worden afgerond.
Databases zijn zulke complexe dingen die ook moeten worden gemonitord, omdat databases een opslagplaats van informatie zijn. En informatie is erg belangrijk voor het bedrijf; deze mag op geen enkele manier verloren gaan. Maar tegelijkertijd zijn databases zeer complexe stukjes software. Ze bestaan uit een groot aantal componenten. En veel van deze componenten moeten worden gemonitord.
Als we het specifiek over PostgreSQL hebben, kan het worden weergegeven in de vorm van een schema dat uit een groot aantal componenten bestaat. Deze componenten interageren met elkaar. En tegelijkertijd heeft PostgreSQL het zogenaamde Stats Collector-subsysteem, waarmee u statistieken kunt verzamelen over de werking van deze subsystemen en een soort interface kunt bieden aan de beheerder of gebruiker zodat hij deze statistieken kan bekijken.
Deze statistieken worden gepresenteerd in de vorm van een bepaalde reeks functies en weergaven. Ze kunnen ook tafels worden genoemd. Dat wil zeggen dat u met een gewone psql-client verbinding kunt maken met de database, een keuze kunt maken uit deze functies en weergaven en enkele specifieke cijfers kunt krijgen over de werking van de PostgreSQL-subsystemen.
U kunt deze cijfers toevoegen aan uw favoriete monitoringsysteem, grafieken tekenen, functies toevoegen en op de lange termijn analyses krijgen.
Maar in dit rapport zal ik niet al deze functies volledig behandelen, omdat dit de hele dag kan duren. Ik zal letterlijk twee, drie of vier dingen bespreken en vertellen hoe ze de monitoring helpen verbeteren.
En als we het hebben over databasemonitoring, wat moet er dan worden gemonitord? Allereerst moeten we de beschikbaarheid monitoren, omdat de database een dienst is die klanten toegang biedt tot gegevens. We moeten de beschikbaarheid monitoren en ook enkele kwalitatieve en kwantitatieve kenmerken ervan verstrekken.
We moeten ook clients monitoren die verbinding maken met onze database, omdat dit zowel normale clients als schadelijke clients kunnen zijn die de database kunnen beschadigen. Ze moeten ook worden gecontroleerd en hun activiteiten moeten worden gevolgd.
Wanneer klanten verbinding maken met de database, is het duidelijk dat ze met onze gegevens gaan werken, dus moeten we monitoren hoe klanten met de gegevens werken: met welke tabellen, en in mindere mate, met welke indexen. Dat wil zeggen, we moeten de werkdruk evalueren die door onze klanten wordt gecreëerd.
Maar de werkdruk bestaat uiteraard ook uit verzoeken. Applicaties maken verbinding met de database, hebben toegang tot gegevens met behulp van query's, dus het is belangrijk om te evalueren welke query's we in de database hebben, hun geschiktheid te controleren, dat ze niet scheef zijn geschreven, dat sommige opties moeten worden herschreven en gemaakt zodat ze sneller werken en met betere prestaties.
En aangezien we het over een database hebben, bestaat de database altijd uit achtergrondprocessen. Achtergrondprocessen helpen de databaseprestaties op een goed niveau te houden, zodat ze een bepaalde hoeveelheid middelen nodig hebben om te kunnen functioneren. En tegelijkertijd kunnen ze overlappen met bronnen voor klantverzoeken, zodat hebzuchtige achtergrondprocessen rechtstreeks van invloed kunnen zijn op de prestaties van klantverzoeken. Daarom moeten ze ook worden gemonitord en gevolgd, zodat er geen verstoringen optreden in de achtergrondprocessen.
En dit alles in termen van databasemonitoring blijft in de systeemmetriek. Maar gezien het feit dat het grootste deel van onze infrastructuur naar de cloud verhuist, verdwijnen de systeemstatistieken van een individuele host altijd naar de achtergrond. Maar in databases zijn ze nog steeds relevant en het is natuurlijk ook noodzakelijk om systeemmetrieken te monitoren.
Alles is min of meer in orde met systeemstatistieken, alle moderne monitoringsystemen ondersteunen deze statistieken al, maar over het algemeen zijn sommige componenten nog steeds niet voldoende en moeten er dingen worden toegevoegd. Ik zal ze ook bespreken, er zullen verschillende dia's over zijn.
Het eerste punt van het plan is bereikbaarheid. Wat is toegankelijkheid? Beschikbaarheid is naar mijn mening het vermogen van de basis om verbindingen te onderhouden, dat wil zeggen dat de basis wordt verhoogd en als service verbindingen van klanten accepteert. En deze toegankelijkheid kan worden beoordeeld aan de hand van bepaalde kenmerken. Het is erg handig om deze kenmerken op dashboards weer te geven.
Iedereen weet wat dashboards zijn. Hierbij heb je één blik geworpen op het scherm waarop de benodigde informatie is samengevat. En u kunt direct vaststellen of er een probleem is in de database of niet.
Daarom moeten de beschikbaarheid van de database en andere belangrijke kenmerken altijd op dashboards worden weergegeven, zodat deze informatie altijd bij de hand en voor u beschikbaar is. Sommige aanvullende details die al helpen bij het onderzoeken van incidenten; bij het onderzoeken van sommige noodsituaties moeten ze al op secundaire dashboards worden geplaatst, of verborgen in drilldown-links die leiden naar monitoringsystemen van derden.
Een voorbeeld van een bekend monitoringsysteem. Dit is een heel cool monitoringsysteem. Ze verzamelt veel gegevens, maar vanuit mijn oogpunt heeft ze een vreemd concept van dashboards. Er is een link om “een dashboard te maken”. Maar wanneer u een dashboard maakt, maakt u een lijst met twee kolommen, een lijst met grafieken. En als je ergens naar moet kijken, begin je met de muis te klikken, te scrollen, op zoek naar de gewenste grafiek. En dit kost tijd, d.w.z. er zijn geen dashboards als zodanig. Er zijn alleen lijsten met grafieken.
Wat moet u toevoegen aan deze dashboards? U kunt beginnen met zo'n kenmerk als de responstijd. PostgreSQL heeft de weergave pg_stat_statements. Het is standaard uitgeschakeld, maar het is een van de belangrijke systeemweergaven die altijd ingeschakeld en gebruikt moet worden. Het slaat informatie op over alle actieve query's die in de database zijn uitgevoerd.
Dienovereenkomstig kunnen we uitgaan van het feit dat we de totale uitvoeringstijd van alle verzoeken kunnen nemen en deze kunnen delen door het aantal verzoeken met behulp van de bovenstaande velden. Maar dit is de gemiddelde temperatuur in het ziekenhuis. We kunnen beginnen met andere velden: minimale uitvoeringstijd van zoekopdrachten, maximum en mediaan. En we kunnen zelfs percentielen bouwen; PostgreSQL heeft hiervoor overeenkomstige functies. En we kunnen een aantal cijfers krijgen die de responstijd van onze database karakteriseren voor reeds voltooide verzoeken, d.w.z. we voeren het nepverzoek 'select 1' niet uit en kijken naar de responstijd, maar we analyseren de responstijd voor reeds voltooide verzoeken en tekenen óf een apart figuur, óf we bouwen er een grafiek op gebaseerd.
Het is ook belangrijk om het aantal fouten te monitoren dat momenteel door het systeem wordt gegenereerd. En hiervoor kunt u de weergave pg_stat_database gebruiken. We concentreren ons op het veld xact_rollback. Dit veld toont niet alleen het aantal rollbacks dat in de database voorkomt, maar houdt ook rekening met het aantal fouten. Relatief gezien kunnen we dit cijfer in ons dashboard weergeven en zien hoeveel fouten we momenteel hebben. Als er veel fouten zijn, dan is dit een goede reden om in de logs te kijken en te zien wat voor soort fouten het zijn en waarom ze optreden, om er vervolgens in te investeren en deze op te lossen.
Je kunt zoiets als een toerenteller toevoegen. Dit zijn het aantal transacties per seconde en het aantal verzoeken per seconde. Relatief gezien kunt u deze cijfers gebruiken als de huidige prestaties van uw database en observeren of er pieken zijn in verzoeken, pieken in transacties, of, omgekeerd, of de database onderbelast is omdat een of andere backend uitvalt. Het is belangrijk om altijd naar dit cijfer te kijken en te onthouden dat dit soort prestaties voor ons project normaal is, maar dat de waarden boven en onder al op de een of andere manier problematisch en onbegrijpelijk zijn, wat betekent dat we moeten kijken waarom deze cijfers zo zijn. zo hoog.
Om het aantal transacties te schatten, kunnen we opnieuw de weergave pg_stat_database raadplegen. We kunnen het aantal commits en het aantal rollbacks optellen en zo het aantal transacties per seconde krijgen.
Begrijpt iedereen dat er meerdere verzoeken in één transactie kunnen passen? Daarom zijn TPS en QPS enigszins verschillend.
Het aantal verzoeken per seconde kan worden verkregen uit pg_stat_statements en berekent eenvoudig de som van alle voltooide verzoeken. Het is duidelijk dat we de huidige waarde vergelijken met de vorige, deze aftrekken, de delta verkrijgen en de hoeveelheid verkrijgen.
Indien gewenst kunt u aanvullende statistieken toevoegen, die ook helpen bij het evalueren van de beschikbaarheid van onze database en het monitoren of er sprake is van downtime.
Een van deze statistieken is uptime. Maar uptime in PostgreSQL is een beetje lastig. Ik zal je vertellen waarom. Wanneer PostgreSQL is gestart, begint de uptime te rapporteren. Maar als op een gegeven moment bijvoorbeeld een taak 's nachts werd uitgevoerd, er een OOM-killer kwam en het onderliggende PostgreSQL-proces met geweld beëindigde, beëindigt PostgreSQL in dit geval de verbinding van alle clients, reset het gesharde geheugengebied en begint het herstel van het laatste controlepunt. En zolang dit herstel vanaf het controlepunt duurt, accepteert de database geen verbindingen, d.w.z. deze situatie kan worden beoordeeld als downtime. Maar de uptimeteller wordt niet gereset, omdat deze vanaf het eerste moment rekening houdt met de opstarttijd van de postmaster. Daarom kunnen dergelijke situaties worden overgeslagen.
Je moet ook het aantal vacuümwerkers monitoren. Weet iedereen wat autovacuüm is in PostgreSQL? Dit is een interessant subsysteem in PostgreSQL. Er zijn veel artikelen over haar geschreven, er zijn veel rapporten gemaakt. Er zijn veel discussies over vacuüm en hoe het zou moeten werken. Velen beschouwen het als een noodzakelijk kwaad. Maar zo is het. Dit is een soort analoog van een garbage collector die verouderde versies van rijen opruimt die voor geen enkele transactie nodig zijn en ruimte vrijmaakt in tabellen en indexen voor nieuwe rijen.
Waarom moet je het monitoren? Omdat het vacuüm soms veel pijn doet. Het verbruikt een grote hoeveelheid bronnen en de verzoeken van klanten beginnen eronder te lijden.
En het zou moeten worden gecontroleerd via de weergave pg_stat_activity, waarover ik in de volgende sectie zal praten. Deze weergave toont de huidige activiteit in de database. En via deze activiteit kunnen we het aantal stofzuigers volgen dat momenteel werkt. We kunnen stofzuigers volgen en zien dat als we de limiet hebben overschreden, dit een reden is om naar de PostgreSQL-instellingen te kijken en op de een of andere manier de werking van het vacuüm te optimaliseren.
Een ander ding over PostgreSQL is dat PostgreSQL lange transacties erg beu is. Vooral van transacties die lang blijven hangen en niets doen. Dit is de zogenaamde stat-idle-in-transactie. Zo'n transactie houdt sloten vast en verhindert dat het vacuüm werkt. En als gevolg daarvan zwellen de tafels op en worden ze groter. En query's die met deze tabellen werken, beginnen langzamer te werken, omdat u alle oude versies van rijen van geheugen naar schijf en terug moet verplaatsen. Daarom moeten ook de tijd, de duur van de langste transacties en de langste vacuümverzoeken worden gemonitord. En als we processen zien die al heel lang actief zijn, al meer dan 10-20-30 minuten voor een OLTP-lading, dan moeten we daar aandacht aan besteden en ze met kracht beëindigen, of de applicatie optimaliseren zodat ze worden niet gebeld en blijven niet zo lang hangen. Voor een analytische werklast is 10-20-30 minuten normaal; er zijn ook langere.
Vervolgens hebben we de optie met aangesloten clients. Als we al een dashboard hebben gemaakt en daarop de belangrijkste beschikbaarheidsstatistieken hebben geplaatst, kunnen we daar ook aanvullende informatie over verbonden klanten toevoegen.
Informatie over verbonden clients is belangrijk omdat clients vanuit PostgreSQL-perspectief verschillend zijn. Er zijn goede klanten en er zijn slechte klanten.
Een eenvoudig voorbeeld. Onder opdrachtgever versta ik de applicatie. De applicatie heeft verbinding gemaakt met de database en begint onmiddellijk zijn verzoeken daarheen te sturen. De database verwerkt deze, voert deze uit en stuurt de resultaten terug naar de klant. Dit zijn goede en correcte klanten.
Er zijn situaties waarin de client verbinding heeft gemaakt, de verbinding vasthoudt, maar niets doet. Het bevindt zich in de inactieve toestand.
Maar er zijn slechte klanten. Dezelfde client maakte bijvoorbeeld verbinding, opende een transactie, deed iets in de database en ging vervolgens in de code om bijvoorbeeld toegang te krijgen tot een externe bron of om daar de ontvangen gegevens te verwerken. Maar hij rondde de transactie niet af. En de transactie blijft in de database hangen en wordt in een slotje op de lijn bewaard. Dit is een slechte toestand. En als er ergens in zichzelf plotseling een applicatie uitvalt, met een uitzondering, dan kan de transactie heel lang open blijven staan. En dit heeft rechtstreeks invloed op de prestaties van PostgreSQL. PostgreSQL zal langzamer zijn. Daarom is het belangrijk om dergelijke klanten tijdig te volgen en hun werk met geweld te beëindigen. En u moet uw applicatie optimaliseren, zodat dergelijke situaties niet voorkomen.
Andere slechte klanten zijn wachtende klanten. Maar door omstandigheden worden ze slecht. Bijvoorbeeld een eenvoudige inactieve transactie: deze kan een transactie openen, bepaalde regels blokkeren, en dan ergens in de code mislukken, waardoor een hangende transactie achterblijft. Een andere klant zal komen en dezelfde gegevens opvragen, maar hij zal een slot tegenkomen, omdat die hangende transactie al sloten bevat op sommige vereiste rijen. En de tweede transactie zal blijven wachten tot de eerste transactie is voltooid of deze met geweld door de beheerder wordt gesloten. Daarom kunnen lopende transacties zich ophopen en de databaseverbindingslimiet vullen. En als de limiet vol is, kan de applicatie niet meer met de database werken. Dit is al een noodsituatie voor het project. Daarom moeten slechte klanten worden gevolgd en tijdig worden gereageerd.
Nog een voorbeeld van toezicht. En er is hier al een behoorlijk dashboard. Hierboven vindt u informatie over verbindingen. DB-aansluiting – 8 stuks. En het is alles. We hebben geen informatie over welke klanten actief zijn, welke klanten gewoon niets doen. Er is geen informatie over lopende transacties en lopende verbindingen, d.w.z. dit is een cijfer dat het aantal verbindingen weergeeft en dat is alles. En raad het dan zelf maar.
Om deze informatie aan monitoring toe te voegen, moet u daarom toegang krijgen tot de systeemweergave pg_stat_activity. Als je veel tijd in PostgreSQL doorbrengt, dan is dit een heel goed beeld dat je vriend zou moeten worden, omdat het de huidige activiteit in PostgreSQL laat zien, dat wil zeggen wat er daarin gebeurt. Voor elk proces is er een aparte regel met informatie over dit proces: vanaf welke host de verbinding is gemaakt, onder welke gebruiker, onder welke naam, wanneer de transactie is gestart, welk verzoek momenteel loopt, welk verzoek voor het laatst is uitgevoerd. En dienovereenkomstig kunnen we de toestand van de klant evalueren met behulp van het statistische veld. Relatief gezien kunnen we groeperen op dit veld en de statistieken verkrijgen die zich momenteel in de database bevinden, en het aantal verbindingen dat deze statistiek in de database heeft. En we kunnen de reeds ontvangen cijfers naar onze monitoring sturen en op basis daarvan grafieken tekenen.
Het is ook belangrijk om de duur van de transactie te evalueren. Ik heb al gezegd dat het belangrijk is om de duur van vacuüms te evalueren, maar transacties worden op dezelfde manier geëvalueerd. Er zijn xact_start- en query_start-velden. Ze tonen relatief gezien de starttijd van de transactie en de starttijd van het verzoek. We nemen de functie now(), die de huidige tijdstempel toont, en trekken de transactie en de tijdstempel van het verzoek af. En we krijgen de duur van de transactie, de duur van het verzoek.
Als we lange transacties zien, moeten we deze al voltooien. Voor een OLTP-lading duren lange transacties al meer dan 1-2-3 minuten. Voor een OLAP-werklast zijn lange transacties normaal, maar als de voltooiing ervan meer dan twee uur in beslag neemt, is dit ook een teken dat er ergens een scheefheid zit.
Zodra klanten verbinding hebben gemaakt met de database, gaan ze met onze gegevens aan de slag. Ze hebben toegang tot tabellen, ze hebben toegang tot indexen om gegevens uit de tabel te halen. En het is belangrijk om te evalueren hoe klanten omgaan met deze gegevens.
Dit is nodig om onze werklast te evalueren en grofweg te begrijpen welke tabellen voor ons het “hotst” zijn. Dit is bijvoorbeeld nodig in situaties waarin we ‘hot’ tabellen op een soort snelle SSD-opslag willen plaatsen. Sommige archieftabellen die we lange tijd niet hebben gebruikt, kunnen bijvoorbeeld worden verplaatst naar een soort “koud” archief, naar SATA-schijven en ze daar laten staan, ze zullen indien nodig worden geopend.
Dit is ook handig voor het detecteren van afwijkingen na eventuele releases en implementaties. Laten we zeggen dat het project een nieuwe functie heeft uitgebracht. Zo hebben we nieuwe functionaliteit toegevoegd voor het werken met de database. En als we grafieken van tabelgebruik plotten, kunnen we deze afwijkingen gemakkelijk in deze grafieken detecteren. Werk bijvoorbeeld bursts bij of verwijder bursts. Het zal zeer zichtbaar zijn.
U kunt ook afwijkingen in ‘zwevende’ statistieken detecteren. Wat betekent het? PostgreSQL heeft een zeer sterke en zeer goede queryplanner. En de ontwikkelaars besteden veel tijd aan de ontwikkeling ervan. Hoe werkt hij? Om goede plannen te maken verzamelt PostgreSQL statistieken over de verdeling van gegevens in tabellen op een bepaald tijdsinterval en met een bepaalde frequentie. Dit zijn de meest voorkomende waarden: het aantal unieke waarden, informatie over NULL in de tabel, veel informatie.
Op basis van deze statistieken stelt de planner verschillende query's samen, selecteert de meest optimale en gebruikt dit queryplan om de query zelf uit te voeren en gegevens terug te sturen.
En het komt voor dat de statistieken “zweven”. De kwaliteits- en kwantiteitsgegevens veranderden op de een of andere manier in de tabel, maar de statistieken werden niet verzameld. En de gevormde plannen zijn misschien niet optimaal. En als onze plannen op basis van de verzamelde monitoring, op basis van de tabellen, niet optimaal blijken te zijn, zullen we deze afwijkingen kunnen zien. Ergens veranderden de gegevens bijvoorbeeld kwalitatief en in plaats van de index werd een opeenvolgende doorgang door de tabel gebruikt, d.w.z. als een zoekopdracht slechts 100 rijen hoeft terug te geven (er is een limiet van 100), wordt er een volledige zoekopdracht uitgevoerd voor deze zoekopdracht. En dit heeft altijd een zeer slecht effect op de prestaties.
En dat zien we terug in de monitoring. En kijk al eens naar deze query, voer er een uitleg voor uit, verzamel statistieken, bouw een nieuwe aanvullende index. En reageer al op dit probleem. Daarom is het belangrijk.
Nog een voorbeeld van toezicht. Ik denk dat veel mensen hem herkenden omdat hij erg populair is. Die het gebruiken in hun projecten ? Wie gebruikt dit product in combinatie met Prometheus? Feit is dat er in de standaardrepository van deze monitoring een dashboard is voor het werken met PostgreSQL - Prometheus. Maar er is één slecht detail.
Er zijn verschillende grafieken. En bytes worden aangegeven als eenheid, d.w.z. er zijn 5 grafieken. Dit zijn Gegevens invoegen, Gegevens bijwerken, Gegevens verwijderen, Gegevens ophalen en Gegevens retourneren. De eenheidsmaat is bytes. Maar het punt is dat statistieken in PostgreSQL gegevens in tuple (rijen) retourneren. En dienovereenkomstig zijn deze grafieken een zeer goede manier om uw werklast meerdere malen, tientallen keren, te onderschatten, omdat een tupel geen byte is, een tupel een string, het bestaat uit vele bytes en het is altijd van variabele lengte. Dat wil zeggen dat het berekenen van de werklast in bytes met behulp van tupels een onrealistische taak of erg moeilijk is. Wanneer u een dashboard of ingebouwde monitoring gebruikt, is het daarom altijd belangrijk om te begrijpen dat deze correct werkt en u correct beoordeelde gegevens retourneert.
Hoe krijg ik statistieken over deze tabellen? Voor dit doel heeft PostgreSQL een bepaalde reeks weergaven. En het hoofdaanzicht is . User_tables - dit betekent tabellen die namens de gebruiker zijn gemaakt. Daarentegen zijn er systeemweergaven die door PostgreSQL zelf worden gebruikt. En er is een samenvattende tabel Alltables, die zowel systeem- als gebruikerstabellen bevat. Je kunt beginnen met elk van hen die je het leukst vindt.
Met behulp van de bovenstaande velden kunt u een schatting maken van het aantal invoegingen, updates en verwijderingen. Het voorbeeld van een dashboard dat ik heb gebruikt, gebruikt deze velden om de kenmerken van een werklast te evalueren. Daarom kunnen wij er ook op voortbouwen. Maar het is de moeite waard om te onthouden dat dit tupels zijn en geen bytes, dus we kunnen het niet zomaar in bytes doen.
Op basis van deze gegevens kunnen we zogenaamde TopN-tabellen bouwen. Bijvoorbeeld Top-5, Top-10. En u kunt de hottables volgen die meer worden gerecycled dan andere. Bijvoorbeeld 5 “hot” tabellen voor invoeging. En met behulp van deze TopN-tabellen evalueren we onze werklast en kunnen we uitbarstingen van werklast evalueren na releases, updates en implementaties.
Het is ook belangrijk om de grootte van de tabel te evalueren, omdat ontwikkelaars soms een nieuwe functie uitrollen en onze tabellen in hun grote omvang beginnen te groeien, omdat ze besloten een extra hoeveelheid gegevens toe te voegen, maar niet voorspelden hoe dit zou gebeuren. invloed hebben op de grootte van de database. Dergelijke gevallen komen ook voor ons als verrassingen.
En nu een klein vraagje voor jou. Welke vraag rijst wanneer u de belasting van uw databaseserver opmerkt? Wat is de volgende vraag die u heeft?
Maar in feite rijst de vraag als volgt. Welke verzoeken veroorzaakt de belasting? Dat wil zeggen, het is niet interessant om te kijken naar de processen die door de belasting worden veroorzaakt. Het is duidelijk dat als de host een database heeft, de database daar draait en het is duidelijk dat alleen de databases daar zullen worden verwijderd. Als we Top openen, zien we daar een lijst met processen in PostgreSQL die iets doen. Het zal voor Top niet duidelijk zijn wat ze doen.
Dienovereenkomstig moet u die query's vinden die de hoogste belasting veroorzaken, omdat het afstemmen van query's in de regel meer winst oplevert dan het afstemmen van de PostgreSQL- of besturingssysteemconfiguratie, of zelfs het afstemmen van de hardware. Volgens mijn schatting is dit ongeveer 80-85-90%. En dit gebeurt veel sneller. Het is sneller om een verzoek te corrigeren dan om de configuratie te corrigeren, een herstart te plannen, vooral als de database niet opnieuw kan worden opgestart, of hardware toe te voegen. Het is gemakkelijker om de query ergens te herschrijven of een index toe te voegen om een beter resultaat uit deze query te krijgen.
Daarom is het noodzakelijk om toezicht te houden op de verzoeken en de geschiktheid ervan. Laten we nog een voorbeeld van monitoring nemen. En ook hier lijkt er sprake te zijn van uitstekende monitoring. Er is informatie over replicatie, er is informatie over doorvoer, blokkering en gebruik van hulpbronnen. Alles is in orde, maar er is geen informatie over verzoeken. Het is niet duidelijk welke zoekopdrachten er in onze database actief zijn, hoe lang ze actief zijn en hoeveel van deze zoekopdrachten er zijn. Wij moeten deze informatie altijd in onze monitoring hebben.
En om deze informatie te verkrijgen kunnen we de pg_stat_statements module gebruiken. Op basis hiervan kunt u verschillende grafieken maken. U kunt bijvoorbeeld informatie verkrijgen over de meest voorkomende zoekopdrachten, dat wil zeggen over de zoekopdrachten die het vaakst worden uitgevoerd. Ja, na de implementatie is het ook erg handig om ernaar te kijken en te begrijpen of er sprake is van een toename van het aantal verzoeken.
U kunt de langste query's volgen, dat wil zeggen de query's die het langst duren om te voltooien. Ze draaien op de processor en verbruiken I/O. We kunnen dit ook evalueren met behulp van de velden total_time, mean_time, blk_write_time en blk_read_time.
We kunnen de zwaarste verzoeken evalueren en monitoren in termen van bronnengebruik, verzoeken die van schijf lezen, die met geheugen werken of, omgekeerd, een soort schrijfbelasting creëren.
Wij kunnen de meest genereuze verzoeken beoordelen. Dit zijn de query's die een groot aantal rijen retourneren. Dit kan bijvoorbeeld een verzoek zijn waarbij ze vergeten een limiet in te stellen. En het retourneert eenvoudigweg de volledige inhoud van de tabel of query over de opgevraagde tabellen.
En u kunt ook query's monitoren die tijdelijke bestanden of tijdelijke tabellen gebruiken.
En we hebben nog steeds achtergrondprocessen. Achtergrondprocessen zijn in de eerste plaats controlepunten of worden ook wel controlepunten genoemd, dit zijn autovacuüm en replicatie.
Nog een voorbeeld van toezicht. Er is een tabblad Onderhoud aan de linkerkant, ga ernaartoe en hoop iets nuttigs te zien. Maar hier is alleen de tijd van vacuümoperaties en het verzamelen van statistieken, meer niet. Dit is zeer slechte informatie, dus we moeten altijd informatie hebben over hoe achtergrondprocessen in onze database werken en of er problemen zijn met hun werk.
Als we naar controlepunten kijken, moeten we niet vergeten dat controlepunten vuile pagina's van het gesharde geheugengebied naar de schijf spoelen en vervolgens een controlepunt creëren. En dit controlepunt kan vervolgens worden gebruikt als herstelplaats als PostgreSQL plotseling werd beëindigd in geval van nood.
Om alle "vuile" pagina's naar de schijf te spoelen, moet u dus een bepaalde hoeveelheid schrijven. En in de regel is dit veel op systemen met grote hoeveelheden geheugen. En als we heel vaak controlepunten uitvoeren met een kort interval, zullen de schijfprestaties aanzienlijk afnemen. En de verzoeken van klanten zullen lijden onder een gebrek aan middelen. Ze zullen strijden om hulpbronnen en een gebrek aan productiviteit hebben.
Dienovereenkomstig kunnen we via pg_stat_bgwriter met behulp van de opgegeven velden het aantal controlepunten dat optreedt controleren. En als we gedurende een bepaalde periode (in 10-15-20 minuten, in een half uur) veel controlepunten hebben, bijvoorbeeld 3-4-5, dan kan dit al een probleem zijn. En je moet al in de database kijken, in de configuratie kijken, wat zo'n overvloed aan controlepunten veroorzaakt. Misschien is er een grote opname aan de gang. We kunnen de werklast al evalueren, omdat we al werklastgrafieken hebben toegevoegd. We kunnen de controlepuntparameters al aanpassen en ervoor zorgen dat deze de queryprestaties niet sterk beïnvloeden.
Ik kom nog een keer terug op autovacuüm omdat het, zoals ik al zei, de prestaties van zowel schijven als query's gemakkelijk kan optellen, dus het is altijd belangrijk om de hoeveelheid autovacuüm te schatten.
Het aantal autovacuümwerkers in de database is beperkt. Standaard zijn er drie, dus als we altijd drie werknemers in de database hebben, betekent dit dat ons autovacuüm niet is geconfigureerd. We moeten de limieten verhogen, de autovacuüminstellingen herzien en naar de configuratie gaan.
Het is belangrijk om te evalueren welke vacuümwerkers we hebben. Of het werd gelanceerd door de gebruiker, de DBA kwam en lanceerde handmatig een soort vacuüm, en dit zorgde voor een belasting. We hebben een probleem. Of dit is het aantal stofzuigers dat de transactieteller losschroeft. Voor sommige versies van PostgreSQL zijn dit zeer zware stofzuigers. En ze kunnen de prestaties eenvoudig bij elkaar optellen omdat ze de hele tabel lezen en alle blokken in die tabel scannen.
En natuurlijk de duur van het stofzuigen. Als we duurzame stofzuigers hebben die heel lang meegaan, betekent dit dat we opnieuw aandacht moeten besteden aan de vacuümconfiguratie en misschien de instellingen ervan moeten heroverwegen. Omdat er een situatie kan ontstaan waarin het vacuüm lange tijd (3-4 uur) op de tafel werkt, maar gedurende de tijd dat het vacuüm werkte, wist zich weer een grote hoeveelheid dode rijen in de tafel op te hopen. En zodra het stofzuigen klaar is, moet hij deze tafel opnieuw stofzuigen. En we komen in een situatie: een eindeloos vacuüm. En in dit geval kan het vacuüm zijn werk niet aan en beginnen de tabellen geleidelijk aan in omvang te groeien, hoewel het volume aan nuttige gegevens daarin hetzelfde blijft. Daarom kijken we tijdens lange vacuüms altijd naar de configuratie en proberen deze te optimaliseren, maar tegelijkertijd zodat de prestaties van klantverzoeken er niet onder lijden.
Tegenwoordig is er vrijwel geen PostgreSQL-installatie die geen streaming-replicatie heeft. Replicatie is het proces waarbij gegevens van een master naar een replica worden verplaatst.
Replicatie in PostgreSQL gebeurt via een transactielogboek. De wizard genereert een transactielogboek. Het transactielogboek reist via de netwerkverbinding naar de replica en wordt vervolgens op de replica gereproduceerd. Het is makkelijk.
Dienovereenkomstig wordt de weergave pg_stat_replication gebruikt om de replicatievertraging te bewaken. Maar niet alles is eenvoudig bij haar. In versie 10 heeft de weergave verschillende wijzigingen ondergaan. Ten eerste zijn enkele velden hernoemd. En er zijn een aantal velden toegevoegd. In versie 10 verschenen velden waarmee u de replicatievertraging in seconden kunt schatten. Het is zeer comfortabel. Vóór versie 10 was het mogelijk om de replicatievertraging in bytes te schatten. Deze optie blijft in versie 10, dat wil zeggen dat u kunt kiezen wat het handigst voor u is: schat de vertraging in bytes of schat de vertraging in seconden. Veel mensen doen beide.
Maar toch, om de replicatievertraging te evalueren, moet u de positie van het logbestand in de transactie kennen. En deze transactielogboekposities bevinden zich precies in de pg_stat_replication-weergave. Relatief gesproken kunnen we twee punten uit het transactielogboek halen met behulp van de functie pg_xlog_location_diff(). Bereken de delta ertussen en verkrijg de replicatievertraging in bytes. Het is erg handig en eenvoudig.
In versie 10 werd deze functie hernoemd naar pg_wal_lsn_diff(). Over het algemeen werd het woord “xlog” in alle functies, weergaven en hulpprogramma's vervangen door de waarde “wal”. Dit geldt voor zowel weergaven als functies. Dit is zo'n innovatie.
Bovendien zijn er in versie 10 regels toegevoegd die specifiek de vertraging weergeven. Dit zijn schrijfvertraging, spoelvertraging en replayvertraging. Dat wil zeggen, het is belangrijk om deze dingen te monitoren. Als we zien dat we een replicatievertraging hebben, moeten we onderzoeken waarom deze is opgetreden, waar deze vandaan komt en het probleem oplossen.
Bijna alles is in orde met de systeemstatistieken. Wanneer monitoring begint, begint het met systeemstatistieken. Dit is de verwijdering van processors, geheugen, swap, netwerk en schijf. Veel parameters zijn er echter standaard niet.
Als alles in orde is met het recyclingproces, zijn er problemen met schijfrecycling. In de regel voegen monitoringontwikkelaars informatie over de doorvoer toe. Het kan in iops of bytes zijn. Maar ze vergeten de latentie en het gebruik van schijfapparaten. Dit zijn belangrijkere parameters waarmee we kunnen evalueren hoe belast onze schijven zijn en hoe langzaam ze zijn. Als we een hoge latentie hebben, betekent dit dat er enkele problemen zijn met de schijven. Als we een hoge bezettingsgraad hebben, betekent dit dat de schijven het niet aankunnen. Dit zijn betere eigenschappen dan doorvoer.
Bovendien kunnen deze statistieken ook worden verkregen uit het /proc-bestandssysteem, zoals wordt gedaan voor recyclingverwerkers. Ik weet niet waarom deze informatie niet aan de monitoring wordt toegevoegd. Maar toch is het belangrijk om dit in je monitoring te hebben.
Hetzelfde geldt voor netwerkinterfaces. Er is informatie over de netwerkdoorvoer in pakketten, in bytes, maar desalniettemin is er geen informatie over latentie en geen informatie over gebruik, hoewel dit ook nuttige informatie is.
Elke monitoring heeft nadelen. En welke monitoring u ook uitvoert, deze zal altijd niet aan bepaalde criteria voldoen. Maar toch zijn ze in ontwikkeling, er worden nieuwe functies en nieuwe dingen toegevoegd, dus kies iets en maak het af.
En om af te ronden moet u altijd een idee hebben van wat de verstrekte statistieken betekenen en hoe u deze kunt gebruiken om problemen op te lossen.
En een paar belangrijke punten:
- Je moet altijd de beschikbaarheid monitoren en over dashboards beschikken, zodat je snel kunt beoordelen of alles in orde is met de database.
- U moet altijd een idee hebben van welke klanten met uw database werken om slechte klanten uit te sluiten en neer te schieten.
- Het is belangrijk om te evalueren hoe deze klanten met data werken. U moet een idee hebben van uw werklast.
- Het is belangrijk om te evalueren hoe deze werklast wordt gevormd, met behulp van welke queries. U kunt query's evalueren, u kunt ze optimaliseren, refactoren en er indexen voor bouwen. Het is erg belangrijk.
- Achtergrondprocessen kunnen een negatieve invloed hebben op klantverzoeken, dus het is belangrijk om te controleren of ze niet te veel bronnen gebruiken.
- Met systeemstatistieken kunt u plannen maken voor het schalen en vergroten van de capaciteit van uw servers. Het is dus belangrijk om deze ook bij te houden en te evalueren.
Als u geïnteresseerd bent in dit onderwerp, kunt u deze links volgen.
- dit is officiële documentatie van de statistiekenverzamelaar. Er is een beschrijving van alle statistische weergaven en een beschrijving van alle velden. Je kunt ze lezen, begrijpen en analyseren. En op basis daarvan bouwt u uw grafieken en voegt u deze toe aan uw monitoring.
Voorbeelden aanvragen:
Dit is onze bedrijfsrepository en die van mij. Ze bevatten voorbeeldquery's. Er zijn geen zoekopdrachten uit de geselecteerde* uit series daar. Er zijn al kant-en-klare queries met joins, waarbij interessante functies worden gebruikt waarmee je ruwe getallen kunt omzetten in leesbare, handige waarden, d.w.z. dit zijn bytes, tijd. U kunt ze oppakken, bekijken, analyseren, toevoegen aan uw monitoring en op basis daarvan uw monitoring opbouwen.
vragen
Vraag: U zei dat u geen reclame voor merken gaat maken, maar ik ben nog steeds nieuwsgierig: wat voor soort dashboards gebruikt u in uw projecten?
Antwoord: Het varieert. Het komt voor dat we bij een klant komen en dat hij al zijn eigen monitoring heeft. En wij adviseren de klant over wat er aan zijn monitoring toegevoegd moet worden. De ergste situatie is bij Zabbix. Omdat het niet de mogelijkheid heeft om TopN-grafieken te bouwen. Wij gebruiken zelf , omdat we met deze jongens overlegden over monitoring. Ze monitorden PostgreSQL op basis van onze technische specificaties. Ik schrijf mijn eigen huisdierproject, dat gegevens verzamelt via Prometheus en deze weergeeft . Mijn taak is om mijn eigen exporteur in Prometheus te maken en alles vervolgens in Grafana weer te geven.
Vraag: Zijn er analogen van AWR-rapporten of... aggregatie? Weet jij iets als dit?
Antwoord: Ja, ik weet wat AWR is, het is cool. Op dit moment zijn er verschillende fietsen die ongeveer het volgende model implementeren. Met een bepaald tijdsinterval worden sommige basislijnen naar dezelfde PostgreSQL of naar een afzonderlijke opslag geschreven. Je kunt ze op internet googlen, ze zijn er. Een van de ontwikkelaars van zoiets zit op het sql.ru-forum in de PostgreSQL-thread. Daar kun je hem vangen. Ja, er zijn zulke dingen, ze kunnen worden gebruikt. Plus in zijn Ik schrijf ook iets waarmee jij hetzelfde kunt doen.
PS1 Als je postgres_exporter gebruikt, welk dashboard gebruik je dan? Er zijn er meerdere. Ze zijn al verouderd. Misschien zal de community een bijgewerkte sjabloon maken?
PS2 Pganalyze verwijderd omdat het een eigen SaaS-aanbod is dat zich richt op prestatiemonitoring en geautomatiseerde afstemmingssuggesties.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Welke zelfgehoste postgresql-monitoring (met dashboard) vindt u het beste?
-
30,0%Zabbix + toevoegingen van Alexey Lesovsky of zabbix 4.4 of libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze is een eigen SaaS - ik kan het niet verwijderen1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 gebruikers hebben gestemd. 26 gebruikers onthielden zich van stemming.
Bron: www.habr.com