{"id":32353,"date":"2019-10-31T21:46:32","date_gmt":"2019-10-31T18:46:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting\/"},"modified":"2019-10-31T21:46:32","modified_gmt":"2019-10-31T18:46:32","slug":"monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/monitoring-proizvoditelnosti-zaprosov-postgresql-chast-1-reporting","title":{"rendered":"Monitoring van de prestaties van PostgreSQL-queries. Deel 1 - rapportage","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ingenieur is in het Latijn ge\u00efnspireerd.
\nEen ingenieur kan alles. (c) R.Diesel.
\nEpigrafen.<\/i>
\n\"Monitoring
\nOf het verhaal over waarom een database-administrator zijn programmeerachtergrond moet herinneren. <\/i><\/p>\n

Voorwoord<\/h2>\n

\nAlle namen zijn gewijzigd. Toevalligheden zijn willekeurig. Het materiaal is uitsluitend de persoonlijke mening van de auteur.<\/p>\n

Disclaimer van garanties:<\/b> in de geplande serie artikelen zal er geen gedetailleerde en nauwkeurige beschrijving zijn van de gebruikte tabellen en scripts. Materialen kunnen niet meteen 'AS IS' worden gebruikt.
\nTen eerste vanwege de grote hoeveelheid materiaal,
\nten tweede vanwege de specificiteit in de productieomgeving van de echte klant.
\nDaarom zullen de artikelen alleen idee\u00ebn en beschrijvingen in de meest algemene zin bevatten.
\nMisschien groeit het systeem in de toekomst uit tot een niveau waarop het op GitHub kan worden geplaatst, en misschien ook niet. De tijd zal dat leren.<\/i><\/p><\/blockquote>\n

\nBegin van het verhaal - \"Weet je nog hoe het begon<\/a><\/noindex>\u00bb.
\nWat er als resultaat is ontstaan, in de meest algemene lijnen - \"Cloudflare heeft zijn eigen VPN-service gelanceerd op basis van de 1.1.1.1-app voor mobiele apparaten<\/a><\/noindex>\u00bb<\/p>\n

Waarom is dit allemaal voor mij?<\/h2>\n

\nNou, ten eerste om zelf niets te vergeten, als ik met pensioen ben en terugdenk aan die glorieuze dagen.
\nTen tweede om het geschrevene te systematiseren. Want soms begin ik zelf in de war te raken en vergeet ik bepaalde delen. <\/p>\n

En het belangrijkste - wie weet, misschien kan het iemand helpen en ervoor zorgen dat ze niet de fiets opnieuw uitvinden en niet op dezelfde rake botsten. Met andere woorden, om hun karma (niet habr's) te verbeteren. Want het waardevolste in deze wereld zijn idee\u00ebn. Het belangrijkste is om een idee te vinden. En het idee in werkelijkheid omzetten is al een puur technische kwestie.<\/p>\n

Laten we dus langzaam beginnen\u2026<\/p>\n

Probleemstelling.<\/h2>\n

<\/p>\n

Er is: <\/h3>\n

\nPostgreSQL-database (10.5), gemengde belasting (OLTP+DSS), gemiddelde-lage belasting, gelegen in de AWS-cloud.
\nDatabase-monitoring ontbreekt, infrastructuurmonitoring wordt geleverd via de standaardmiddelen van AWS in minimale configuratie.<\/p>\n

Benodigd:<\/h3>\n

\nDe prestaties en de toestand van de database monitoren, en de initi\u00eble informatie voor het optimaliseren van zware databasequery's vinden en hebben.
\n<\/a><\/noindex><\/p>\n

Korte inleiding of analyse van oplossingsvarianten<\/h2>\n

\nLaten we beginnen met het onderzoeken van de oplossingsvarianten vanuit het perspectief van een vergelijkende analyse van de voordelen en nadelen voor de ingenieur, terwijl het management zich maar moet bezighouden met de voordelen en kosten zoals het hoort volgens het personeelsregister.<\/p>\n

Variant 1 - \"Werken op aanvraag\"<\/h3>\n

\nWe leave everything as it is. If the client is not satisfied with something in the performance of the database or application, they will notify the DBA engineers by email or by creating an incident in the ticketing system.
\nThe engineer, upon receiving the notification, will investigate the problem, propose a solution, or postpone the issue, hoping that it resolves itself, and anyway, it will soon be forgotten.
\nCookies and donuts, bruises and bumps<\/b>Cookies and donuts:<\/b>
\n1. Nothing extra needs to be done
\n2. There is always a possibility to excuse oneself and slack off.
\n3. A lot of time can be spent at one's own discretion.
\nBruises and bumps:<\/b>
\n1. Sooner or later, the client will ponder the essence of existence and universal justice in this world, and once again, they will ask themselves the question \u2014 why am I paying them my money? The outcome is always the same \u2014 the only question is when the client will get bored and wave goodbye. And the feeder will empty. It's sad.
\n2. The engineer's development is zero.
\n3. Difficulties in planning work and loading <\/p>\n

Option 2 - \"We dance with tambourines, pushing and shoeing\"<\/h3>\n

\nPoint 1<\/b>-Why do we need a monitoring system? We will get everything through requests. We launch a bunch of various requests to the data dictionary and dynamic views, enable various counters, compile everything into tables, periodically, sort of, analyze the lists and tables. As a result, we have beautiful or not so beautiful graphics, tables, reports. The main thing is to have more, more.
\nPoint 2<\/b>-We generate activity - we start analyzing all of this.
\nPoint 3<\/b>-We prepare some document, simply calling this document - \"how to organize our database.\"
\nPoint 4<\/b>-The client, seeing all this magnificence of graphs and numbers, remains in a childlike naive confidence - now everything will work, soon. And easily and painlessly, they part with their financial resources. Management is also confident - our engineers are doing great. Load is at maximum.
\nPoint 5<\/b>-Regularly repeat Point 1.
\nCookies and donuts, bruises and bumps<\/b>Cookies and donuts: <\/b>
\n1. The life of managers and engineers is simple, predictable, and filled with activity. Everything is buzzing, everyone is busy.
\n2. The client's life is also not bad - they are always sure that they just need to be a little more patient and everything will be fine. It doesn\u2019t get better, well, what can you do - this world is unfair, next life - luckier.
\nBruises and bumps:<\/b>
\n1. Op een gegeven moment zal er wel een snellere aanbieder van een vergelijkbare dienst komen die hetzelfde doet, maar iets goedkoper is. En als het resultaat hetzelfde is, waarom meer betalen? Dit zal opnieuw leiden tot het verdwijnen van de geldstroom.
\n2. Dit is saai. Zoals elke weinig zinnige activiteit.
\n3. Zoals in de vorige variant \u2014 er is geen ontwikkeling. Maar voor de engineer is het minpunt dat, in tegenstelling tot de eerste variant, hier constant een database moet worden gegenereerd. En dat kost tijd. Tijd die je beter aan jezelf kunt besteden. Want als je niet voor jezelf zorgt, doet niemand het.<\/p>\n

Variant 3 - Je hoeft het wiel niet opnieuw uit te vinden, je moet het kopen en gaan fietsen.<\/h3>\n

\nIngenieurs van andere bedrijven eten niet voor niets pizza met bier (oh, de glorieuze tijden in Sint-Petersburg in de jaren '90). Laten we gebruikmaken van monitoring systemen die zijn gemaakt, verfijnd en werken, en die, laten we wel wezen, eigenlijk nuttig zijn (tenzij voor hun makers).
\nCookies and donuts, bruises and bumps<\/b>Cookies and donuts:<\/b>
\n1. Je hoeft geen tijd te besteden aan het verzinnen van wat al is uitgevonden. Neem het en gebruik het.
\n2. Monitoring systemen worden niet door domme mensen geschreven en ze zijn natuurlijk nuttig.
\n3. Werkende monitoring systemen bieden doorgaans nuttige gefilterde informatie.
\nBruises and bumps:<\/b>
\n1. De engineer is in dit geval geen engineer, maar gewoon een gebruiker van iemands product. Of een gebruiker.
\n2. De opdrachtgever moet worden overtuigd van de noodzaak om iets te kopen waar hij eigenlijk niet in ge\u00efnteresseerd is, en dat moet hij ook niet zijn. Bovendien is het budget voor het jaar goedgekeurd en zal dit niet veranderen. Daarna moet er een aparte bron worden toegewezen, afgestemd op het specifieke systeem. Dus eerst moet je betalen, betalen en nog eens betalen. En de opdrachtgever is gierig. Dit is de norm van het leven.<\/p>\n

Wat te doen - Tsjernysjovski? Jouw vraag is zeer relevant. (c)<\/h2>\n

\nIn dit specifieke geval en de huidige situatie kunnen we het iets anders aanpakken \u2014 laten we ons eigen monitoring systeem maken. <\/b>
\n\"Monitoring
\nNou, niet echt een systeem in de volle zin van het woord, dat is een te talige en zelfingenomen uitspraak, maar laten we proberen het onszelf iets gemakkelijker te maken en meer informatie te verzamelen voor het oplossen van prestatie-incidenten. Zodat we niet in de situatie komen \u2014 \u201cga daarheen, weet niet waar, vind dat, weet niet wat\u201d.<\/p>\n

Wat zijn de voordelen en nadelen van deze optie:<\/h4>\n

Voordelen:<\/b>
\n1. Dit is interessant. In ieder geval interessanter dan constante \u2018shrink datafile, alter tablespace, etc.\u2019
\n2. Dit zijn nieuwe vaardigheden en een nieuwe ontwikkeling. Wat op de lange termijn vroeg of laat de verdiende beloningen en lekkernijen zal opleveren.
\nNadelen:<\/b>
\n1. We moeten aan de bak. Veel werken.
\n2. We moeten regelmatig de betekenis en de vooruitzichten van alle activiteiten uitleggen.
\n3. We moeten ergens voor opofferen, omdat de enige beschikbare bron voor een ingenieur \u2014 tijd \u2014 beperkt is door het universum.
\n4. Het ergste en het meest onaangename<\/b> \u2014 kan resulteren in iets als 'Geen muis, geen kikker, maar een onbekend beestje'.<\/p>\n

Wie niet waagt, die niet wint.<\/b>
\nDus \u2014 het interessantste begint nu.<\/p>\n

Het algemene idee \u2014 schematisch.<\/h2>\n

\n\"Monitoring
\n(De illustratie is afkomstig uit een artikel.<\/i> \u00abCloudflare heeft zijn eigen VPN-service gelanceerd op basis van de 1.1.1.1-app voor mobiele apparaten<\/a><\/noindex>\u00bb)<\/p>\n

Uitleg:<\/p>\n