Ju lutem, njihni me përshkrimin e raportit të Nikolay Samokhvalov "Qasje industriale në tunimin e PostgreSQL: eksperimentet mbi bazat e të dhënave"
Shared_buffers = 25% â Ă«shtĂ« shumĂ« apo pak? A Ă«shtĂ« saktĂ«sisht ashtu? Si tĂ« kuptoni nĂ«se ky rekomandim â mjaft i vjetĂ«ruar â Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r rastin tuaj tĂ« veçantĂ«?
Ka ardhur koha për të trajtuar çështjen e përcaktimit të parametrave postgresql.conf "në një mënyrë më të qartë". Jo përmes "autotunerëve" të verbër ose këshillave të vjetruara nga artikuj dhe blogje, por në bazë të:
- eksperimentëve rigorozë në BD, të kryera automatizueshëm, në sasi të mëdha dhe në kushte sa më të afërta me "luftën".
- kuptimit të thellë të veçorive të funksionimit të DBMS dhe OS.
Duke pĂ«rdorur Nancy CLI (), ne do tĂ« shqyrtojmĂ« njĂ« shembull konkret â tĂ« njohurit shared_buffers â nĂ« situata tĂ« ndryshme, nĂ« projekte tĂ« ndryshme dhe do tĂ« pĂ«rpiqemi tĂ« kuptojmĂ« se si tĂ« pĂ«rcaktojmĂ« parametrin optimal pĂ«r infrastrukturĂ«n tonĂ«, BD dhe ngarkesĂ«n.
Bëhet fjalë për eksperimentet mbi bazat e të dhënave. Kjo është një histori që vazhdon pak më shumë se gjashtë muaj.
Pak për mua. Kam më shumë se 14 vjet përvojë me Postgres. Kam themeluar disa kompani në rrjete sociale. Kudo është përdorur dhe përdoret Postgres.
Po ashtu, grupi RuPostgres në Meetup, vendi i dytë në botë. Po afrohemi ngadalë drejt 2,000 anëtarëve. RuPostgres.org.
Dhe në konferenca të ndryshme, duke përfshirë Highload, unë jam përgjegjës për bazat e të dhënave, veçanërisht për Postgres që nga fillimi.
Dhe në vitet e fundit kam rinisur praktikën time të konsulencës për Postgres në 11 zona të kohës nga këtu.
Dhe kur e bëra këtë disa vjet më parë, pata një pushim në punën aktive manuale me Postgres, ndoshta që nga viti 2010. U habitëm sa pak kanë ndryshuar ditët e punës së DBA, sa shumë punë manuale duhet akoma të përdoret. Dhe menjëherë m'u duk se kishte diçka të gabuar, duhej të automatizoja më shumë gjëra.
Dhe pasi që gjithçka ndodhte në distancë, shumica e klientëve ishte në cloud. Dhe shumë është automatizuar tashmë. Për këtë do flasim më vonë. Kështu që kjo kaloi në ide, se duhet të ketë disa mjete, pra një platformë që do të automatizonte praktisht të gjitha veprimet e DBA, në mënyrë që të mund të menaxhonte numra të mëdha të bazave.
Në këtë raport nuk do të ketë:
- «Plumba tĂ« argjendtë» dhe deklarata si â vendosni 8 GB ose 25 % shared_buffers dhe do tĂ« jeni mirĂ«. PĂ«r shared_buffers nuk do tĂ« flasim shumĂ«.
- Hardcore "interiors".
And what will happen?
- There will be optimization principles that we apply and develop. There will be various ideas that come up along the way and different tools we mostly create in Open Source, meaning we build the foundation in Open Source. Moreover, we have tickets, and almost all communication happens in Open Source. You can see what we are currently doing, what will be in the next release, and so on.
- There will also be some experience using these principles and tools in a number of companies: from small startups to large corporations.
How is all this developing?
First of all, the main task of a DBA, besides ensuring the creation of instances, deploying backups, etc., is identifying bottlenecks and optimizing performance.
Currently, it's organized this way. We look at monitoring, we see something, but we lack some details. We start digging a little deeper, usually by hand, and understand what to do with it one way or another.
And there are two approaches. Pg_stat_statements is the standard default solution for identifying slow queries. And analyzing Postgres logs with pgBadger.
Each approach has serious drawbacks. The first approach discards all parameters. If we see groups like SELECT * FROM table where column equals sign "?" or "$" starting with Postgres version 10. We don't know if it's an index scan or a sequential scan. It heavily depends on the parameter. If you insert a rarely occurring value, there will be an index scan. If you insert a value that represents 90% of the table, it will obviously be a sequential scan, because Postgres knows the statistics. And that's a significant drawback of pg_stat_statements, although some work is being done on it.
The main drawback of log analysis is that you can't usually afford "log_min_duration_statement = 0". We'll also talk about this. Accordingly, you don't see the full picture. A very fast query could consume a huge amount of resources, but you wonât notice it because itâs below your threshold.
How do DBAs solve identified problems?
PĂ«r shembull, ne gjetĂ«m ndonjĂ« problem. ĂfarĂ« bĂ«het zakonisht? NĂ«se jeni zhvillues, do tĂ« bĂ«ni diçka nĂ« ndonjĂ« instance, qĂ« nuk Ă«shtĂ« aq shumĂ« e madhe. NĂ«se jeni DBA, atĂ«herĂ« keni staging. Dhe mund tĂ« ketĂ« vetĂ«m njĂ«. Dhe ai ka mbetur pas gjysmĂ« viti. Dhe mendoni se do tĂ« shkoni nĂ« production. Madhenj DBA tĂ« eksperiencĂ«s kontrollojnĂ« mĂ« vonĂ« nĂ« production, nĂ« replikĂ«. Disa herĂ« krijojnĂ« njĂ« indeks temporar, sigurohen qĂ« ai ndihmon, e heqin dhe ia kthejnĂ« zhvilluesve, qĂ« tĂ« fusin atĂ« nĂ« skedarĂ«t e migrimit. Kjo Ă«shtĂ« çfarĂ« po ndodh tani. Dhe kjo Ă«shtĂ« njĂ« e keqe.
- TĂ« tunim konfigurimet.
- Të optimizojmë grupin e indekseve.
- Të ndryshojmë vetë SQL-query (kjo është mënyra më e komplikuar).
- Të shtojmë kapacitete (mënyra më e thjeshtë në shumicën e rasteve).
Me kĂ«to gjĂ«ra ka shumĂ« pĂ«r tĂ« thĂ«nĂ«. Ka shumĂ« kontrolla nĂ« Postgres. Duhet tĂ« dish shumĂ«. Ka shumĂ« indekse nĂ« Postgres, falĂ« gjithashtu organizatorĂ«ve tĂ« kĂ«tij konferencĂ«. Dhe tĂ« gjitha kĂ«to duhet tâi dish, dhe pikĂ«risht kjo i jep ndjesinĂ« qĂ« DBA po merret me magji tĂ« zezĂ«. DomethĂ«nĂ«, duhet tĂ« kalosh 10 vjet qĂ« tĂ« fillosh ta kuptosh dhe kjo saktĂ«.
Dhe unë jam luftëtar kundër kësaj magjie të zezë. Dua të bëj gjithçka në një mënyrë që të ketë teknologji, e jo intuita në të gjitha këto.
Shembuj nga jeta
KĂ«tĂ« e kam vĂ«rejtur tĂ« paktĂ«n nĂ« dy projekte, duke pĂ«rfshirĂ« timin. NjĂ« postim tjetĂ«r nĂ« blog na informon se vlera 1,000 pĂ«r default_statistic_target â Ă«shtĂ« e mirĂ«. E mirĂ«, le tĂ« provojmĂ« nĂ« production.
Dhe këtu ne, duke përdorur mjetin tonë dy vjet më vonë nëpërmjet eksperimenteve mbi bazat e të dhënave për të cilat flasim sot, mund të krahasojmë çfarë ishte dhe çfarë është tani.
Dhe për këtë na nevojitet të krijojmë një eksperiment. Ai përbëhet nga katër pjesë.
- E para â Ă«shtĂ« ambienti. Na duhen pajisjet. Dhe kur shkoj nĂ« ndonjĂ« kompani dhe lidh njĂ« kontratĂ«, atĂ«herĂ« i them tĂ« mĂ« japin pajisje tĂ« njĂ«jta si nĂ« production. PĂ«r secilin nga mjeshtrat tuaj, kam nevojĂ« pĂ«r tĂ« paktĂ«n njĂ« pajisje tĂ« tillĂ«. Ose Ă«shtĂ« njĂ« makinĂ« virtuale instance nĂ« Amazon ose nĂ« Google, ose mĂ« duhet saktĂ«sisht e njĂ«jta pajisje. DomethĂ«nĂ«, dua tĂ« riprodhoj ambientin. Dhe nĂ« konceptin e ambientit ne pĂ«rfshijmĂ« versionin kryesor tĂ« Postgres.
- Pjesa e dytĂ« â Ă«shtĂ« objekti i hulumtimeve tona. Kjo Ă«shtĂ« baza e tĂ« dhĂ«nave. Ajo mund tĂ« krijohet nĂ« disa mĂ«nyra. UnĂ« do tĂ« tregoj si.
- Pjesa e tretĂ« â Ă«shtĂ« ngarkesa. Ky Ă«shtĂ« momenti mĂ« i komplikuar.
- Dhe pjesa e katërt është ajo që ne kontrollojmë, dmth me çfarë do ta krahasojmë. Supozojmë se mund të ndryshojmë një ose disa parametra në konfigurim, ose mund të krijojmë një indeks, etj.
Ne po fillojmĂ« njĂ« eksperiment. Ja pg_stat_statements. NĂ« tĂ« majtĂ« â si ishte. NĂ« tĂ« djathtĂ« â si Ă«shtĂ« bĂ«rĂ«.
Në të majtë default_statistics_target = 100, në të djathtë = 1,000. Ne shohim se kjo na ndihmoi. Nga 8% gjithçka është përmirësuar në tërësi.
Por nëse e rrokullisim poshtë, do të ketë grupe kërkesash nga pgBadger ose nga pg_stat_statements. Këtu ka dy mundësi. Ne do të shohim se ndonjë kërkesë ka rënë me 88%. Dhe këtu fillon qasja inxhinierike. Ne mund të thellohemi më tej, sepse është interesante se pse ajo ka rënë. Duhet të kuptojmë çfarë ndodhi me statistikat. Pse më shumë kube në statistikë çojnë në një rezultat më të dobët.
Ose mund të mos thellohemi, por të bëjmë 'ALTER TABLE ⊠ALTER COLUMN' dhe t'i kthejmë 100 kube në statistikë kësaj kolone. Dhe pastaj, përmes një eksperimentit, ne mund të sigurohemi se kjo zgjidhje ndihmoi. Kaq. Kjo është qasja inxhinierike që na ndihmon të shohim situatën dhe të marrim vendime mbi baza të të dhënave, e jo mbi intuitë.
Disa shembuj nga fusha të tjera. Në testime, ka CI testime që ekzistojnë prej shumë vitesh. Dhe asnjë projekt i shëndoshë në mendje nuk do të ekzistojë pa teste automatike.
Në industri të tjera: në aviacion, në prodhimin e automjeteve, kur testojmë aerodinamikën, gjithashtu kemi mundësinë të kryejmë eksperimente. Ne nuk do të lëshojmë diçka nga skicimi menjëherë në hapësirë apo nuk do të nxjerrim ndonjë makinë menjëherë në autostradë. Për shembull, ka një tunel aerodinamik.
Nga vObservimet në industri të tjera, ne mund të nxjerrim përfundime.
Së pari, ne kemi një mjedis të veçantë. Ai është afër prodhimit, por jo tërësisht i njëjtë. Karakteristika kryesore e tij është se duhet të jetë i lirë, i përsëritshëm dhe maksimalisht i automatizuar. Dhe gjithashtu duhet të ketë mjete speciale për të kryer një analizë të detajuar.
Mundësisht, kur fluturojmë me avionin, kemi më pak mundësi të studiojmë çdo militër të sipërfaqes së krahut, se sa kemi në tunelin aerodinamik. Ne kemi më shumë mjete për diagnostikim. Mund të lejojmë të vendosim më shumë gjëra të rënda, të cilat nuk mund t'i vendosim në avionin në ajër. Po ashtu edhe me Postgres. Në disa raste, mund të aktivizojmë logimin e plotë të kërkesave gjatë eksperimenteve. Dhe nuk duam ta bëjmë këtë në ambientin e prodhimit. Ndoshta madje do ta aktivizojmë këtë me planet përmes auto_explain.
Dhe siç thashë, një nivel i lartë automatizimi do të thotë që kemi shtypur butonin dhe kemi përsëritur. Kështu duhet të jetë, për të pasur shumë eksperimente, që të jetë në rrjedhë.
Nancy CLI â themeli i "laboratorit tĂ« DB"
Dhe ja, ne kemi bërë një gjë të tillë. Do të thotë, kam folur për këto ide në qershor, pothuajse një vit më parë. Dhe tani kemi në Open Source një Nancy CLI të quajtur kështu. Ky është themeli për të ndërtuar një laborator të bazës së të dhënave.
â Ky Ă«shtĂ« nĂ« Open Source, nĂ« Gitlab. Mund ta thoni, mund ta provoni. Kam dhĂ«nĂ« njĂ« lidhje nĂ« slidet. Mund tĂ« klikoni dhe do tĂ« ketĂ« pĂ«r tĂ« gjitha parametrat.
Sigurisht, ka ende shumë për të zhvilluar. Ka shumë ide. Por kjo është ajo që ne e zbatojmë pothuajse çdo ditë. Dhe kur na vjen një ide - a çfarë ndodh kur fshini 40,000,000 rreshta dhe gjithçka është bllokuar në IO, atëherë mund të bëjmë një eksperiment dhe të shohim më në detaje, për të kuptuar se çfarë po ndodh dhe më pas të përpiqemi ta zgjidhim atë në mënyrë që të mund të vazhdojmë. Do të thotë, bëjmë një eksperiment. Për shembull, ndonjë gjë e rregullojmë dhe shohim se çfarë rezultati marrim. Dhe ne nuk e bëjmë këtë në prodhim. Ky është thelbi i idesë.
Ku mund të funksionojë kjo? Mund të funksionojë lokal, do të thotë, mund ta bëni kudo, madje mund ta nisni në MacBook. Keni nevojë për docker, fillojmë. Dhe kaq. Mund të ndizni në ndonjë instancë në hardware, ose në një virtual, kudo.
Dhe ka edhe mundĂ«sinĂ« e hapjes sĂ« largĂ«t nĂ« Amazon nĂ« EC2 Instance, nĂ« spots. Dhe kjo Ă«shtĂ« njĂ« mundĂ«si shumĂ« e shkĂ«lqyer. PĂ«r shembull, dje kemi realizuar mĂ« shumĂ« se 500 eksperimente nĂ« instancĂ«n i3, duke filluar nga ajo mĂ« e vogĂ«l dhe duke pĂ«rfunduar nĂ« i3-16-xlarge. Dhe na kushtoi 500 eksperimente 64 dollarĂ«. Ădo njĂ«ri zgjati 15 minuta. DomethĂ«nĂ«, falĂ« pĂ«rdorimit tĂ« spoteve, kjo Ă«shtĂ« shumĂ« e lirĂ« â zbritje 70%, tarifimi sipas sekondĂ«s nga Amazon. Mund tĂ« bĂ«ni shumĂ« gjĂ«ra. Mund tĂ« realizoni njĂ« hetim tĂ« vĂ«rtetĂ«.
Dhe tri versione kryesore të Postgres mbështeten. Nuk është kaq e vështirë të përmirësosh disa versione të vjetra dhe versionin e ri 12 gjithashtu.
Objektin mund ta përcaktojmë në tri mënyra. Ato janë:
- Dump/sq-fail.
- MĂ«nyra kryesore â Ă«shtĂ« kloni i direktorisĂ« PGDATA. Zakonisht marrĂ« nga serveri i backup-it. NĂ«se keni backup-e binaresh tĂ« mira, mund tĂ« bĂ«ni klone prej andej. NĂ«se keni cloud, atĂ«herĂ« kjo do tĂ« bĂ«het automatikisht nga kompania cloud si Amazon dhe Google. Kjo Ă«shtĂ« mĂ«nyra kryesore pĂ«r klonĂ«t nĂ« prodhim tĂ« vĂ«rtetĂ«. KĂ«shtu zhvillojmĂ« ne.
- Dhe mënyra e fundit është e përshtatshme për hulumtimet, kur ka dëshirë të kuptohet se si funksionon diçka në Postgres. Kjo është pgbench. Mund të gjeneroni me ndihmën e pgbench. Kjo është thjesht një opsion "db-pgbench". I thua atij, çfarë scale. Dhe gjithçka do të gjenerohet në cloud, siç është thënë.
Dhe ngarkesa:
- Ngarkesën mund ta ekzekutojmë në një rrjedhë SQL. Kjo është mënyra më primitive.
- Ose mund të emulojmë ngarkesën. Dhe mund ta emulojmë atë para së gjithash në këtë mënyrë. Na nevojitet të mbledhim të gjitha logjet. Dhe kjo është e dhimbshme. Do t'ju tregoj pse. Dhe me ndihmën e pgreplay luajmë, që është i integruar në Nancy.
- Ose një opsion tjetër. Një ngarkesë e quajtur artizanal, që ne e bëjmë me një sasi të caktuar përpjekjeje. Duke analizuar ngarkesën tonë aktuale në sistemin e prodhimit, ne nxjerrim grupet më të mira të kërkesave. Dhe me ndihmën e pgbench mund ta emulojmë këtë ngarkesë në laborator.
- Ose duhet të ekzekutojmë ndonjë SQL, domethënë kontrollojmë një migrim, krijojmë një indeks atje, realizojmë ANALAZE. Dhe shohim se çfarë ndodhi para vakuumit dhe pas vakuumit. Në përgjithësi, çdo SQL.
- Ose ne e nevojë që të ndryshojmë një ose disa parametra në konfigurim. Mund të kërkojmë që të verifikohen, për shembull, 100 vlera në Amazon për bazën tonë me terabajt. Dhe pas disa orësh, do të keni rezultatin. Si rregull, baza me terabajt do të zgjatet disa orë. Por në zhvillim kemi një patch, ku kemi mundësinë për të bërë një seri, domethënë, mund të përdorni të njëjtin pgdata në të njëjtin server dhe të verifikoni. Postgres do të rindezë, cache-t do të zbrazin. Dhe mund të stërvitni ngarkesën.
- Vjen njĂ« direktori, ku ka shumĂ« skedarĂ«, duke filluar nga snapshots pg.stat***. Dhe aty janĂ« gjĂ«rat mĂ« interesante â pg_stat_statements, pg_stat_kcacke. KĂ«to janĂ« dy zgjerime qĂ« analizojnĂ« kĂ«rkesat. Dhe pg_stat_bgwriter pĂ«rmban jo vetĂ«m statistikĂ«n e pgwriter, por gjithashtu pĂ«r checkpoint dhe se si vetĂ« backendet shkarkojnĂ« bufferat e papastĂ«r. Dhe kjo Ă«shtĂ« e interesante tĂ« shikohet. PĂ«r shembull, kur konfiguroni shared_buffers, Ă«shtĂ« shumĂ« interesante tĂ« shikoni sa ka shkarkuar kush.
- Po ashtu, arrijnĂ« log-Ă«t e Postgres. Dy log-e â log i pĂ«rgatitjes dhe log i luajtjes sĂ« ngarkesĂ«s.
- NjĂ« tipar relativisht i ri â janĂ« FlameGraphs.
- Po ashtu, nëse keni përdorur pgreplay ose pgbench varianta e luajtjes së ngarkesës, do të keni nativen e tyre në daljen e tyre. Dhe do të shihni latency dhe TPS. Mund të kuptoni se si e kanë parë ata.
- Informacion rreth sistemit.
- Kontrollet bazike CPU dhe IO. Kjo është më shumë për instancat EC2 në Amazon, kur dëshironi të nisni në rrjedhë 100 instanca identike dhe t'i testoni ato me 100 prova të ndryshme, do të keni 10,000 eksperimente. Dhe duhet të siguroheni që nuk keni një instancë problematike, të cilën dikush e ka pakësuar. Në këtë hardware, të tjerët aktivizohen dhe ju mbetet pak burim. Të tilla rezultate është më mirë t'i eliminoni. Dhe pikërisht me ndihmën e sysbench nga Aleksei Kopytov ne bëjmë disa kontrolle të shkurtra, që do të vijë dhe mund të krahasohet me të tjerat, domethënë, do të kuptoni si e menaxhon CPU-ja dhe si e menaxhon IO-ja.
Cilat janë komplikimet teknike në shembuj të kompanive të ndryshme?
Supozoni se duam të përsëritim një ngarkesë të vërtetë me anë të log-ëve. Ide e shkëlqyer, nëse është shkruar në Open Source pgreplay. Ne e përdorim. Por, që të punojë mirë, duhet të aktivizoni logimin e plotë të kërkesave me parametra dhe kohëmatjen.
Ka there disa vĂ«shtirĂ«si rreth duration dhe timestamp. Ne do ta anashkalojmĂ« kĂ«tĂ« pjesĂ«. Pyetja kryesore Ă«shtĂ« â a mund ta lejoni veten njĂ« gjĂ« tĂ« tillĂ« apo jo?
Problemi është se kjo mund të mos jetë e aksesueshme. Ju duhet së pari të kuptoni se çfarë fluksi do të shkruhet në log. Nëse keni pg_stat_statements, mund të kuptoni, me këtë kërkesë (linku do të jetë i disponueshëm në slajde), sa përafërsisht byte do të shkruhet në sekondë.
Ne e shikojmë gjatësi e kërkesës. Ne injorojmë faktin se nuk ka parametra, por e dimë gjatësi e kërkesës dhe dimë sa herë në sekondë është ekzekutuar. Kështu mund të përllogarisim sa përafërsisht byte në sekondë. Mund të gabojmë dy herë, por rendi do ta kuptojmë me siguri kështu.
Mund tĂ« shohim se kjo kĂ«rkesĂ« ekzekutohet 802 herĂ« nĂ« sekondĂ«. Dhe ne shohim se bytes_per sec â 300 kB/s do tĂ« shkruhen plus minus. Dhe, zakonisht, mund tĂ« lejojmĂ« njĂ« fluks tĂ« tillĂ«.
Por! ĂĂ«shtja Ă«shtĂ« se ka sisteme tĂ« ndryshme logimi. Dhe zakonisht, njerĂ«zit kanĂ« âsyslogâ si parazgjedhje.
Dhe nëse keni syslog, atëherë mund të keni një pamje të tillë. Ne do të marrim pgbench, do të aktivizojmë logimin e kërkesave dhe do të shohim çfarë ndodh.
Pa logim â kjo Ă«shtĂ« kolona nĂ« tĂ« majtĂ«. AtĂ«herĂ« kishim 161,000 TPS. Me syslog â nĂ« Ubuntu 16.04 nĂ« Amazon, kemi 37,000 TPS. NdĂ«rsa nĂ«se ndĂ«rojmĂ« dy metoda tĂ« tjera tĂ« logimit, situata Ă«shtĂ« shumĂ« mĂ« e mirĂ«. Kjo Ă«shtĂ«, prisnim qĂ« tĂ« shĂ«nuarit tĂ« bjerĂ«, por jo kaq shumĂ«.
Dhe në CentOS 7, ku merr pjesë journald, duke e kthyer logun në format binary për kërkimin e lehtë, atëherë ndodhemi në një situatë të tmerrshme, 44 herë ulje në TPS.
Dhe kjo është ajo me të cilën jetojnë njerëzit. Dhe shpesh në kompani, veçanërisht në të mëdha, është shumë e vështirë për t'u ndryshuar. Nëse mund të largoheni nga syslog, atëherë ju lutemi largohuni.
- Vlerësoni IOPS dhe fluksin e shkruar.
- Kontrolloni sistemin tuaj të logimit.
- Nëse ngarkesa e parashikuar është tepër e madhe, shqyrtoni mundësinë e sampling.
Kemi pg_stat_statements. Siç e thashĂ«, ai duhet patjetĂ«r tĂ« jetĂ«. Dhe mund tĂ« marim dhe çdo grup kĂ«rkesash ta pĂ«rshkruajmĂ« nĂ« njĂ« skedar special. Pastaj mund tĂ« pĂ«rdorim njĂ« funksion shumĂ« tĂ« dobishĂ«m nĂ« pgbench â mundĂ«sinĂ« pĂ«r tĂ« pĂ«rfshirĂ« disa skedare me opsionin â-fâ.
Ai kupton shumĂ« â-fâ. Dhe mund tĂ« thuash me â@â nĂ« fund, cila pĂ«rqindje i takon secilit skedar. Pra, mund tĂ« themi se ky duhet tĂ« ekzekutohet nĂ« 10% tĂ« rasteve, dhe ky nĂ« 20%. Dhe kjo do tĂ« na afrojĂ« me atĂ« qĂ« shohim nĂ« prodhim.
Si do ta kuptojmë se çfarë kemi në prodhim? Cila përqindje dhe çfarë si? Këtu kemi një devijim paksi. Kemi një produkt tjetër. . Gjithashtu baza është në Open Source. Dhe ne tani po e zhvillojmë aktivisht atë.
Ai lindi pĂ«r arsye pak tĂ« ndryshme. PĂ«r arsye se monitorimi nuk Ă«shtĂ« i mjaftueshĂ«m. Pra, ju vini, shikoni nĂ« bazĂ«, shikoni problemet qĂ« ekzistojnĂ«. Dhe, zakonisht, ju bĂ«ni kontrollin e shĂ«ndetit. NĂ«se jeni njĂ« DBA me pĂ«rvojĂ«, atĂ«herĂ« e bĂ«ni kontrollin e shĂ«ndetit. Shikoni pĂ«rdorimin e indekseve etj. NĂ«se keni OKmeter, atĂ«herĂ« shkĂ«lqyeshĂ«m. Ky Ă«shtĂ« njĂ« monitorim i klasit pĂ«r Postgres. OKmeter.io â ju lutem, instalojeni, gjithçka Ă«shtĂ« bĂ«rĂ« shumĂ« mirĂ« atje. Ai Ă«shtĂ« me pagesĂ«.
Nëse nuk e keni atë, atëherë, zakonisht, nuk keni shumë për të parë. Në monitorim zakonisht ka CPU, IO dhe madje me rezervime, dhe gjithë kjo. Por ne kemi nevojë për më shumë. Duhet të shohim si funksionon autovakuumi, si funksionon checkpoint, në IO duhet të ndash checkpoint nga bgwriter dhe nga backend-et etj.
Problemi është kur ndihmon një kompani të madhe, ato nuk mund të zbatojnë shpejt diçka. Nuk mund të blejnë shpejt OKmeter. Mund të kenë mundësi ta blejnë pas gjashtë muajsh. Nuk mund të instalojnë shpejt disa paketa.
Dhe na lindi ideja se na nevojitet një vegël e tillë, e cila nuk kërkon asgjë për instalim, pra ju nuk duhet të instaloni asgjë në prodhim. E instaloni në laptopin tuaj, ose në serverin e vëzhgimit, nga ku do të nisni. Dhe ai do të analizojë shumë gjëra: edhe sistemin operativ, edhe sistemin e skedarëve, edhe vetë Postgres-in, duke bërë disa kërkesa të lehta që mund t'i drejtoni drejtpërdrejt në prodhim dhe asgjë nuk do të bjerë.
Ne e quajmë atë Postgres-checkup. Nëse flasim mjekësisht, kjo është një kontroll i rregullt i shëndetit. Nëse e lidhim me temën automobilistike, është si një kontroll teknik. Ju bëni kontroll teknik për makinën çdo gjashtë muaj ose një vit, në varësi të markës. A bëni kontroll teknik për bazën tuaj? Pra, a bëni një kërkim të thellë rregullisht? Kjo duhet bërë. Nëse bëni kopje rezervë, atëherë bëni edhe kontrollin, kjo është po aq e rëndësishme.
Dhe ne kemi njĂ« vegĂ«l tĂ« tillĂ«. Ai filloi tĂ« zhvillohet aktivisht vetĂ«m tri muaj mĂ« parĂ«. ĂshtĂ« ende i ri, por aty ka shumĂ« gjĂ«ra.
Ne pofigurojmĂ« grupet mĂ« "tĂ« ndikueshme" tĂ« kĂ«rkesave â raporti K003 nĂ« Postgres-checkup
Dhe ka një grup raportesh K. Momentalisht ka tre raporte. Dhe ka një raport të tillë K003. Aty është maje e pg_stat_statements, e renditur sipas total_time.
Kur rendisim grupet e kërkesave sipas total_time, në krye shohim një grup që ngarkon sistemin tonë më shumë, dmth konsumon më shumë burime. Pse e quaj grupet e kërkesave? Sepse ne heqim parametrat. Kjo nuk janë më kërkesa, por grupe kërkesash, dmth ato janë të abstrahuara.
Dhe nëse do të optimizojmë nga lartë poshtë, do të lehtësojmë burimet tona dhe do të shtyjmë momentin kur do të duhet të bëjmë një përmirësim. Ky është një mënyrë shumë e mirë për të kursyer para.
Mund të mos jetë ndoshta mënyra më e mirë për të kujdesur për përdoruesit, sepse ndoshta nuk shohim raste të rralla, por shumë të bezdisshme, kur dikush pret 15 sekonda. Në total, ato janë aq të rralla sa që nuk i shohim, por përndryshe merremi me burimet.
ĂfarĂ« ndodhi nĂ« kĂ«tĂ« tabelĂ«? Ne bĂ«mĂ« dy snapshot-e. Postgres_checkup do t'ju bĂ«jĂ« njĂ« delta pĂ«r çdo metrikĂ«: pĂ«r total-time, calls, rows, shared_blks_read etj. E gjithĂ«, delta Ă«shtĂ« llogaritur. Problemi i madh me pg_stat_statements Ă«shtĂ« se ai nuk e mban mend kur ka qenĂ« reset. NdĂ«rsa pg_stat_database e mban mend, pg_stat_statements nuk e mban. Shihni, ka 1 000 000 numĂ«r, por nga e kemi llogaritur, nuk e dimĂ«.
Dhe këtu e dimë, këtu kemi dy snapshot-e. E dimë se delta në këtë rast ishte 56 sekonda. Një periudhë shumë e vogël. E renditëm sipas total_time. Më pas mund të diferencojmë, domethënë, të gjithë metrikat i ndajmë me duration. Nëse i ndajmë çdo metrikë me duration, do të kemi numrin e thirrjeve për sekondë.
MĂ« pas total_time pĂ«r sekondĂ« â kjo Ă«shtĂ« metrika ime e preferuar. Ajo matet nĂ« sekonda, nĂ« sekondĂ«, dmth sa sekonda i nevojiteshin sistemit tonĂ« pĂ«r tĂ« pĂ«rfunduar kĂ«tĂ« grup kĂ«rkesash pĂ«r sekondĂ«. NĂ«se shihni aty mĂ« shumĂ« se njĂ« sekondĂ« pĂ«r sekondĂ«, do tĂ« thotĂ« se ju nevojiteshin mĂ« shumĂ« se njĂ« bĂ«rthamĂ«. Kjo Ă«shtĂ« njĂ« metrikĂ« shumĂ« e mirĂ«. Mund tĂ« kuptoni se ky person, pĂ«r shembull, ka nevojĂ« pĂ«r tĂ« paktĂ«n tri bĂ«rthama.
Kjo Ă«shtĂ« novatori ynĂ«, nuk kam parĂ« asgjĂ« tĂ« tillĂ«. Vini re â kjo Ă«shtĂ« njĂ« gjĂ« shumĂ« e thjeshtĂ« â sekonda pĂ«r sekondĂ«. N sometimes, kur keni CPU 100 %, atĂ«herĂ« gjysmĂ« ore pĂ«r sekondĂ«, dmth ju keni kaluar gjysmĂ« ore vetĂ«m me kĂ«to kĂ«rkesa.
Më pas, ne shohim rreshta në sekondë. Ne e dimë sa rreshta u kthyen në sekondë.
Dhe gjithashtu ka një gjë interesante. Sa shared_buffers kemi lexuar në sekondë nga vetë shared_buffers. Hit-et kishin qenë atje, ndërsa rreshtat i morëm nga cache i sistemit operativ, ose nga disku. Varianti i parë është i shpejtë, ndërsa i dyti, ndoshta është i shpejtë, ndoshta edhe jo, varet nga situata.
Dhe mĂ«nyra e dytĂ« pĂ«r diferencim â ne ndajmĂ« numrin e kĂ«rkesave nĂ« kĂ«tĂ« grup. NĂ« kolonĂ«n e dytĂ« do tĂ« keni gjithmonĂ« njĂ« kĂ«rkesĂ« tĂ« ndarĂ« nga kĂ«rkesa. MĂ« pas Ă«shtĂ« interesante â sa milisekonda ishin nĂ« kĂ«tĂ« kĂ«rkesĂ«. Ne e dimĂ« si sillet nĂ« mesatare kjo kĂ«rkesĂ«. 101 milisekonda ishin tĂ« nevojshme pĂ«r çdo kĂ«rkesĂ«. Kjo Ă«shtĂ« njĂ« metrikĂ« tradicionale qĂ« na nevojitet pĂ«r tĂ« kuptuar.
Sa rreshta çdo kërkesë ktheu në mesatare. Ne shohim se grupi kthen 8. Sa në mesatare morëm dhe lexuam nga cache. Ne shohim se gjithçka është e mbajtur shkëlqyeshëm në cache. Të gjitha hit-et për grupin e parë.
Dhe nĂ« rreshtin e katĂ«rt nĂ« çdo rresht â Ă«shtĂ« sa pĂ«rqind nga numri total. Ne kemi calls. Le tĂ« supozojmĂ«, nĂ« 1,000,000. Dhe ne mund tĂ« kuptojmĂ« çfarĂ« kontribuon ky grup. Ne shohim se nĂ« kĂ«tĂ« rast grupi i parĂ« kontribuon mĂ« pak se 0.01 %. Kjo do tĂ« thotĂ« se Ă«shtĂ« kaq e ngadaltĂ« sa nuk e shohim nĂ« pamjen e pĂ«rgjithshme. NdĂ«rsa grupi i dytĂ« â 5 % nga calls. Kjo do tĂ« thotĂ« 5 % nga tĂ« gjitha calls â Ă«shtĂ« grupi i dytĂ«.
Po ashtu, edhe pĂ«r total_time Ă«shtĂ« interesante. Ne shpenzuam 14 % tĂ« gjithĂ« kohĂ«s sĂ« punĂ«s pĂ«r grupin e parĂ« tĂ« kĂ«rkesave. NdĂ«rsa pĂ«r tĂ« dytin â 11 % etj.
Nuk do të thellohem në detaje, por aty ka nuanca. Ne nxjerrim gabimin nga lart, sepse, kur krahasojmë, snapshot-et mund të deformohen, domethënë, disa kërkesa mund të bien dhe në të dytën nuk mund të jenë më, ndërsa disa mund të shfaqen të reja. Dhe ne aty llogarisim gabimin. Nëse shihni 0, atëherë është mirë. Nuk ka gabime. Nëse niveli i gabimit është deri në 20 %, është OK.
Më pas kthehemi në temën tonë. Duhet të krijojmë workload. Ne e marrim nga lartë poshtë, derisa të mbledhim 80 % ose 90 %. Zakonisht janë 10-20 grupe. Dhe krijojmë skedarë për pgbench. Atje përdorim random. Ndonjëherë, fatkeqësisht, kjo nuk funksionon. Dhe në Postgres 12 do të ketë më shumë mundësi për ta përdorur këtë qasje.
Dhe kĂ«shtu ne arrijmĂ« 80-90% nĂ« total_time. ĂfarĂ« duhet tĂ« vendosim pas "@"? ShikojmĂ« thirrjet, shikojmĂ« sa pĂ«rqindje dhe kuptojmĂ« se duhet tĂ« kemi kĂ«tĂ« pĂ«rqindje kĂ«tu. Nga kĂ«to pĂ«rqindje mund tĂ« kuptojmĂ« se si tĂ« balancojmĂ« secilin nga skedarĂ«t. Pas kĂ«saj, pĂ«rdorim pgbench dhe vazhdojmĂ« punĂ«n.
Kemi gjithashtu K001 dhe K002.
K001 â Ă«shtĂ« njĂ« varg i madh me katĂ«r nĂ«nvargje. Kjo Ă«shtĂ« karakteristika e ngarkesĂ«s sonĂ« tĂ« gjithĂ«. Shikoni kolonen e dytĂ« dhe nĂ«nvargun e dytĂ«. ShikojmĂ« se Ă«shtĂ« rreth njĂ« e gjysmĂ« sekondĂ« pĂ«r sekondĂ«, dmth nĂ«se do tĂ« kishte dy bĂ«rthama, do tĂ« ishte mirĂ«. Do tĂ« ishte rreth 75% ngarkesĂ«. Dhe kĂ«shtu do tĂ« punonte. NĂ«se do tĂ« kishim 10 bĂ«rthama, do tĂ« ishim plotĂ«sisht tĂ« qetĂ«. KĂ«shtu mund tĂ« vlerĂ«sojmĂ« burimet.
K002 â kĂ«tu e quaj klasat e kĂ«rkesave, dmth SELECT, INSERT, UPDATE, DELETE. Dhe veçmas SELECT FOR UPDATE, sepse ky bllokon.
Dhe kĂ«tu mund tĂ« arrijmĂ« nĂ« pĂ«rfundimin se SELECT tĂ« zakonshĂ«m lexues â 82% e tĂ« gjithĂ« thirrjeve, por nga ana tjetĂ«r â 74% pĂ«r total_time. DMTH ato thirren shumĂ«, por konsumojnĂ« mĂ« pak burime.
Dhe kthehemi tek pyetja: "Si tĂ« zgjedhim saktĂ« shared_buffers?". VĂ«rej se shumica e bllokimeve ndodhen mbi idenĂ« â le tĂ« shikojmĂ« se çfarĂ« throughput-i do tĂ« ketĂ«, dmth çfarĂ« do tĂ« jetĂ« kapaciteti i kalimit. Kjo matet zakonisht nĂ« TPS ose QPS.
Dhe ne përpiqemi të nxjerrim nga makina sa më shumë transaksione për sekondë përmes parametrave të optimizimit. Këtu është 311 për sekondë për select.
Por askush nuk shkon në punë dhe përsëri në shtëpi me makinë me shpejtësinë maksimale. Kjo është e budallallëk. Po ashtu me databazat. Ne nuk duhet të ecim me shpejtësinë maksimale, askush nuk e bën këtë. Askush nuk jeton në prodhim me 100% CPU. Edhe pse ndoshta dikush jeton, por kjo nuk është mirë.
Ideja është që ne zakonisht shkojmë rreth 20% të mundësive, ndoshta jo më shumë se 50%. Dhe përpiqemi të optimizojmë kohën e përgjigjes për përdoruesit tanë përpara gjithçkaje. DMTH duhet të rrotullojmë duart tona për të pasur latencë minimale në 20% shpejtësie, në mënyrë të thjeshtë. Kjo është një ide që ne gjithashtu përpiqemi ta përdorim në eksperimentet tona.
Dhe në përfundim të rekomandimeve:
- Sigurohuni që të krijoni Database Lab.
- Sa mĂ« shumĂ« qĂ« Ă«shtĂ« e mundur, krijoni nĂ« kĂ«rkesĂ«, qĂ« tĂ« zhvillohet pĂ«r njĂ« kohĂ« tĂ« caktuar â tĂ« luani dhe tĂ« hidhni. NĂ«se keni mbĂ«shtetje pĂ«r cloud, kjo Ă«shtĂ« vetĂ« e natyrshme, dmth, keni shumĂ« qĂ«ndrim.
- Bëni kuriozë. Dhe nëse diçka nuk shkon, kontrolloni me eksperimente se si sillet. Nancy mund të përdoret për të mësuar vetë, për të provuar si funksionon baza.
- Dhe synoni kohën minimale të reagimit.
- Dhe mos u friksoni nga kodet burimore të Postgres. Kur punoni me kodin burimor, duhet të dini anglisht. Ka shumë komente, gjithçka është e shpjeguar.
- Dhe kontrolloni shëndetin e bazës rregullisht, të paktën një herë në tre muaj manualisht ose me Postgres-checkup.
Pyetje
Faleminderit shumë! është një gjë shumë interesante.
Dy gjëra.
Po, dy gjëra. Vetëm se nuk e kuptova plotësisht. Kur punojmë me Nancy, a mund të rregullojmë vetëm një parameter ose një grup të tërë?
Ne kemi parametrin e konfigurimit delta. Mund të rregulloni aq shumë sa të doni njëkohësisht. Por duhet të kuptoni, kur ndryshoni shumë gjëra, mund të bëni konkluzione të gabuara.
Po. Pse e pyes? Sepse është e vështirë të bësh eksperimente kur ke vetëm një parameter. E rregullon, sheh si funksionon. E vendos. Pastaj fillon me parametrin tjetër.
Mund të rregullohen njëkohësisht, por varet nga situata, sigurisht. Por është më mirë të provosh një ide. Dje na erdhi një ide. Kishim një situatë shumë të ngjashme. Kishim dy konfigurime. Dhe nuk mund të kuptonim pse kishte një diferencë të madhe. Na erdhi ideja se duhet të përdorim dykalimin për të kuptuar dhe gjetur ndryshimin. Mund të bëni menjëherë gjysmën e parametrave të njëjtë, pastaj një të katërtën e kështu me radhë. Gjithçka është fleksibël.
Dhe ka një pyetje tjetër. Projekti është i ri, po zhvillohet. A është dokumentacioni tashmë i gatshëm, a ka një përshkrim të detajuar?
Kisha bĂ«rĂ« njĂ« lidhje tĂ« veçantĂ« pĂ«r pĂ«rshkrimin e parametrave. Kjo ekziston. Por ka shumĂ« gjĂ«ra ende qĂ« nuk ekzistojnĂ«. Po kĂ«rkoj bashkĂ«punĂ«torĂ«. Dhe i gjej ata kur flas. ĂshtĂ« shumĂ« bukur. Disa tashmĂ« punojnĂ« me mua, disa ndihmuan dhe bĂ«nĂ« diçka atje. Dhe nĂ«se jeni tĂ« interesuar nĂ« kĂ«tĂ« temĂ«, jepni feedback â çfarĂ« mungon.
Kur të vendosim laboratorin, ndoshta do të ketë feedback. Do ta shikojmë. Faleminderit!
Përshëndetje! Faleminderit për referatin! Shihja se ka mbështetje për Amazon. A është planifikuar mbështetje për GSP?
Pyetja e mirĂ«. Kemi filluar tĂ« punojmĂ«. Dhe pĂ«r momentin e kemi ngrirĂ«, sepse duam tĂ« kursejmĂ«. Do tĂ« thotĂ«, ka mbĂ«shtetje pĂ«rmes run on localhost. Ju mund tĂ« krijoni vetĂ« njĂ« instance dhe tĂ« punoni lokalmente. NĂ« fakt, kĂ«shtu ne punojmĂ«. NĂ« Getlab e bĂ«j kĂ«shtu, aty nĂ« GSP. Por nuk shohim kuptim nĂ« organizimin e tillĂ« pĂ«r momentin, sepse Google nuk ka oferta tĂ« lira. Ka ??? instances atje, por ato kanĂ« kufizime. SĂ« pari, ata gjithmonĂ« kanĂ« njĂ« zbritje prej 70 % dhe nuk mund tĂ« luani me çmimin. Ne rrisim çmimin e ofertave me 5-10 % pĂ«r tĂ« ulur probabilitetin qĂ« ju tĂ« eliminoheni. Do tĂ« thotĂ«, me ofertat kurseni, por ato mund t'ju merren nĂ« çdo moment. NĂ«se jeni pak mĂ« tĂ« lartĂ« çmimi se tĂ« tjerĂ«t, do tĂ« eliminoheni mĂ« vonĂ«. Google ka njĂ« specifikĂ« krejtĂ«sisht ndryshe. Dhe ka njĂ« kufizim shumĂ« tĂ« pafavorshĂ«m â ato jetojnĂ« vetĂ«m 24 orĂ«. NdonjĂ«herĂ« ne duam tĂ« eksperimentojmĂ« pĂ«r 5 ditĂ«. Por me ofertat Ă«shtĂ« e mundur, ndonjĂ«herĂ« ato jetojnĂ« pĂ«r muaj me radhĂ«.
Përshëndetje! Faleminderit për referatin! Ju përmendët për checkup. Si i llogaritni gabimet stat_statements?
Pyetje shumĂ« e mirĂ«. Mund tĂ« tregoj dhe tĂ« shpjegoj nĂ« detaje. NĂ« shkurtime â ne shikojmĂ« se si ka ndryshuar grupi i kĂ«rkesave: sa janĂ« eliminuar dhe sa tĂ« reja janĂ« shfaqur. Dhe mĂ« pas ne shikojmĂ« dy metrika: total_time dhe calls, prandaj ka dy gabime. Dhe shohim, çfarĂ« kontributi kanĂ« grupet qĂ« janĂ« ndryshuar. Ka dy nĂ«n-grupe: ato qĂ« janĂ« ikur dhe ato qĂ« janĂ« kthyer. ShikojmĂ«, çfarĂ« kontributi kanĂ« nĂ« pamjen e pĂ«rgjithshme.
A mos keni frikë se ajo do të rrotullohet dy-tre herë në kohën midis snapshot-ëve?
Do të thotë, ata u regjistruan përsëri ose si?
Për shembull, kjo kërkesë është eliminuar një herë, pastaj erdhi dhe u eliminuar përsëri, pastaj erdhi sërish dhe u eliminuar përsëri. Dhe këtu llogaritet diçka, dhe ku është e gjithë kjo?
Pyetje e mirë, duhet të shikojmë.
Kam bërë diçka të ngjashme. Sigurisht më e thjeshtë, e kam bërë vetëm. Por mu desh të rikthehem, të bëj reset stat_statements dhe të orientohesha në momentin e snapshot-it, duke parë që kishte më pak se një pjesë të caktuar, që ende nuk kishte arritur në kulm, sa stat_statements mund të grumbullohen. Dhe unë orientohesha që, me sa duket, nuk ishte eliminuar asgjë.
Po-po.
Por nuk e kuptoj si mund ta bëj ndryshe me saktësi.
MĂ« vjen keq, nuk e mbaj mend saktĂ«sisht â pĂ«rdorim tekstin e kĂ«rkesĂ«s ose queryid nga pg_stat_statements dhe mbi tĂ« orientoheshim. NĂ«se ne orientoheshim nĂ« queryid, nĂ« parim, krahasojmĂ« gjĂ«ra tĂ« krahasueshme.
Jo, ai mund të largohet disa herë midis snapshot-eve dhe të vijë sërish.
Me këtë ID të njëjtë?
Po.
Ne do ta studiojmë këtë. Pyetje e mirë. Duhet të hulumtojmë. Por për momentin, ajo që shohim është ose 0 shkruhet...
Sigurisht, kjo është një rast i rrallë, por më tronditi kur mësova se stat_statements mund të largohet atje.
Në Pg_stat_statements mund të ketë shumë gjëra. Ne kemi kaluar me atë që nëse keni track_utility = on, atëherë grupet tuaja gjithashtu ndjeken.
Po, sigurisht.
Dhe nëse keni java hibernate, që është rastësor, atëherë aty fillon të bllokohet tabela e hash-it. Dhe sapo të çaktivizoni një aplikacion me ngarkesë të madhe, keni 50-100 grupe. Dhe aty gjithçka është më shumë-më pak e stabilizuar. Një nga mënyrat për të luftuar këtë është të rritur pg_stat_statements.max.
Po, por duhet të dini se sa. Dhe ndonjëherë duhet ta monitoroni. Unë e bëj këtë. Domethënë, kam pg_stat_statements.max. Dhe shoh se në momentin e snapshot-it nuk kam arritur 70% të saj. Mirë, domethënë, nuk kemi humbur asgjë. Bëjmë reset. Dhe grumbullojmë sërish. Nëse në snapshot-in tjetër është më pak se 70, atëherë me shumë gjasë, sërish nuk kemi humbur asgjë.
Po. Për default tani janë 5,000. Dhe shumë njerëz e kanë mjaft këtë.
Zakonisht â po.
Video:
P.S. Nga ana ime, do të shtoj se nëse në Postgres ka të dhëna konfidenciale dhe ato nuk duhet të kalojnë në ambientin e testimit, atëherë mund të përdorni . Schema është përafërsisht si më poshtë:
Burimi: habr.com
