Ek stel voor om die transkripsie van die verslag deur Nikolai Samokhvalov te lees "Industriële benadering tot die instel van PostgreSQL: eksperimente op databasisse"
Shared_buffers = 25% - is dit baie of 'n bietjie? Of net reg? Hoe weet jy of hierdie—taamlik verouderde—aanbeveling reg is vir jou?
Dit is tyd om die kwessie van die keuse van postgresql.conf-parameters "op 'n volwasse manier" te benader. Nie met die hulp van blinde "outo-tuners" of verouderde advies van artikels en blogs nie, maar gebaseer op:
- streng geverifieerde eksperimente op die databasis, outomaties uitgevoer, in groot hoeveelhede en onder toestande so na as moontlik aan "bestryding",
- diepgaande begrip van die kenmerke van die DBMS en OS.
Gebruik Nancy CLI (), sal ons 'n spesifieke voorbeeld oorweeg - die berugte shared_buffers - in verskillende situasies, in verskillende projekte en probeer uitvind hoe om die optimale instelling vir ons infrastruktuur, databasis en werklading te kies.
Dit gaan oor eksperimentering met databasisse. Dit is 'n storie wat vir 'n bietjie meer as ses maande aanhou.
'n Bietjie oor my. Ervaring met Postgres vir meer as 14 jaar. 'n Aantal maatskappye het sosiale netwerke gestig. Postgres is en word oral gebruik.
Ook RuPostgres-groep op Meetup, 2de in die wêreld. Ons nader stadig 2 000 mense. RuPostgres.org.
En in die rekenaars van verskeie konferensies, insluitend Highload, was ek van die begin af in beheer van databasisse, veral Postgres.
En in die laaste paar jaar het ek my Postgres-konsultasiepraktyk in 11 tydsones van hier af weer begin.
En toe ek dit 'n paar jaar gelede gedoen het, het ek 'n bietjie onderbreking gehad van aktiewe handwerk met Postgres, waarskynlik sedert 2010. Ek was verbaas hoe min die DBA-werksdae verander het, hoeveel hande-arbeid nog gebruik moes word. En ek het dadelik gedink dat hier iets fout is, ons moet meer van alles outomatiseer.
En aangesien dit alles afgeleë was, was die meeste van die kliënte in die wolke. En alreeds is baie geoutomatiseer natuurlik. Meer hieroor later. Dit wil sê, dit alles het gelei tot die idee dat daar 'n aantal hulpmiddels moet wees, dit wil sê 'n sekere platform wat byna alle DBA-aksies sal outomatiseer sodat jy 'n groot aantal databasisse kan bestuur.
Hierdie verslag sal nie:
- Silwer koeëls en tipe verklarings - gaan vir 8 GB of 25% shared_buffers en jy sal reg wees. Daar sal nie veel oor shared_buffers wees nie.
- Hardcore "binnekant".
En wat sal gebeur?
- Daar sal optimeringsbeginsels wees wat ons toepas en ontwikkel. Daar sal allerhande idees wees wat oor ons pad kom en verskillende hulpmiddels wat ons grotendeels in Open Source skep, dit wil sê, ons maak die grondslag in Open Source. Boonop het ons kaartjies, alle kommunikasie is feitlik in oopbron. Jy kan sien wat ons nou doen, wat in die volgende uitgawe sal wees, ens.
- En daar sal ook 'n mate van ervaring wees met die gebruik van hierdie beginsels, hierdie hulpmiddels in 'n aantal maatskappye: van klein beginners tot groot maatskappye.
Hoe ontwikkel dit alles?
Eerstens is die hooftaak van DBA, benewens om die skep van gevalle te verseker, die ontplooiing van rugsteun, ens., om knelpunte te vind en werkverrigting te optimaliseer.
Nou is dit so opgestel. Ons kyk na die monitering, ons sien iets, ons kort 'n paar besonderhede. Ons begin versigtiger grawe, gewoonlik met ons hande, en verstaan wat om op een of ander manier daarmee te doen.
En daar is twee benaderings. pg_stat_statements is die verstek oplossing vir die identifisering van stadige navrae. En ontleed Postgres-logboeke met pgBadger.
Elke benadering het ernstige nadele. In die eerste benadering het ons al die parameters weggegooi. En as ons groepe SELECT * FROM tabel sien waar die kolom gelyk is aan die teken "?" of "$" sedert Postgres 10. Ons weet nie of dit indeksskandering of vervolgskandering is nie. Baie hang af van die parameter. Jy sal vervang daar selde ontmoet waarde, sal daar indeks skandering. Vervang 'n waarde daar wat 90% van die tabel beslaan, seq scan sal voor die hand liggend wees, want Postgres ken die statistieke. En dit is 'n groot nadeel van pg_stat_statements, hoewel sommige werk aan die gang is.
Loganalise het die grootste nadeel dat jy nie "log_min_duration_statement = 0" as 'n reël kan bekostig nie. En ons sal ook daaroor praat. Gevolglik sien jy nie die hele prentjie nie. En 'n versoek wat baie vinnig is, kan 'n groot hoeveelheid hulpbronne verbruik, maar jy sal dit nie sien nie, want dit is onder jou drempel.
Hoe los DBA's die probleme op wat hulle vind?
Ons het byvoorbeeld 'n probleem gevind. Wat word gewoonlik gedoen? As jy 'n ontwikkelaar is, sal jy in een of ander geval iets doen wat nie van daardie grootte is nie. As jy 'n DBA is, dan het jy verhoog. En daar kan net een wees. En hy was ses maande agter. En jy dink jy sal na produksie gaan. En selfs ervare DBA's kontroleer dit dan in produksie, op 'n replika. En dit gebeur dat hulle 'n tydelike indeks skep, seker maak dat dit help, dit laat val en dit aan die ontwikkelaars gee sodat hulle dit in die migrasielêers plaas. Dit is die soort kak wat nou gebeur. En dit is 'n probleem.
- Verstel die konfigurasie.
- Optimaliseer 'n stel indekse.
- Verander die SQL-navraag self (dit is die moeilikste manier).
- Voeg kapasiteit by (die maklikste manier in die meeste gevalle).
Daar is baie dinge met hierdie dinge. Daar is baie handvatsels in Postgres. Jy moet baie weet. Baie indekse in Postgres, ook dankie aan die organiseerders van hierdie konferensie. En dit alles moet bekend wees, en dit is wat nie-DBA's laat voel asof DBA's swart magie doen. Dit wil sê, jy moet vir 10 jaar studeer om te begin verstaan dat dit alles normaal is.
En ek is 'n vegter met hierdie swart magie. Ek wil alles doen sodat daar tegnologie is, en daar is geen intuïsie in dit alles nie.
Werklike voorbeelde
Ek het dit in ten minste twee projekte waargeneem, insluitend myne. Nog 'n blogpos vertel ons dat 'n waarde van 1 000 vir default_statistict_target goed is. Goed, kom ons probeer dit in produksie.
En hier is ons, met behulp van ons instrument twee jaar later, met behulp van eksperimente op databasisse, waaroor ons vandag praat, kan ons vergelyk wat was en wat geword het.
En hiervoor moet ons 'n eksperiment skep. Dit bestaan uit vier dele.
- Die eerste is die omgewing. Ons het 'n stuk yster nodig. En as ek by een of ander maatskappy kom en 'n kontrak sluit, sê ek dat hulle vir my dieselfde stuk yster gee as in produksie. Vir elkeen van jou Meesters het ek ten minste een stuk yster van dieselfde soort nodig. Óf dit is 'n virtuele masjien in Amazon of Google, óf ek het presies dieselfde hardeware nodig. Dit wil sê, ek wil die omgewing herskep. En ons plaas die belangrikste weergawe van Postgres in die konsep van omgewing.
- Die tweede deel is die doel van ons navorsing. Dit is 'n databasis. Dit kan op verskeie maniere geskep word. Ek sal jou wys hoe.
- Die derde deel is die las. Dit is die moeilikste oomblik.
- En die vierde deel is wat ons nagaan, dit wil sê wat ons met wat sal vergelyk. Kom ons sê ons kan een of meer parameters in die konfigurasie verander, of ons kan 'n indeks skep, ens.
Ons begin 'n eksperiment. Hier is pg_stat_statements. Aan die linkerkant is wat gebeur het. Aan die regterkant - wat het gebeur.
Aan die linkerkant, default_statistics_target = 100, aan die regterkant = 1 000. Ons kan sien dat dit ons gehelp het. Met 8% in die algemeen het dinge beter geword.
Maar as ons afblaai, sal daar versoekgroepe van pgBadger of van pg_stat_statements wees. Daar is twee opsies. Ons sal sien dat sommige versoeke met 88% gedaal het. En dan is daar die ingenieursbenadering. Ons kan verder na binne grawe, want ons wonder hoekom hy gesink het. Jy moet verstaan wat met die statistiek gebeur het. Waarom meer emmers in statistieke lei tot 'n slegter resultaat.
Of ons kan nie grawe nie, maar doen “ALTER TABLE ... ALTER COLUMN” en ons sal 100 emmers terugstuur na die statistieke van hierdie kolom. En verder eksperimenteer ons kan seker maak dat hierdie pleister gehelp het. Almal. Dit is 'n ingenieursbenadering wat ons help om die groot prentjie te sien en besluite te neem gebaseer op data eerder as op intuïsie.
'n Paar voorbeelde uit ander gebiede. Daar is nou al baie jare CI-toetse in toetse. En geen projek by sy volle verstand sal leef sonder outomatiese toetse nie.
In ander bedrywe: in lugvaart, in die motorbedryf, wanneer ons aërodinamika toets, het ons ook die geleentheid om eksperimente te maak. Ons sal nie dadelik iets van die tekening na die ruimte lanseer nie, of ons sal nie dadelik een of ander motor op die baan sit nie. Daar is byvoorbeeld 'n windtonnel.
Uit waarnemings van ander industrieë kan ons gevolgtrekkings maak.
Eerstens het ons 'n spesiale omgewing. Dit is naby produksie, maar nie naby nie. Die belangrikste kenmerk daarvan is dat dit goedkoop, herhaalbaar en so outomaties as moontlik moet wees. En daar moet spesiale gereedskap wees vir gedetailleerde ontleding.
Heel waarskynlik, toe ons die vliegtuig gelanseer en vlieg, het ons minder geleentheid om elke millimeter van die vlerkoppervlak te bestudeer as wat ons in 'n windtonnel het. Ons het meer diagnostiese hulpmiddels. Ons kan bekostig om meer van alles swaar te hang wat ons nie kan bekostig om die vliegtuig in die lug te besoek nie. Ook met Postgres. Ons kan, in sommige gevalle, volledige navraagregistrasie tydens eksperimente aktiveer. En ons wil dit nie in produksie doen nie. Ons kan selfs planne insluit om dit moontlik te maak met behulp van auto_explain.
En soos ek gesê het, 'n hoë vlak van outomatisering beteken dat ons die knoppie gedruk en herhaal het. Dit is hoe dit moet wees, sodat daar baie eksperimente is, sodat dit aan die gang is.
Nancy CLI - die grondslag van die "databasislaboratorium"
En so het ons so iets gedoen. Dit wil sê, ek het in Junie, amper 'n jaar gelede, oor hierdie idees gepraat. En ons het reeds die sogenaamde Nancy CLI in oopbron. Dit is die grondslag vir die bou van die databasislaboratorium.
- Dit is in oopbron, op Gitlab. Jy kan sê jy kan probeer. Ek het 'n skakel in die skyfies verskaf. Jy kan daarop klik en dit sal in alle opsigte.
Natuurlik is daar nog baie in ontwikkeling. Daar is baie idees daar buite. Maar dit is wat ons byna daagliks gebruik. En wanneer ons 'n idee het - en wat is dit met die verwydering van 40 reëls, alles het op IO gerus, dan kan ons 'n eksperiment uitvoer en in meer besonderhede kyk om te verstaan wat gebeur en dan probeer om dit op die pad reg te stel. Dit wil sê, ons doen 'n eksperiment. Ons verdraai byvoorbeeld iets en sien wat op die ou end gebeur. En ons doen dit nie in produksie nie. Dit is die kern van die idee.
Waar kan dit werk? Dit kan plaaslik werk, dit wil sê jy kan dit enige plek doen, jy kan dit selfs op 'n MacBook laat loop. Ons het 'n dokwerker nodig, kom ons gaan. En dit is dit. Jy kan dit in een of ander geval in 'n stuk hardeware, of in 'n virtuele masjien, enige plek laat loop.
En daar is ook die vermoë om op 'n afstand in Amazon te hardloop in EC2 Instance, in kolle. En dit is 'n baie oulike geleentheid. Ons het byvoorbeeld gister meer as 500 eksperimente op i3-gevalle uitgevoer, wat begin met die jongste en eindig met i3-16-xlarge. En 500 eksperimente het ons $64 gekos. Elkeen het 15 minute geduur. Dit wil sê, as gevolg van die feit dat kolle daar gebruik word, is dit baie goedkoop - 'n 70% afslag, vra Amazon per sekonde. Jy kan baie doen. Jy kan werklike navorsing doen.
En drie hoof weergawes van Postgres word ondersteun. Dit is nie so moeilik om 'n ou en nuwe 12de weergawe ook klaar te maak nie.
Ons kan 'n voorwerp op drie maniere definieer. Dit:
- Dump/sql-lêer.
- Die belangrikste manier is om die PGDATA-gids te kloon. As 'n reël word dit van die rugsteunbediener geneem. As jy normale binêre rugsteun het, kan jy van daar af klone maak. As jy wolke het, dan is dit 'n wolkkantoor soos Amazon en Google self sal dit vir jou doen. Dit is die belangrikste manier vir regte produksieklone. Dit is hoe ons afrol.
- En die laaste metode is geskik vir navorsing, wanneer daar 'n begeerte is om uit te vind hoe een of ander ding in Postgres werk. Dit is pgbench. Jy kan genereer met pgbench. Dit is net een "db-pgbench" opsie. Jy vertel hom watter skaal. En alles sal in die wolk gegenereer word, soos daar gesê word.
En laai:
- Ons kan die las in een SQL-draad uitvoer. Dit is die mees primitiewe manier.
- En ons kan die las naboots. En ons kan dit eerstens op die volgende manier naboots. Ons moet al die logs versamel. En dit is pynlik. Ek sal jou wys hoekom. En met die hulp van pgreplay speel ons, wat in Nancy ingebou is.
- Of 'n ander opsie. Die sogenaamde handwerkvrag, wat ons met 'n sekere hoeveelheid moeite doen. Deur ons huidige las op die gevegstelsel te ontleed, trek ons die topgroepe versoeke uit. En met die hulp van pgbench kan ons hierdie vrag in die laboratorium naboots.
- Of ons moet 'n bietjie SQL uitvoer, dit wil sê ons kyk na 'n soort migrasie, skep 'n indeks daar, voer ANALAZE daar uit. En ons kyk wat gebeur het voor die vakuum en na die vakuum. In die algemeen, enige SQL.
- Of ons verander een of meer parameters in die konfigurasie. Ons kan ons vertel om byvoorbeeld 100 waardes in Amazon na te gaan vir ons teragreep-databasis. En oor 'n paar uur sal jy die resultaat hê. As 'n reël sal 'n teragreep-databasis 'n paar uur neem om te ontplooi. Maar daar is 'n pleister in ontwikkeling, ons het 'n reeks moontlik, dit wil sê jy kan konsekwent dieselfde pgdata op dieselfde bediener gebruik en kyk. Postgres sal herbegin, kas sal gespoel word. En jy kan die vrag bestuur.
- 'n Gids arriveer waarin 'n klomp allerhande lêers begin, vanaf pg-kiekiesstat***. En daar is die interessantste ding pg_stat_statements, pg_stat_kcacke. Dit is twee uitbreidings wat navrae ontleed. En pg_stat_bgwriter bevat nie net pgwriter-statistieke nie, maar ook kontrolepuntstatistieke en hoe die backends self vuil buffers verdring. En dit is alles interessant om te sien. Byvoorbeeld, wanneer ons shared_buffers opstel, is dit baie interessant om te sien hoeveel iemand verdring het.
- Postgres logs kom ook. Twee logs - die log van voorbereiding en die log van die speel van die vrag.
- 'n Relatief nuwe kenmerk is FlameGraphs.
- Ook, as jy pgreplay of pgbench load herspeel opsies gebruik het, sal hul uitset inheems wees. En jy sal latency en TPS sien. Dit sal moontlik wees om te verstaan hoe hulle dit gesien het.
- Inligting oor die stelsel.
- Basiese SVE- en IO-kontroles. Dit is meer vir EC2-instansies in Amazon, wanneer jy 100 identiese gevalle in 'n draad wil laat loop en 100 verskillende lopies daar wil uitvoer, dan sal jy 10 000 eksperimente hê. En jy moet seker maak dat jy nie 'n gebrekkige geval teëkom wat iemand reeds onderdruk nie. Ander is aktief op hierdie stuk yster en jy het min hulpbron oor. Dit is beter om sulke resultate weg te gooi. En net met die hulp van sysbench van Alexey Kopytov, doen ons 'n paar kort kontroles wat sal kom en met ander vergelyk kan word, dit wil sê, jy sal verstaan hoe die SVE optree en hoe IO optree.
Wat is die tegniese probleme op die voorbeeld van verskillende maatskappye?
Kom ons sê ons wil die werklike vrag herhaal met behulp van logs. Goeie idee as dit in Open Source pgreplay geskryf is. Ons gebruik dit. Maar om goed te werk, moet u volledige versoekregistrasie met parameters en tydsberekening aktiveer.
Daar is 'n paar komplikasies oor duur en tydstempel. Ons gaan hierdie kombuis los. Die groot vraag is, kan jy dit bekostig of kan jy nie?
Die probleem is dat dit dalk nie beskikbaar is nie. U moet eerstens verstaan watter stroom na die log geskryf sal word. As jy pg_stat_statements het, kan jy hierdie versoek gebruik (die skakel sal in die skyfies beskikbaar wees) om te verstaan hoeveel grepe per sekonde geskryf sal word.
Ons kyk na die lengte van die versoek. Ons verwaarloos die feit dat daar geen parameters is nie, maar ons ken die lengte van die versoek en ons weet hoeveel keer per sekonde dit uitgevoer is. Ons kan dus skat hoeveel grepe per sekonde. Ons kan omtrent twee keer 'n fout maak, maar ons sal beslis die volgorde op hierdie manier verstaan.
Ons kan sien dat hierdie versoek 802 keer per sekonde uitgevoer word. En ons sien dat bytes_per sek - 300 kB / s plus of minus geskryf sal word. En as 'n reël kan ons so 'n vloei bekostig.
Maar! Die feit is dat daar verskillende logstelsels is. En by verstek het mense gewoonlik "syslog".
En as jy syslog het, kan jy hierdie prentjie hê. Ons sal pgbench neem, versoekaantekening aktiveer en kyk wat gebeur.
Sonder om aan te meld - dit is die kolom aan die linkerkant. Ons het 161 000 TPS gekry. Met syslog - dit is in Ubuntu 16.04 op Amazon, ons kry 37 000 TPS. En as ons na twee ander logmetodes verander, dan is die situasie baie beter. Dit wil sê, ons het verwag dat dit sou sink, maar nie met dieselfde hoeveelheid nie.
En op CentOS 7, waaraan journald ook deelneem, om die logs in 'n binêre formaat te verander vir maklike soek, ens., dan is dit 'n nagmerrie daar, ons sak 44 keer in TPS.
En dit is waarmee mense saamleef. En dikwels in maatskappye, veral in grotes, is dit baie moeilik om te verander. As jy van syslog kan wegkom, kom asseblief weg daarvan.
- Skat IOPS en skryf vloei.
- Gaan jou aantekenstelsel na.
- As die voorspelde lading buitensporig is, oorweeg steekproefneming.
Ons het pg_stat_statements. Soos ek gesê het, dit moet wees. En ons kan elke groep versoeke op 'n spesiale manier in 'n lêer neem en beskryf. En dan kan ons 'n baie gerieflike kenmerk in pgbench gebruik - dit is die vermoë om verskeie lêers te skuif deur die "-f" opsie te gebruik.
Hy verstaan baie "-f". En jy kan met "@" aan die einde sê watter deel elke lêer moet hê. Dit wil sê, ons kan sê dat hierdie een in 10% van die gevalle uitgevoer word, en hierdie een in 20%. En dit sal ons nader bring aan wat ons in produksie sien.
En hoe sal ons verstaan wat ons in produksie het? Watter aandeel en hoe? Bietjie van 'n syspoor hier. Ons het 'n ander produk . Ook 'n basis in Open Source. En nou ontwikkel ons dit aktief.
Hy is om effens ander redes gebore. Om redes dat monitering nie genoeg is nie. Dit wil sê, jy kom kyk na die basis, kyk na die probleme wat bestaan. En, as 'n reël, doen jy health_check. As jy 'n ervare DBA is, doen jy 'n gesondheidsondersoek. Ons het gekyk na die gebruik van indekse, ens. As jy OKmeter het, dan is dit wonderlik. Dit is 'n koel monitering vir Postgres. OKmeter.io - installeer dit asseblief, alles is baie gaaf daar. Hy word betaal.
As jy dit nie het nie, dan het jy gewoonlik nie veel om te eet nie. In monitering is daar gewoonlik 'n SVE, IO, en dan met besprekings, en dit is dit. En ons het meer nodig. Ons moet sien hoe outovacuum werk, hoe kontrolepunt werk, in io moet ons kontrolepunt van bgwriter en van backends skei, ens.
Die probleem is dat wanneer jy een of ander groot maatskappy help, hulle nie iets vinnig kan implementeer nie. Kan nie vinnig OKmeter koop nie. Miskien sal hulle dit oor ses maande koop. Hulle kan sommige pakkette nie vinnig aflewer nie.
En ons het met die idee vorendag gekom dat ons so 'n spesiale instrument nodig het wat niks vereis om geïnstalleer te word nie, dit wil sê, jy hoef glad nie iets op produksie te plaas nie. Installeer dit op jou skootrekenaar, of op die waarnemingsbediener, van waar jy sal begin. En dit sal baie dinge ontleed: die bedryfstelsel, die lêerstelsel en Postgres self, wat 'n paar ligte navrae maak wat direk op produksie uitgevoer kan word en niks sal val nie.
Ons het dit Postgres-checkup genoem. Medies gesproke is dit 'n gereelde gesondheidsondersoek. As dit in die motor-tema is, dan is dit soos MOT. Jy doen onderhoud aan die motor elke ses maande of 'n jaar, afhangende van die handelsmerk. Doen jy onderhoud vir jou basis? Dit wil sê, doen jy gereeld diep navorsing? Dit moet gedoen word. As jy rugsteun maak, kyk dan na, dit is nie minder belangrik nie.
En ons het so 'n hulpmiddel. Hy het eers sowat drie maande gelede aktief begin opkom. Hy is nog jonk, maar daar is baie goed daar buite.
Ons versamel die mees "invloedryke" groepe versoeke - rapporteer K003 in Postgres-checkup
En daar is 'n groep verslae K. Drie verslae tot dusver. En daar is so 'n verslag K003. Daar is 'n top van pg_stat_statements gesorteer volgens totaal_tyd.
Wanneer ons volgens totale_tyd groepe versoeke sorteer, dan sien ons boaan 'n groep wat ons stelsel die meeste laai, dit wil sê meer hulpbronne verbruik. Hoekom noem ek navraaggroepe? Omdat ons die parameters uitgegooi het. Dit is nie meer navrae nie, maar groepe navrae, dit wil sê hulle word geabstraheer.
En as ons van bo na onder optimaliseer, sal ons ons hulpbronne ligter maak en die oomblik vertraag wanneer ons moet opgradeer. Dit is 'n baie goeie manier om geld te spaar.
Miskien is dit nie 'n goeie manier om vir gebruikers te sorg nie, want ons sal dalk nie seldsame, maar baie irriterende gevalle sien wanneer 'n persoon 15 sekondes gewag het nie. Kortom, hulle is so skaars dat ons hulle nie sien nie, maar ons is besig met hulpbronne.
Wat het in hierdie tabel gebeur? Ons het twee foto's geneem. Postgres_checkup sal jou 'n delta vir elke metriek gee: vir totale tyd, oproepe, rye, shared_blks_read, ens. Dit is dit, ek het die delta bereken. Die groot probleem met pg_stat_statements is dat dit nie onthou wanneer dit teruggestel is nie. As pg_stat_database onthou, dan doen pg_stat_statements nie. Jy sien dat daar 1 000 000 getal is, maar ons weet nie waar ons vandaan getel het nie.
En hier weet ons, hier het ons twee kiekies. Ons weet dat die delta in hierdie geval 56 sekondes was. Baie klein gaping. Gesorteer volgens totaal_tyd. En dan kan ons differensieer, dit wil sê ons verdeel al die metrieke volgens duur. As ons elke maatstaf volgens duur verdeel, sal ons die aantal oproepe per sekonde hê.
Vervolgens is totale_tyd per sekonde my gunsteling maatstaf. Dit word gemeet in sekondes, per sekonde, dit wil sê hoeveel sekondes dit ons stelsel geneem het om hierdie groep versoeke per sekonde te voltooi. As jy meer as 'n sekonde per sekonde daar sien, beteken dit dat jy meer as een kern moes gee. Dit is 'n baie goeie maatstaf. Jy kan verstaan dat hierdie vriend byvoorbeeld ten minste drie kerne benodig.
Dit is ons know-how, ek het dit nêrens gesien nie. Let op - dit is 'n baie eenvoudige ding - 'n sekonde per sekonde. Soms, wanneer jou SVE 100% is, dan 'n halfuur per sekonde, d.w.s. jy het net 'n halfuur spandeer om hierdie navrae te doen.
Verder sien ons rye per sekonde. Ons weet hoeveel rye per sekonde dit teruggegee het.
En dan nog 'n interessante ding. Hoeveel shared_buffers per sekonde lees ons van shared_buffers self. Die treffers was reeds daar, en ons het die rye van die bedryfstelsel-kas geneem, of vanaf die skyf. Die eerste opsie is vinnig, terwyl die tweede vinnig kan wees of nie, afhangende van die situasie.
En die tweede manier van differensiasie - ons verdeel die aantal versoeke in hierdie groep. In die tweede kolom sal jy altyd een versoek per versoek verdeel. En dan is dit interessant - hoeveel millisekondes was in hierdie versoek. Ons weet hoe hierdie navraag gemiddeld optree. 101 millisekondes was nodig vir elke versoek. Dit is die tradisionele maatstaf wat ons moet verstaan.
Hoeveel rye elke navraag gemiddeld teruggekeer het. Ons sien 8 hierdie groep keer terug. Hoeveel is gemiddeld uit die kas geneem en gelees. Ons sien alles is mooi gekas. Stewige treffers vir die eerste groep.
En die vierde substring in elke reël is hoeveel persent van die totaal. Ons het oproepe. Kom ons sê 1 000 000. En ons kan verstaan hoeveel hierdie groep bydra. Ons sien dat in hierdie geval die eerste groep minder as 0,01% bydra. Dit wil sê, dit is so stadig dat ons dit nie in die groot prentjie sien nie. En die tweede groep - 5% op oproepe. Dit wil sê, 5% van alle oproepe is die tweede groep.
Teen totaal_tyd is ook interessant. Ons het 14% van die totale tyd aan die eerste groep versoeke bestee. En vir die tweede - 11%, ens.
Ek gaan nie in besonderhede in nie, maar daar is subtiliteite. Ons vertoon 'n fout van bo, want wanneer ons vergelyk, kan momentopnames dryf, d.w.s. sommige versoeke kan uitval en in die tweede een kan hulle nie anders as om teenwoordig te wees nie, en sommige nuwes kan verskyn. En ons bereken die fout daar. As jy 0 sien, dan is dit goed. Dit is geen fout nie. As die foutkoers tot 20% is, is dit in orde.
Dan keer ons terug na ons onderwerp. Ons moet die werklading handwerk. Ons neem van bo na onder en gaan totdat ons 80% of 90% bereik. Gewoonlik is dit 10-20 groepe. En ons maak lêers vir pgbench. Ons gebruik random daar. Soms werk dit ongelukkig nie. En in Postgres 12 sal daar meer opsies wees om hierdie benadering te gebruik.
En dan kry ons 80-90% van totale_tyd op hierdie manier. Wat volgende om te vervang na "@"? Ons kyk na oproepe, kyk hoeveel persent en verstaan dat ons soveel persent hier skuld. Uit hierdie persentasies kan ons uitvind hoe om elk van die lêers te balanseer. Daarna gebruik ons pgbench en gaan werk toe.
Ons het ook K001 en K002.
K001 is een groot string met vier substringe. Dit is 'n kenmerk van ons hele vrag. Sien tweede kolom en tweede substring. Ons sien dat een en 'n half sekondes per sekonde ongeveer is, dit wil sê as daar twee kerns is, dan sal dit goed wees. Daar sal ongeveer 75% laai wees. En dis hoe dit sal werk. As ons 10 kerne het, sal ons oor die algemeen kalm wees. Sodat ons hulpbronne kan evalueer.
K002 is wat ek die navraagklasse noem, dit wil sê SELECT, INSERT, UPDATE, DELETE. En apart KIES VIR BYWERKING, want dit sluit.
En hier kan ons tot die gevolgtrekking kom dat SELECT gewone lesers - 82% van alle oproepe, maar terselfdertyd - 74% van totale_tyd. Dit wil sê, hulle word baie genoem, maar verbruik die hulpbron minder.
En ons keer terug na die vraag: "Hoe kies ons die regte shared_buffers?". Ek neem waar dat die meeste maatstawwe op die idee gebou is - kom ons kyk wat die deurset sal wees, dit wil sê wat die deurset sal wees. Dit word gewoonlik in TPS of QPS gemeet.
En ons probeer om soveel as moontlik transaksies per sekonde uit die motor te druk met behulp van instelparameters. Hier net 311 per sekonde vir uitsoek.
Maar niemand ry op volle spoed werk toe en terug huis toe in 'n motor nie. Dit is simpel. So is dit met databasisse. Ons moet nie op volle spoed ry nie, en niemand doen dit nie. Niemand leef in produksie nie, wat 100% SVE het. Alhoewel, miskien leef iemand, maar dit is nie goed nie.
Die idee is dat ons gewoonlik teen 20 persent van die moontlikheid ry, verkieslik nie hoër as 50%. En ons probeer eerstens om die reaksietyd vir ons gebruikers te optimaliseer. Dit wil sê, ons moet ons knoppies draai sodat daar 'n minimum latensie teen 20% spoed is, voorwaardelik. Dit is 'n idee wat ons ook in ons eksperimente probeer gebruik.
En aan die einde van die aanbeveling:
- Maak seker dat jy Database Lab maak.
- Indien moontlik, maak dit op aanvraag sodat dit vir 'n rukkie ontvou - hulle het dit gespeel en weggegooi. As jy wolke het, dan spreek dit vanself, maw het baie staan.
- Wees nuuskierig. En as iets verkeerd is, kyk dan met eksperimente hoe dit optree. Nancy kan gebruik word om jouself te leer om te kyk hoe die basis werk.
- En streef na die minimum reaksietyd.
- En moenie bang wees vir Postgres-bronne nie. Wanneer jy met bronne werk, moet jy Engels ken. Daar is baie kommentaar daar, alles word daar verduidelik.
- En kontroleer die gesondheid van die databasis gereeld, ten minste een keer elke drie maande met die hand, of Postgres-checkup.
vrae
Baie dankie! 'n Baie interessante ding.
Twee stukkies.
Ja, twee. Net ek het dit nie heeltemal verstaan nie. Wanneer ons met Nancy werk, kan ons net een parameter of die hele groep aanpas?
Ons het 'n delta config parameter. Jy kan op een slag daar draai soveel as wat jy wil. Maar jy moet verstaan dat wanneer jy baie dinge verander, jy die verkeerde gevolgtrekkings kan maak.
Ja. Hoekom het ek gevra? Omdat dit moeilik is om te eksperimenteer as jy net een parameter het. Jy draai dit, kyk hoe dit werk. Hom ontbloot. Dan begin jy die volgende een.
Jy kan terselfdertyd draai, maar dit hang natuurlik van die situasie af. Maar dit is beter om een idee na te gaan. Ons het gister 'n idee gehad. Ons was in 'n baie nou situasie. Daar was twee konfigurasies. En ons kon nie agterkom hoekom die groot verskil is nie. En die idee het ontstaan dat jy 'n digotomie moet gebruik om konsekwent die verskil te verstaan en te vind. Jy kan dadelik die helfte van die parameters dieselfde maak, dan 'n kwart, ens. Alles is buigsaam.
En daar is nog 'n vraag. Die projek is jonk en ontwikkelend. Die dokumentasie is reeds gereed, is daar 'n gedetailleerde beskrywing?
Ek het 'n spesiale skakel daar gemaak oor die beskrywing van die parameters. Dit is. Maar baie ontbreek nog. Ek is op soek na eendersdenkende mense. En ek vind hulle wanneer ek optree. Dit is baie cool. Iemand werk reeds saam met my, iemand het gehelp en iets daar gedoen. En as jy belangstel in hierdie onderwerp, gee terugvoer - wat ontbreek.
Soos ons 'n laboratorium maak, sal daar dalk terugvoer wees. Kom ons kyk. Dankie!
Hallo! Dankie vir die verslag! Ek het gesien daar is Amazon-ondersteuning. Is GSP-ondersteuning beplan?
Goeie vraag. Ons het begin doen. En tot dusver het hulle gevries, want ons wil spaar. Dit wil sê, daar is ondersteuning met gebruik van run op localhost. Jy kan self 'n instansie skep en plaaslik werk. Terloops, dit is hoe ons dit doen. Ek doen dit in Getlab, daar op GSP. Maar ons sien steeds nie die sin daarin om net so 'n orkestrasie te doen nie, want Google het nie goedkoop plekke nie. Daar is ??? gevalle, maar hulle het beperkings. Eerstens het hulle altyd net 70% afslag en jy kan nie met die prys daar speel nie. Spots, ons verhoog die prys met 5-10% om die waarskynlikheid dat jy doodgemaak sal word, te verminder. Dit wil sê, jy spaar plekke, maar jy kan enige tyd weggeneem word. As jy 'n bietjie hoër bied as ander, sal jy later doodgemaak word. Google is heeltemal anders. En daar is nog 'n baie slegte beperking - hulle leef net 24 uur. En soms wil ons 'n eksperiment vir 5 dae uitvoer. Maar jy kan dit op kolle doen, kolle leef soms maande lank.
Hallo! Dankie vir die verslag! Jy het melding gemaak van ondersoek. Hoe bereken jy stat_statements foute?
'n Baie goeie vraag. Ek kan in groot detail wys en vertel. Kortom, ons kyk na hoe die stel versoekgroepe gedryf het: hoeveel het afgeval en hoeveel nuwes het verskyn. En dan kyk ons na twee maatstawwe: totaal_tyd en oproepe, so daar is twee foute. En ons kyk na die bydrae van die drywende groepe. Daar is twee subgroepe: diegene wat vertrek het en diegene wat aangekom het. Kom ons kyk hoe hulle bydra tot die groot prentjie.
Is jy nie bang dat dit twee of drie keer daar sal draai in die tyd tussen kiekies nie?
Ek bedoel, het hulle herregistreer of wat?
Hierdie versoek is byvoorbeeld reeds een keer uitgestoot, toe het dit gekom en weer uitgedruk, toe het dit weer gekom en is weer uitgestoot. En jy het iets hier bereken, en waar is dit alles?
Goeie vraag om na te kyk.
Ek het 'n soortgelyke ding gedoen. Makliker, natuurlik, ek het dit alleen gedoen. Maar ek moes reset, reset stat_statements en ten tyde van die momentopname bewus wees dat daar minder as 'n sekere persentasie is, wat steeds nie die plafon bereik het nie, hoeveel stat_statements daar kan ophoop. En ek word gelei dat, heel waarskynlik, niks uitgedwing is nie.
Ja ja.
Maar ek verstaan nie hoe om dit anders te doen nie.
Ongelukkig onthou ek nie presies of ons die navraagteks of queryid met pg_stat_statements daar gebruik en daarop fokus nie. As ons deur die queryid gelei word, vergelyk ons in teorie vergelykbare dinge.
Nee, hy kan verskeie kere tussen kiekies uit gedwing word en weer kom.
Met dieselfde id?
Ja.
Ons sal dit bestudeer. Goeie vraag. Moet studeer. Maar vir nou, wat ons sien, skryf ons óf 0 ...
Dit is natuurlik 'n seldsame geval, maar ek was geskok toe ek uitvind dat stat_statemetns daar kan vooruitloop.
Daar kan baie dinge in Pg_stat_statements wees. Ons het die feit teëgekom dat as jy track_utility = aan het, dan word jou stelle ook nagespoor.
Ja natuurlik.
En as jy java hiberneer het, wat ewekansig is, dan begin die hash-tabel daar sluit. En sodra jy 'n baie besige toepassing afskakel, het jy 50-100 groepe. En alles is min of meer stabiel daar. Een manier om dit te bekamp, is om pg_stat_statements.max te verhoog.
Ja, maar jy moet weet hoeveel. En op een of ander manier moet jy dit volg. Ek doen. d.w.s. ek het pg_stat_statements.max. En ek sien dat ek ten tyde van die momentopname nie 70% persent bereik het nie. Goed, so ons het niks verloor nie. Ons doen 'n reset. En ons kopieer weer. As die volgende foto minder as 70 het, is daar heel waarskynlik niks weer verlore nie.
Ja. Die verstek is nou 5 000. En vir baie is dit genoeg.
Gewoonlik ja.
Video:
NS Ek sal op my eie byvoeg dat as Postgres vertroulike data bevat en dit nie in die toetsomgewing kan inkom nie, dan kan jy gebruik . Die skema is min of meer soos volg:
Bron: will.com