Unë ju sugjeroj të lexoni transkriptin e raportit të Nikolai Samokhvalov "Qasja industriale për akordimin e PostgreSQL: eksperimente në bazat e të dhënave"
Shared_buffers = 25% - është shumë apo pak? Apo thjesht e drejtë? Si e dini nëse ky rekomandim - mjaft i vjetëruar - është i përshtatshëm në rastin tuaj të veçantë?
Është koha për t'iu qasur çështjes së zgjedhjes së parametrave postgresql.conf "si një i rritur". Jo me ndihmën e "akorduesve automatikë" të verbër ose këshillave të vjetruara nga artikujt dhe bloget, por bazuar në:
- eksperimente të verifikuara rreptësisht në bazat e të dhënave, të kryera automatikisht, në sasi të mëdha dhe në kushte sa më të afërta me ato "luftarake",
- kuptim i thellë i veçorive të DBMS dhe OS.
Duke përdorur Nancy CLI (), do të shikojmë një shembull specifik - shared_buffers famëkeq - në situata të ndryshme, në projekte të ndryshme dhe do të përpiqemi të kuptojmë se si të zgjedhim cilësimin optimal për infrastrukturën, bazën e të dhënave dhe ngarkesën tonë.
Do të flasim për eksperimente me bazat e të dhënave. Kjo është një histori që zgjat pak më shumë se gjashtë muaj.
Pak për mua. Eksperiencë me Postgres për më shumë se 14 vjet. Një numër i kompanive të rrjeteve sociale kanë themeluar. Postgres ishte dhe përdoret kudo.
Gjithashtu grupi RuPostgres në Meetup, vendi i 2-të në botë. Dalëngadalë po i afrohemi 2 njerëzve. RuPostgres.org.
Dhe në PC të konferencave të ndryshme, duke përfshirë Highload, unë jam përgjegjës për bazat e të dhënave, veçanërisht Postgres që në fillim.
Dhe në vitet e fundit, unë kam rifilluar praktikën time të konsultimit Postgres 11 zona kohore nga këtu.
Dhe kur e bëra këtë disa vite më parë, pata një pushim në punën aktive manuale me Postgres, ndoshta që nga viti 2010. U habita se sa pak ka ndryshuar rutina e punës e një DBA dhe sa punë manuale duhet ende të përdoret. Dhe menjëherë mendova se diçka nuk ishte në rregull këtu, më duhet të automatizoj më shumë nga gjithçka.
Dhe duke qenë se gjithçka ishte e largët, shumica e klientëve ishin në retë. Dhe shumë tashmë janë automatizuar, natyrisht. Më shumë për këtë më vonë. Kjo do të thotë, e gjithë kjo rezultoi në idenë se duhet të ketë një numër mjetesh, d.m.th., një lloj platforme që do të automatizojë pothuajse të gjitha veprimet e DBA në mënyrë që një numër i madh i bazave të të dhënave të mund të menaxhohet.
Ky raport nuk do të përfshijë:
- "Plumba argjendi" dhe deklarata si - vendosni 8 GB ose 25% shared_buffers dhe do të jeni mirë. Nuk do të ketë shumë për shared_buffers.
- Hardcore "të brendshme".
Çfarë do të ndodhë?
- Do të ketë parime optimizimi që ne i zbatojmë dhe zhvillojmë. Do të ketë lloj-lloj idesh që lindin gjatë rrugës dhe mjete të ndryshme që ne i krijojmë në pjesën më të madhe në Open Source, dmth ne bëjmë bazën në Open Source. Për më tepër, ne kemi bileta, i gjithë komunikimi është praktikisht me kod të hapur. Ju mund të shihni se çfarë po bëjmë tani, çfarë do të jetë në versionin e ardhshëm, etj.
- Do të ketë gjithashtu një përvojë në përdorimin e këtyre parimeve, këtyre mjeteve në një sërë kompanish: nga startup-et e vogla tek kompanitë e mëdha.
Si po zhvillohet e gjithë kjo?
Së pari, detyra kryesore e një DBA, përveç sigurimit të krijimit të instancave, vendosjes së kopjeve rezervë, etj., është gjetja e pengesave dhe optimizimi i performancës.
Tani është vendosur kështu. Ne shikojmë monitorimin, shohim diçka, por na mungojnë disa detaje. Ne fillojmë të gërmojmë më me kujdes, zakonisht me duart tona, dhe të kuptojmë se çfarë të bëjmë me të në një mënyrë ose në një tjetër.
Dhe ka dy qasje. Pg_stat_statements është zgjidhja e paracaktuar për identifikimin e pyetjeve të ngadalta. Dhe analiza e regjistrave Postgres duke përdorur pgBadger.
Çdo qasje ka disavantazhe serioze. Në qasjen e parë, ne kemi hedhur jashtë të gjithë parametrat. Dhe nëse shohim grupet SELECT * FROM tabela ku kolona është e barabartë me "?" ose “$” që nga Postgres 10. Ne nuk e dimë nëse ky është një skanim indeks apo një skanim vijues. Varet shumë nga parametri. Nëse zëvendësoni një vlerë që haset rrallë atje, do të jetë një skanim indeksi. Nëse zëvendësoni një vlerë që zë 90% të tabelës atje, skanimi vijues do të jetë i dukshëm, sepse Postgres i di statistikat. Dhe kjo është një pengesë e madhe e pg_stat_statements, megjithëse disa punë janë duke u zhvilluar.
Disavantazhi më i madh i analizës së regjistrave është se ju nuk mund të përballoni "log_min_duration_statement = 0" si rregull. Dhe ne do të flasim edhe për këtë. Prandaj, ju nuk e shihni të gjithë pamjen. Dhe disa pyetje, që janë shumë të shpejta, mund të konsumojnë një sasi të madhe burimesh, por ju nuk do ta shihni atë sepse është nën pragun tuaj.
Si i zgjidhin DBA-të problemet që gjejnë?
Për shembull, kemi gjetur një problem. Çfarë bëhet zakonisht? Nëse jeni një zhvillues, atëherë do të bëni diçka në një rast që nuk është me të njëjtën madhësi. Nëse jeni një DBA, atëherë keni skenë. Dhe mund të ketë vetëm një. Dhe ai ishte gjashtë muaj prapa. Dhe ju mendoni se do të shkoni në prodhim. Dhe madje edhe DBA me përvojë, më pas kontrolloni në prodhim, në një kopje. Dhe ndodh që ata të krijojnë një indeks të përkohshëm, të sigurohen që ai të ndihmojë, ta lëshojnë dhe t'ua japin zhvilluesve në mënyrë që ta vendosin në skedarët e migrimit. Ky është lloji i marrëzive që po ndodh tani. Dhe ky është një problem.
- Rregulloni konfigurimet.
- Optimizoni grupin e indekseve.
- Ndryshoni vetë pyetjen SQL (kjo është mënyra më e vështirë).
- Shtoni kapacitetin (mënyra më e lehtë në shumicën e rasteve).
Po ndodh shumë me këto gjëra. Ka shumë doreza në Postgres. Ka shumë për të ditur. Në Postgres ka shumë indekse, falë edhe organizatorëve të kësaj konference. Dhe e gjithë kjo duhet të dihet, dhe kjo është ajo që i bën jo-DBA-të të ndihen sikur DBA-të po praktikojnë magji të zezë. Kjo do të thotë, ju duhet të studioni për 10 vjet për të filluar të kuptoni të gjitha këto normalisht.
Dhe unë jam një luftëtar kundër kësaj magjie të zezë. Unë dua të bëj gjithçka në mënyrë që të ketë teknologji dhe të mos ketë intuitë në gjithë këtë.
Shembuj të jetës reale
E kam vërejtur këtë në të paktën dy projekte, duke përfshirë edhe timin. Një tjetër postim në blog na tregon se një vlerë prej 1 për default_statistict_target është e mirë. Mirë, le ta provojmë në prodhim.
Dhe ja ku jemi, duke përdorur mjetin tonë dy vjet më vonë, me ndihmën e eksperimenteve në bazat e të dhënave për të cilat po flasim sot, ne mund të krahasojmë atë që ishte dhe çfarë është bërë.
Dhe për këtë ne duhet të krijojmë një eksperiment. Ai përbëhet nga katër pjesë.
- E para është mjedisi. Ne kemi nevojë për një pjesë të pajisjeve. Dhe kur vij në ndonjë kompani dhe nënshkruaj një kontratë, u them atyre të më japin të njëjtin harduer si në prodhim. Për secilin prej Masterit tuaj, më duhet të paktën një pjesë e pajisjeve të tilla. Ose kjo është një makinë virtuale e shembullit në Amazon ose Google, ose më duhet saktësisht e njëjta pjesë e harduerit. Kjo është, unë dua të rikrijoj mjedisin. Dhe në konceptin e mjedisit ne përfshijmë versionin kryesor të Postgres.
- Pjesa e dytë është objekt i hulumtimit tonë. Kjo është një bazë të dhënash. Mund të krijohet në disa mënyra. Unë do t'ju tregoj se si.
- Pjesa e tretë është ngarkesa. Ky është momenti më i vështirë.
- Dhe pjesa e katërt është ajo që ne kontrollojmë, pra çfarë do të krahasojmë me çfarë. Le të themi se mund të ndryshojmë një ose më shumë parametra në konfigurim, ose mund të krijojmë një indeks, etj.
Ne po nisim një eksperiment. Këtu janë pg_stat_statements. Në të majtë është ajo që ndodhi. Në të djathtë - çfarë ndodhi.
Në të majtë default_statistics_target = 100, në të djathtë = 1. Ne shohim se kjo na ndihmoi. Në përgjithësi, gjithçka u përmirësua me 000%.
Por nëse lëvizim poshtë, do të ketë grupe kërkesash nga pgBadger ose nga pg_stat_statements. Ka dy opsione. Do të shohim që disa kërkesa kanë rënë me 88%. Dhe këtu vjen qasja inxhinierike. Mund të gërmojmë më tej brenda sepse pyesim veten pse u fundos. Ju duhet të kuptoni se çfarë ndodhi me statistikat. Pse më shumë kova në statistika çojnë në rezultate më të këqija.
Ose nuk mund të gërmojmë, por bëjmë “ALTER TABLE ... ALTER COLUMN” dhe kthejmë 100 kova në statistikat e kësaj kolone. Dhe më pas me një eksperiment tjetër mund të sigurohemi që kjo patch ndihmoi. Të gjitha. Kjo është një qasje inxhinierike që na ndihmon të shohim pamjen e madhe dhe të marrim vendime bazuar në të dhëna dhe jo në intuitë.
Disa shembuj nga fusha të tjera. Ka pasur teste CI në testim për shumë vite. Dhe asnjë projekt në mendjen e tij të duhur nuk do të jetonte pa teste të automatizuara.
Në industri të tjera: në aviacion, në industrinë e automobilave, kur testojmë aerodinamikën, kemi mundësinë të bëjmë edhe eksperimente. Ne nuk do të lëshojmë diçka nga një vizatim direkt në hapësirë, ose nuk do të marrim menjëherë ndonjë makinë në pistë. Për shembull, ekziston një tunel me erë.
Ne mund të nxjerrim përfundime nga vëzhgimet e industrive të tjera.
Së pari, ne kemi një mjedis të veçantë. Është afër prodhimit, por jo afër. Karakteristika e tij kryesore është se duhet të jetë i lirë, i përsëritshëm dhe sa më i automatizuar. Dhe gjithashtu duhet të ketë mjete speciale për kryerjen e analizave të hollësishme.
Me shumë mundësi, kur nisim një aeroplan dhe fluturojmë, kemi më pak mundësi për të studiuar çdo milimetër të sipërfaqes së krahut sesa kemi në një tunel me erë. Ne kemi më shumë mjete diagnostikuese. Ne mund të përballojmë të mbajmë më shumë gjëra të rënda që nuk mund t'i lejojmë t'i vendosim në një aeroplan në ajër. E njëjta gjë me Postgres. Në disa raste, ne mund të aktivizojmë regjistrimin e plotë të pyetjeve gjatë eksperimenteve. Dhe ne nuk duam ta bëjmë këtë në prodhim. Ne madje mund të planifikojmë ta aktivizojmë këtë duke përdorur auto_explain.
Dhe siç thashë, një nivel i lartë automatizimi do të thotë që ne shtypim butonin dhe përsërisim. Kështu duhet të jetë, që të ketë shumë eksperimente, që të jetë në rrymë.
Nancy CLI - themeli i "laboratorit të bazës së të dhënave"
Dhe kështu e bëmë këtë gjë. Domethënë, unë fola për këto ide në qershor, gati një vit më parë. Dhe ne tashmë kemi të ashtuquajturin Nancy CLI në Open Source. Ky është baza për ndërtimin e një laboratori të bazës së të dhënave.
- Është në Open Source, në Gitlab. Mund ta thuash, mund ta provosh. Kam dhënë një lidhje në sllajde. Mund të klikoni mbi të dhe do të jetë aty në të gjitha aspektet.
Sigurisht, ka ende shumë në zhvillim. Ka shumë ide atje. Por kjo është diçka që ne e përdorim pothuajse çdo ditë. Dhe kur kemi një ide - pse kur fshijmë 40 rreshta, gjithçka vjen në IO, atëherë ne mund të bëjmë një eksperiment dhe të shikojmë më në detaje për të kuptuar se çfarë po ndodh dhe pastaj të përpiqemi ta rregullojmë atë në fluturim. Kjo do të thotë, ne po bëjmë një eksperiment. Për shembull, ne shkulim diçka dhe shohim se çfarë ndodh në fund. Dhe ne nuk e bëjmë këtë në prodhim. Ky është thelbi i idesë.
Ku mund të funksionojë kjo? Kjo mund të funksionojë në nivel lokal, d.m.th. ju mund ta bëni atë kudo, madje mund ta ekzekutoni në një MacBook. Ne kemi nevojë për një doker, le të shkojmë. Kjo eshte e gjitha. Ju mund ta ekzekutoni atë në disa raste në një pjesë të harduerit, ose në një makinë virtuale, kudo.
Dhe ekziston gjithashtu mundësia për të kandiduar nga distanca në Amazon në shembullin EC2, në spote. Dhe kjo është një mundësi shumë e bukur. Për shembull, dje kemi kryer më shumë se 500 eksperimente në shembullin i3, duke filluar nga më i riu dhe duke përfunduar me i3-16-xlarge. Dhe 500 eksperimente na kushtojnë 64 dollarë. Secila zgjati 15 minuta. Kjo do të thotë, për faktin se aty përdoren spotet, është shumë i lirë - 70% zbritje, faturimi i Amazon për sekondë. Ju mund të bëni shumë. Ju mund të bëni kërkime të vërteta.
Dhe tre versione kryesore të Postgres janë mbështetur. Nuk është aq e vështirë të përfundosh disa të vjetra dhe versionin e ri të 12-të gjithashtu.
Ne mund të përcaktojmë një objekt në tre mënyra. Kjo:
- Hidh/sql skedar.
- Mënyra kryesore është të klononi direktorinë PGDATA. Si rregull, merret nga serveri rezervë. Nëse keni kopje rezervë normale binare, mund të bëni klone nga atje. Nëse keni re, atëherë një zyrë cloud si Amazon dhe Google do ta bëjë këtë për ju. Kjo është mënyra më e rëndësishme për të klonuar prodhimin e vërtetë. Kështu shpalosemi ne.
- Dhe metoda e fundit është e përshtatshme për kërkime kur doni të kuptoni se si funksionon diçka në Postgres. Ky është pgbench. Ju mund të gjeneroni duke përdorur pgbench. Është vetëm një opsion "db-pgbench". Ju tregoni se çfarë peshore. Dhe gjithçka do të gjenerohet në re, siç u tha.
Dhe ngarkoni:
- Ne mund të ekzekutojmë ngarkesën në një thread SQL. Kjo është mënyra më primitive.
- Dhe ne mund të imitojmë ngarkesën. Dhe ne mund ta imitojmë atë para së gjithash në mënyrën e mëposhtme. Ne duhet të mbledhim të gjitha shkrimet. Dhe është e dhimbshme. Unë do t'ju tregoj pse. Dhe duke përdorur pgreplay ne luajmë, e cila është ndërtuar në Nancy.
- Ose një opsion tjetër. E ashtuquajtura ngarkesë artizanale, të cilën e bëjmë me një përpjekje të caktuar. Duke analizuar ngarkesën tonë aktuale në sistemin luftarak, ne nxjerrim grupet kryesore të kërkesave. Dhe duke përdorur pgbench ne mund ta imitojmë këtë ngarkesë në laborator.
- Ose duhet të kryejmë një lloj SQL, pra të kontrollojmë një lloj migrimi, të krijojmë një indeks atje, të ekzekutojmë ANALAZE atje. Dhe ne shikojmë se çfarë ndodhi para vakumit dhe pas vakumit. Në përgjithësi, çdo SQL.
- Ose ne ndryshojmë një ose më shumë parametra në konfigurim. Mund të na themi që të kontrollojmë, për shembull, 100 vlera në Amazon për bazën tonë të të dhënave terabyte. Dhe në pak orë do të keni rezultatin. Si rregull, do t'ju duhen disa orë për të vendosur një bazë të dhënash terabyte. Por ka një patch në zhvillim, ne kemi një seri të mundshme, d.m.th. ju mund të përdorni vazhdimisht të njëjtat pgdata në të njëjtin server dhe të kontrolloni. Postgres do të riniset dhe cache-të do të rivendosen. Dhe ju mund të drejtoni ngarkesën.
- Mbërrin një direktori me një mori skedarësh të ndryshëm, duke filluar nga fotografitë e fotografive të pgstat***. Dhe gjëja më interesante është pg_stat_statements, pg_stat_kcacke. Këto janë dy shtesa që analizojnë kërkesat. Dhe pg_stat_bgwriter përmban jo vetëm statistika të pgwriter, por edhe në pikat e kontrollit dhe sesi vetë backend-et zhvendosin buferët e pista. Dhe është e gjitha interesante për të parë. Për shembull, kur vendosim shared_buffers, është shumë interesante të shihet se sa zëvendësuan të gjithë.
- Po mbërrijnë edhe shkrimet e Postgres. Dy regjistra - një regjistër i përgatitjes dhe një regjistër i riprodhimit të ngarkesës.
- Një veçori relativisht e re është FlameGraphs.
- Gjithashtu, nëse keni përdorur opsione pgreplay ose pgbench për të luajtur ngarkesën, atëherë prodhimi i tyre do të jetë vendas. Dhe do të shihni latente dhe TPS. Do të jetë e mundur të kuptohet se si e panë.
- Informacioni i sistemit.
- Kontrollet bazë të CPU dhe IO. Kjo është më shumë për shembullin EC2 në Amazon, kur dëshironi të lëshoni 100 raste identike në një fije dhe të ekzekutoni 100 ekzekutime të ndryshme atje, atëherë do të keni 10 eksperimente. Dhe ju duhet të siguroheni që të mos hasni në një rast të metë që tashmë është duke u shtypur nga dikush. Të tjerët janë aktivë në këtë pjesë të harduerit dhe ju keni mbetur pak burim. Është më mirë të hidhni poshtë rezultate të tilla. Dhe me ndihmën e sysbench nga Alexey Kopytov, ne bëjmë disa kontrolle të shkurtra që do të vijnë dhe mund të krahasohen me të tjerët, d.m.th. do të kuptoni se si sillet CPU dhe si sillet IO.
Cilat janë vështirësitë teknike bazuar në shembullin e kompanive të ndryshme?
Le të themi se duam të përsërisim ngarkesën reale duke përdorur regjistrat. Është një ide e shkëlqyer nëse është shkruar në pgreplay me burim të hapur. Ne e përdorim atë. Por që të funksionojë mirë, duhet të aktivizoni regjistrimin e plotë të pyetjeve me parametra dhe kohë.
Ka disa komplikime me kohëzgjatjen dhe vulën kohore. Do ta zbrazim gjithë këtë kuzhinë. Pyetja kryesore është nëse mund ta përballoni apo jo?
Problemi është se mund të mos jetë i disponueshëm. Para së gjithash, duhet të kuptoni se çfarë transmetimi do të shkruhet në regjistër. Nëse keni pg_stat_statements, mund të përdorni këtë pyetje (lidhja do të jetë e disponueshme në sllajde) për të kuptuar përafërsisht sa bajt do të shkruhen në sekondë.
Ne shikojmë gjatësinë e kërkesës. Po neglizhojmë faktin që nuk ka parametra, por e dimë gjatësinë e kërkesës dhe e dimë se sa herë në sekondë është ekzekutuar. Në këtë mënyrë ne mund të vlerësojmë përafërsisht sa bajt në sekondë. Mund të gabojmë dy herë më shumë, por rendin do ta kuptojmë patjetër në këtë mënyrë.
Mund të shohim se 802 herë në sekondë kjo kërkesë ekzekutohet. Dhe ne shohim që bytes_per sec – 300 kB/s do të shkruhet plus ose minus. Dhe, si rregull, ne mund të përballojmë një rrjedhë të tillë.
Por! Fakti është se ekzistojnë sisteme të ndryshme të prerjeve. Dhe parazgjedhja e njerëzve është zakonisht "syslog".
Dhe nëse keni syslog, atëherë mund të keni një foto si kjo. Ne do të marrim pgbench, do të aktivizojmë regjistrimin e pyetjeve dhe do të shohim se çfarë ndodh.
Pa prerje - kjo është kolona në të majtë. Ne morëm 161 TPS. Me syslog - kjo është në Ubuntu 000 në Amazon, ne marrim 16.04 TPS. Dhe nëse kalojmë në dy metoda të tjera të prerjeve, atëherë situata është shumë më e mirë. Domethënë ne prisnim të binte, por jo në të njëjtën masë.
Dhe në CentOS 7, në të cilin merr pjesë edhe ditari, duke i kthyer regjistrat në një format binar për kërkim të lehtë, etj., atëherë është një makth atje, ne lëshojmë 44 herë në TPS.
Dhe kjo është ajo me të cilën njerëzit jetojnë. Dhe shpesh në kompani, veçanërisht ato të mëdha, kjo është shumë e vështirë të ndryshohet. Nëse mund të largoheni nga syslog, atëherë ju lutemi largohuni prej tij.
- Vlerësoni IOPS dhe shkruani rrjedhën.
- Kontrolloni sistemin tuaj të regjistrimit.
- Nëse ngarkesa e parashikuar është tepër e madhe, merrni parasysh marrjen e mostrave.
Kemi pg_stat_statements. Siç thashë, duhet të jetë atje. Dhe ne mund të marrim dhe përshkruajmë çdo grup kërkesash në një mënyrë të veçantë në një skedar. Dhe atëherë mund të përdorim një veçori shumë të përshtatshme në pgbench - kjo është aftësia për të futur disa skedarë duke përdorur opsionin "-f".
Kupton shumë "-f". Dhe ju mund të tregoni me ndihmën e "@" në fund se çfarë ndarjeje duhet të ketë çdo skedar. Kjo do të thotë, mund të themi se bëni këtë në 10% të rasteve, dhe këtë në 20%. Dhe kjo do të na afrojë më shumë me atë që shohim në prodhim.
Si do ta kuptojmë atë që kemi në prodhim? Çfarë ndarjeje dhe si? Kjo është pak mënjanë. Kemi edhe një produkt . Gjithashtu një bazë në Open Source. Dhe ne tani jemi duke e zhvilluar në mënyrë aktive.
Ai lindi për arsye paksa të ndryshme. Për arsye që monitorimi nuk mjafton. Domethënë vini, shikoni bazën, shikoni problemet që ekzistojnë. Dhe, si rregull, ju bëni një kontroll_shëndeti. Nëse jeni një DBA me përvojë, atëherë bëni health_check. Ne shikuam përdorimin e indekseve, etj. Nëse keni OKmeter, atëherë shkëlqyeshëm. Ky është një monitorim i lezetshëm për Postgres. OKmeter.io – ju lutemi instaloni, gjithçka është bërë shumë mirë atje. Është paguar.
Nëse nuk keni një të tillë, atëherë zakonisht nuk keni shumë. Në monitorim, zakonisht ka CPU, IO, dhe më pas me rezervime, dhe kjo është e gjitha. Dhe ne kemi nevojë për më shumë. Ne duhet të shohim se si funksionon autovakuumi, si funksionon pika e kontrollit, në io duhet të ndajmë pikën e kontrollit nga bgwriter dhe nga backend-et, etj.
Problemi është se kur ju ndihmoni një kompani të madhe, ata nuk mund të zbatojnë diçka shpejt. Ata nuk mund të blejnë shpejt OKmeter. Ndoshta do ta blejnë pas gjashtë muajsh. Ata nuk mund të dorëzojnë shpejt disa pako.
Dhe ne dolëm me idenë se ne kemi nevojë për një mjet të veçantë që nuk kërkon asgjë për t'u instaluar, d.m.th. ju nuk keni nevojë të instaloni asgjë në prodhim. Instaloni atë në laptopin tuaj ose në një server vëzhgues nga ku do ta ekzekutoni. Dhe do të analizojë shumë gjëra: sistemin operativ, sistemin e skedarëve dhe vetë Postgres, duke bërë disa pyetje të lehta që mund të drejtohen drejtpërdrejt në prodhim dhe asgjë nuk do të dështojë.
Ne e quajtëm atë Postgres-checkup. Në terma mjekësorë, ky është një kontroll i rregullt shëndetësor. Nëse është me temë automobilistike, atëherë është si mirëmbajtje. Ju bëni mirëmbajtje në makinën tuaj çdo gjashtë muaj ose një vit, në varësi të markës. A bëni mirëmbajtje për bazën tuaj? Kjo do të thotë, a bëni rregullisht kërkime të thella? Duhet bërë. Nëse bëni kopje rezervë, atëherë bëni një kontroll, kjo nuk është më pak e rëndësishme.
Dhe ne kemi një mjet të tillë. Filloi të shfaqej në mënyrë aktive vetëm rreth tre muaj më parë. Ai është ende i ri, por ka shumë.
Mbledhja e grupeve më "me ndikim" të pyetjeve - raportoni K003 në Postgres-checkup
Dhe ka një grup raportesh K. Tre raporte deri tani. Dhe ekziston një raport i tillë K003. Ekziston pjesa e sipërme nga pg_stat_statements, e renditur sipas total_time.
Kur i renditim grupet e kërkesave sipas total_time, në krye shohim grupin që ngarkon më shumë sistemin tonë, d.m.th. konsumon më shumë burime. Pse i emërtoj grupet e pyetjeve? Sepse i hodhëm jashtë parametrat. Këto nuk janë më kërkesa, por grupe kërkesash, pra janë të abstraguara.
Dhe nëse optimizojmë nga lart poshtë, do të lehtësojmë burimet tona dhe do të vonojmë momentin kur duhet të përmirësohemi. Kjo është një mënyrë shumë e mirë për të kursyer para.
Ndoshta kjo nuk është një mënyrë shumë e mirë për t'u kujdesur për përdoruesit, sepse mund të mos shohim raste të rralla, por shumë të bezdisshme ku një person ka pritur 15 sekonda. Në total, ato janë aq të rralla sa nuk i shohim, por kemi të bëjmë me burime.
Çfarë ndodhi në këtë tabelë? Ne bëmë dy fotografi. Postgres_checkup do t'ju japë një delta për çdo metrikë: koha totale, thirrjet, rreshtat, shared_blks_read, etj. Kjo është ajo, delta është llogaritur. Problemi i madh me pg_stat_statements është se nuk mban mend kur është rivendosur. Nëse pg_stat_database mban mend, atëherë pg_stat_statements nuk mban mend. E shihni që ka një numër prej 1, por ne nuk e dimë se nga kemi numëruar.
Dhe ja ku e dimë, këtu kemi dy fotografi. Ne e dimë se delta në këtë rast ishte 56 sekonda. Një hendek shumë i shkurtër. Renditur sipas total_time. Dhe pastaj ne mund të diferencojmë, d.m.th. ne i ndajmë të gjitha metrikat sipas kohëzgjatjes. Nëse e ndajmë secilën metrikë sipas kohëzgjatjes, do të kemi numrin e thirrjeve për sekondë.
Më pas, total_time për sekondë është metrika ime e preferuar. Ajo matet në sekonda, për sekondë, pra sa sekonda iu deshën sistemit tonë për të ekzekutuar këtë grup kërkesash për sekondë. Nëse shihni më shumë se një sekondë në sekondë atje, do të thotë se duhet të jepni më shumë se një bërthamë. Kjo është një metrikë shumë e mirë. Ju mund të kuptoni që ky mik, për shembull, ka nevojë për të paktën tre bërthama.
Kjo është njohuria jonë, nuk kam parë askund diçka të tillë. Ju lutemi vini re - kjo është një gjë shumë e thjeshtë - sekondë në sekondë. Ndonjëherë, kur CPU-ja juaj është 100%, atëherë gjysmë ore në sekondë, domethënë keni shpenzuar gjysmë ore duke bërë vetëm këto kërkesa.
Më pas shohim rreshta për sekondë. Ne e dimë se sa rreshta në sekondë u kthyen.
Dhe pastaj ka edhe një gjë interesante. Sa shared_buffer lexojmë në sekondë nga vetë shared_buffers. Goditjet ishin tashmë aty, dhe ne i morëm rreshtat nga cache e sistemit operativ ose nga disku. Opsioni i parë është i shpejtë, dhe i dyti mund të jetë ose jo i shpejtë, në varësi të situatës.
Dhe mënyra e dytë e diferencimit është ndarja e numrit të kërkesave në këtë grup. Në kolonën e dytë do të keni gjithmonë një pyetje të ndarë për pyetje. Dhe pastaj është interesante - sa milisekonda ishin në këtë kërkesë. Ne e dimë se si sillet mesatarisht kjo pyetje. Për çdo kërkesë kërkoheshin 101 milisekonda. Kjo është metrika tradicionale që duhet të kuptojmë.
Sa rreshta ktheu mesatarisht çdo pyetje? Ne shohim 8 ky grup kthehet. Mesatarisht, sa është marrë nga cache dhe është lexuar. Ne shohim që gjithçka është ruajtur mirë. Goditje të forta për grupin e parë.
Dhe nënvargu i katërt në çdo rresht është sa përqindje e totalit. Kemi thirrje. Le të themi 1 000 000. Dhe ne mund të kuptojmë se çfarë kontributi jep ky grup. Shohim që në këtë rast grupi i parë kontribuon më pak se 0,01%. Kjo do të thotë, është aq i ngadalshëm sa nuk e shohim atë në pamjen e përgjithshme. Dhe grupi i dytë është 5% në thirrje. Kjo do të thotë, 5% e të gjitha thirrjeve janë grupi i dytë.
Total_time është gjithashtu interesante. Ne shpenzuam 14% të kohës sonë totale të punës për grupin e parë të kërkesave. Dhe për të dytën - 11%, etj.
Nuk do të hyj në detaje, por ka hollësi. Ne shfaqim një gabim në krye, sepse kur krahasojmë, fotografitë mund të lundrojnë, domethënë disa kërkesa mund të bien dhe të mos jenë më të pranishme në të dytën, ndërsa mund të shfaqen disa të reja. Dhe këtu ne llogarisim gabimin. Nëse shihni 0, atëherë kjo është mirë. Nuk ka gabime. Nëse shkalla e gabimit është deri në 20%, është në rregull.
Më pas i kthehemi temës sonë. Ne duhet të krijojmë ngarkesën e punës. E marrim nga lart poshtë dhe shkojmë derisa të arrijmë 80% ose 90%. Zakonisht këto janë 10-20 grupe. Dhe ne krijojmë skedarë për pgbench. Ne përdorim të rastësishëm atje. Ndonjëherë kjo, për fat të keq, nuk funksionon. Dhe në Postgres 12 do të ketë më shumë mundësi për të përdorur këtë qasje.
Dhe pastaj fitojmë 80-90% në total_time në këtë mënyrë. Çfarë duhet të vendos më pas pas "@"? Ne i shikojmë thirrjet, shikojmë sa interes ka dhe kuptojmë që kemi kaq shumë interes këtu. Nga këto përqindje mund të kuptojmë se si të balancojmë secilin nga skedarët. Pas kësaj ne përdorim pgbench dhe shkojmë në punë.
Kemi edhe K001 dhe K002.
K001 është një varg i madh me katër nënvargje. Kjo është një karakteristikë e gjithë ngarkesës sonë. Shihni kolonën e dytë dhe nënrendin e dytë. Ne shohim që rreth një sekondë e gjysmë në sekondë, d.m.th. nëse ka dy bërthama, atëherë do të jetë mirë. Do të ketë rreth 75% kapacitet. Dhe do të funksionojë kështu. Nëse kemi 10 bërthama, atëherë në përgjithësi do të jemi të qetë. Në këtë mënyrë ne mund të vlerësojmë burimet.
K002 është ajo që unë i quaj klasa pyetjesh, d.m.th. SELECT, INSERT, UPDATE, DELETE. Dhe veçmas ZGJEDHJE PËR PËRDITËSIM, sepse është një bravë.
Dhe këtu mund të konkludojmë se SELECT janë lexues të zakonshëm - 82% e të gjitha thirrjeve, por në të njëjtën kohë - 74% në total_time. Kjo është, ata quhen shumë, por konsumojnë më pak burime.
Dhe i kthehemi pyetjes: "Si mund të zgjedhim shared_buffer-et e duhura?" Unë vërej se shumica e standardeve bazohen në idenë - le të shohim se çfarë do të jetë xhiroja, d.m.th. sa do të jetë xhiroja. Zakonisht matet në TPS ose QPS.
Dhe ne përpiqemi të shtrydhim sa më shumë transaksione në sekondë nga makina duke përdorur parametrat e akordimit. Këtu është saktësisht 311 për sekondë për të zgjedhur.
Por askush nuk shkon me makinë për në punë dhe në shtëpi me shpejtësi të plotë. Kjo është budallallëk. E njëjta gjë me bazat e të dhënave. Ne nuk duhet të ngasim me shpejtësi të plotë dhe askush nuk e bën. Askush nuk jeton në prodhim, i cili ka 100% CPU. Edhe pse, ndoshta dikush jeton, por kjo nuk është mirë.
Ideja është që ne zakonisht vozisim me 20 për qind të kapacitetit, mundësisht jo më shumë se 50%. Dhe ne përpiqemi të optimizojmë kohën e përgjigjes për përdoruesit tanë mbi të gjitha. Kjo do të thotë, ne duhet t'i kthejmë pullat tona në mënyrë që të ketë një vonesë minimale me shpejtësi 20%, me kusht. Kjo është një ide që ne gjithashtu përpiqemi ta përdorim në eksperimentet tona.
Dhe së fundi, rekomandimet:
- Sigurohuni që të bëni laboratorin e bazës së të dhënave.
- Nëse është e mundur, bëjeni sipas kërkesës në mënyrë që të shpaloset për një kohë - luani dhe hidheni larg. Nëse keni re, atëherë kjo është e vetëkuptueshme, pra keni shumë qëndrim.
- Ji kurioz. Dhe nëse diçka nuk është në rregull, atëherë kontrolloni me eksperimente se si sillet. Nancy mund të përdoret për të trajnuar veten për të kontrolluar se si funksionon baza.
- Dhe synoni kohën minimale të përgjigjes.
- Dhe mos kini frikë nga burimet e Postgres. Kur punoni me burime, duhet të dini anglisht. Ka shumë komente atje, gjithçka është shpjeguar atje.
- Dhe kontrolloni shëndetin e bazës së të dhënave rregullisht, të paktën një herë në tre muaj, manualisht ose kontrolloni Postgres.
Pyetjet tuaja
Faleminderit shume! Një gjë shumë interesante.
Dy pjese.
Po, dy copa. Vetëm unë nuk e kuptova fare. Kur Nency dhe unë punojmë, a mund të rregullojmë vetëm një parametër apo një grup të tërë?
Ne kemi një parametër të konfigurimit delta. Mund të kthehesh aty sa të duash menjëherë. Por ju duhet të kuptoni se kur ndryshoni shumë gjëra, mund të nxirrni përfundime të gabuara.
Po. Pse pyeta? Sepse është e vështirë të bësh eksperimente kur ke vetëm një parametër. Ju e shtrëngoni atë, shikoni se si funksionon. E nxorra jashtë. Pastaj filloni tjetrin.
Mund ta shtrëngoni në të njëjtën kohë, por varet nga situata, sigurisht. Por është më mirë të provosh një ide. Ne kishim një ide dje. Kishim një situatë shumë të ngushtë. Kishte dy konfigurime. Dhe ne nuk mund ta kuptonim pse kishte një ndryshim të madh. Dhe lindi ideja që ju duhet të përdorni dikotominë në mënyrë që të kuptoni dhe gjeni vazhdimisht se cili është ndryshimi. Ju mund të bëni menjëherë gjysmën e parametrave të njëjtë, pastaj një të katërtën, etj. Gjithçka është fleksibël.
Dhe ka edhe një pyetje. Projekti është i ri dhe në zhvillim. Dokumentacioni tashmë është gati, a ka një përshkrim të detajuar?
Unë bëra posaçërisht një lidhje atje me përshkrimin e parametrave. Është aty. Por shumë gjëra ende nuk janë aty. Unë jam duke kërkuar për njerëz me mendje të njëjtë. Dhe i gjej kur performoj. Kjo është shumë e lezetshme. Dikush tashmë po punon me mua, dikush ndihmoi dhe bëri diçka atje. Dhe nëse jeni të interesuar për këtë temë, jepni komente për atë që mungon.
Pasi të ndërtojmë laboratorin, ndoshta do të ketë reagime. Le të shohim. Faleminderit!
Përshëndetje! Faleminderit për raportin! Pashë që ka mbështetje për Amazon. A ka ndonjë plan për të mbështetur GSP?
Pyetje e mirë. Filluam ta bënim. Dhe e kemi ngrirë për momentin sepse duam të kursejmë para. Kjo do të thotë, ka mbështetje duke përdorur ekzekutimin në localhost. Ju mund të krijoni një shembull vetë dhe të punoni në nivel lokal. Nga rruga, kjo është ajo që ne bëjmë. Këtë e bëj në Getlab, atje në GSP. Por ne nuk e shohim ende kuptimin për të bërë vetëm një orkestrim të tillë, sepse Google nuk ka pika të lira. ka ??? raste, por ato kanë kufizime. Së pari, ata kanë gjithmonë vetëm një zbritje prej 70% dhe nuk mund të luash me çmimin atje. Në spote, ne e rrisim çmimin me 5-10% për të zvogëluar gjasat që të shkelmoheni. Kjo do të thotë, ju ruani spote, por ato mund t'ju hiqen në çdo kohë. Nëse bëni një ofertë pak më të lartë se të tjerët, do të vriteni më vonë. Google ka specifika krejtësisht të ndryshme. Dhe ka një kufizim tjetër shumë të keq - ata jetojnë vetëm për 24 orë. Dhe ndonjëherë ne duam të bëjmë një eksperiment për 5 ditë. Por ju mund ta bëni këtë në pika; njollat ndonjëherë zgjasin me muaj.
Përshëndetje! Faleminderit për raportin! Ju përmendët kontrollin. Si i llogaritni gabimet e stat_statements?
Pyetje shumë e mirë. Unë mund t'ju tregoj dhe t'ju tregoj në detaje. Shkurtimisht, ne shikojmë se si grupi i grupeve të kërkesave ka lundruar: sa kanë rënë dhe sa të reja janë shfaqur. Dhe pastaj shikojmë dy metrikë: total_time dhe thirrjet, pra ka dy gabime. Dhe ne shikojmë kontributin e grupeve lundruese. Ka dy nëngrupe: ata që u larguan dhe ata që mbërritën. Le të shohim se cili është kontributi i tyre në pamjen e përgjithshme.
A nuk keni frikë se do të kthehet atje dy ose tre herë gjatë kohës midis fotove?
Dmth u regjistruan sërish apo çfarë?
Për shembull, kjo kërkesë tashmë është paravendosur një herë, pastaj erdhi dhe u paracaktua përsëri, pastaj erdhi përsëri dhe u paracaktua përsëri. Dhe ju llogaritët diçka këtu, dhe ku është e gjitha?
Pyetje e mirë, do të duhet të shikojmë.
Unë bëra një gjë të ngjashme. Ishte më e thjeshtë, sigurisht, e bëra vetëm. Por më duhej të rivendosja, rivendosja stat_statements dhe të kuptoja në kohën e fotografisë se kishte më pak se një fraksion i caktuar, i cili ende nuk arrinte tavanin se sa stat_statements mund të grumbulloheshin atje. Dhe kuptimi im është se, ka shumë të ngjarë, asgjë nuk u zhvendos.
Da-da.
Por nuk e kuptoj se si ta bëj ndryshe në mënyrë të besueshme.
Fatkeqësisht, nuk më kujtohet saktësisht nëse ne përdorim tekstin e pyetjes atje ose queryid me pg_stat_statements dhe përqendrohemi në të. Nëse fokusohemi në queryid, atëherë në teori po krahasojmë gjëra të krahasueshme.
Jo, ai mund të nxirret jashtë disa herë në mes të fotove dhe të kthehet përsëri.
Me të njëjtën ID?
Po.
Ne do ta studiojmë këtë. Pyetje e mirë. Duhet ta studiojmë. Por tani për tani, ajo që shohim është ose e shkruar 0...
Ky është, sigurisht, një rast i rrallë, por u trondita kur kuptova se stat_statemetns mund të zhvendosen atje.
Mund të ketë shumë gjëra në Pg_stat_statements. Ne hasëm në faktin se nëse keni track_utility = aktiv, atëherë edhe grupet tuaja gjurmohen.
Po sigurisht.
Dhe nëse keni hibernate java, e cila është e rastësishme, atëherë tabela e hash fillon të vendoset atje. Dhe sapo fikni një aplikacion shumë të ngarkuar, përfundoni me 50-100 grupe. Dhe gjithçka është pak a shumë e qëndrueshme atje. Një mënyrë për ta luftuar këtë është rritja e pg_stat_statements.max.
Po, por ju duhet të dini se sa. Dhe në një farë mënyre ne duhet ta mbajmë një sy mbi të. Kjo është ajo që unë bëj. Kjo është, unë kam pg_stat_statements.max. Dhe shoh që në momentin e fotografimit nuk kisha arritur në 70%. Në rregull, nuk kemi humbur asgjë. Le të rivendosim. Dhe ne kursejmë përsëri. Nëse fotografia tjetër është më pak se 70, atëherë ka shumë të ngjarë që nuk keni humbur asgjë përsëri.
Po. Parazgjedhja tani është 5. Dhe kjo është e mjaftueshme për shumë njerëz.
Zakonisht po.
Video:
PS Në emrin tim, do të shtoj se nëse Postgres përmban të dhëna konfidenciale dhe nuk mund të përfshihet në mjedisin e testimit, atëherë mund të përdorni . Skema është afërsisht si më poshtë:
Burimi: www.habr.com