Ju rendojë të njiheni me përmbledhjen e diskutimit të Nikolai Samokhvalovit "Qasja industriale në tuningun e PostgreSQL: eksperimente mbi bazat e të dhënave"
Shared_buffers = 25% â Ă«shtĂ« shumĂ« apo pak? Apo ndoshta Ă«shtĂ« perfekt? Si mund ta kuptoni nĂ«se kjo â njĂ« rekomandim mjaft i vjetĂ«r â i pĂ«rshtatet rastit tuaj konkret?
Ka ardhur koha të afrohemi me çështjen e përcaktimit të parametrave postgresql.conf "si të rritur". Jo me anë të "autotunerëve" të verbër apo këshillave të vjetra nga artikuj dhe blogje, por mbi bazën e:
- eksperimenteve të sakta mbi DB, të realizuara automatikisht, në numra të mëdhenj dhe në kushte sa më afër "luftës",
- njohjes së thellë të veçorive të funksionimit të DBMS dhe OS.
Duke pĂ«rdorur Nancy CLI (), ne do tĂ« shqyrtojmĂ« njĂ« shembull konkret â tĂ« famshmit shared_buffers â nĂ« situata tĂ« ndryshme, nĂ« projekte tĂ« ndryshme dhe do tĂ« pĂ«rpiqemi tĂ« kuptojmĂ« se si tĂ« pĂ«rcaktojmĂ« konfigurimin optimal pĂ«r infrastrukturĂ«n tonĂ«, DB dhe ngarkesĂ«n.
Do të flasim për eksperimente mbi bazat e të dhënave. Kjo është një histori që vazhdon për më shumë se gjashtë muaj.
Pak të dhëna për veten time. Kam mbi 14 vjet përvojë me Postgres. Kam themeluar disa kompani në rrjetet sociale. Kudo është përdorur dhe përdoret Postgres.
Gjithashtu, grupi RuPostgres në Meetup, vendi i dytë në botë. Po afrohemi ngadalë drejt 2000 personave. RuPostgres.org.
Dhe në shumë konferenca, duke përfshirë Highload, unë jam përgjegjës për bazat e të dhënave, veçanërisht Postgres që nga fillimi.
Dhe në vitet e fundit kam rinisur praktikën time të këshillimit për Postgres në 11 zona orare nga këtu.
Dhe kur e bëra këtë disa vite më parë, pata një ndalesë të dukshme në punën manuale me Postgres, ndoshta që nga viti 2010. U habitëm se sa pak kishin ndryshuar ditët e punës së DBA-ve, sa shumë punë manuale ende është e nevojshme. Dhe menjëherë mendova se diçka nuk shkon, duhet të automatizohet më shumë.
Dhe për shkak se kjo ndodhte kryesisht në distancë, shumica e klientëve ishin në cloud. Dhe tashmë shumë është automatizuar, kjo është e qartë. Për këtë do të flasim më vonë. Kjo do të thotë se gjithçka kyçej në një ide, që duhet të kemi një mori instrumentesh, pra një platformë, e cila do të automatizonte pothuajse të gjitha veprimet e DBA-ve, në mënyrë që të mund të menaxhonim një numër të madh bazash.
Në këtë diskutim nuk do të ketë:
- âFletĂ«t argjendiâ dhe deklarata si â vendosni 8 GB ose 25% shared_buffers dhe do t'ju shkojĂ« mirĂ«. PĂ«r shared_buffers nuk do tĂ« flitet shumĂ«.
- Hardcore âthellĂ«siâ.
Po çfarë do të ketë?
- Do të jenë parime optimizimi që ne i aplikojmë dhe i zhvillojmë. Do të jenë çdo lloj ideje që na lind në rrugë dhe një mori instrumentesh që krijojmë kryesisht në Open Source, pra ne krijojmë një bazë në Open Source. Për më tepër, kemi bileta, të gjithë komunikimi është praktikisht në Open Source. Mund të shihni se çfarë po bëjmë tani, çfarë do të jetë në versionin e ardhshëm, etj.
- Do të ketë gjithashtu disa përvoja mbi përdorimin e këtyre parimeve dhe këtyre instrumenteve në një sërë kompanish: nga fillestarë të vegjël deri tek kompani të mëdha.
Si zhvillohet gjithçka kjo?
Së pari, detyra kryesore e DBA-së përveç sigurisë së krijimit të instanceve, përhapjes së kopjeve të rezervës etj., është identifikimi i ngushticave dhe optimizimi i performancës.
Tani, kjo është strukturuar kështu. Ne shikojmë monitorimin, shohim diçka, na mungojnë disa detaje. Fillojmë të hetojmë më në thellësi, zakonisht me duar dhe kuptojmë se çfarë duhet të bëjmë kështu ose ashtu.
Dhe ka dy qasje. Pg_stat_statements â zgjidhja standarde pĂ«r identifikimin e kĂ«rkesave tĂ« ngadalta. Dhe analiza e logĂ«ve tĂ« Postgres me pgBadger.
Ădo qasje ka tĂ« meta tĂ« rĂ«nda. NĂ« qasjen e parĂ« ne hedhim tĂ« gjitha parametrat. Dhe nĂ«se ne shohim grupe SELECT * FROM table where kolona Ă«shtĂ« e barabartĂ« me simbolin "?" ose "$" qĂ« nga versione Postgres 10. Ne nuk e dimĂ« â bĂ«het fjalĂ« pĂ«r njĂ« skanim indeksi apo njĂ« skanim sekondar. VĂ«rtet varet shumĂ« nga parametri. NĂ«se shton njĂ« vlerĂ« tĂ« rrallĂ«, do tĂ« jetĂ« skanim indeksi. NĂ«se fut njĂ« vlerĂ« qĂ« pĂ«rfshin 90% tĂ« tabelĂ«s, do tĂ« jetĂ« skanim sekondar, sepse Postgres di statistikĂ«n. Dhe kjo Ă«shtĂ« njĂ« mangĂ«si e madhe e pg_stat_statements, megjithatĂ« disa punĂ« po zhvillohen.
Analiza e logëve ka mangësinë më të madhe që nuk mund të lejoni "log_min_duration_statement = 0", si rregull. Dhe për këtë do të flasim gjithashtu. Për këtë arsye, nuk e shihni tërë pamjen. Dhe një kërkesë që është shumë e shpejtë, mund të konsumojë një sasi të madhe burimesh, por ju nuk do ta shihni atë, sepse është nën pragun tuaj.
Si i zgjidhin DBA-të problemet e gjetura?
PĂ«r shembull, gjetĂ«m njĂ« problem. ĂfarĂ« bĂ«het zakonisht? NĂ«se jeni zhvillues, do tĂ« bĂ«ni diçka nĂ« ndonjĂ« instance qĂ« nuk Ă«shtĂ« aq i madh. NĂ«se jeni DBA, keni staging. Dhe ai mund tĂ« jetĂ« vetĂ«m njĂ«. Dhe Ă«shtĂ« pas me gjashtĂ« muaj. Dhe mendoni se do tĂ« shkoni nĂ« production. Edhe DBA tĂ« pĂ«rvojshĂ«m kontrollojnĂ« pastaj nĂ« production, nĂ« replikĂ«. Dhe ndonjĂ«herĂ« krijojnĂ« njĂ« indeks tĂ« pĂ«rkohshĂ«m, e kontrollojnĂ« nĂ«se ndihmon, e heqin dhe ia dorĂ«zojnĂ« zhvilluesve pĂ«r ta futur nĂ« skedarĂ«t e migrimit. Kjo Ă«shtĂ« çfarĂ« po ndodh tani. Dhe kjo Ă«shtĂ« e keqe.
- TĂ« optimizoni konfigurimet.
- TĂ« optimizoni grupin e indekseve.
- Të ndryshoni krijimin e SQL (kjo është mënyra më e vështirë).
- Të shtoni kapacitet (mënyra më e lehtë në shumicën e rasteve).
Me këto gjëra ka shumë për të bërë. Ka shumë mundësi në Postgres. Duhet të dini shumë. Ka shumë indekse në Postgres, falë organizatorëve të kësaj konference. Dhe të gjitha këto duhet të dihen, dhe pikërisht kjo i jep ndjesinë atyre që nuk janë DBA se ata merren me magji të zezë. Pra, duhet të kaloni rreth 10 vjet për të filluar të kuptoni të gjitha këto siç duhet.
Dhe unë jam luftëtar kundër kësaj magjie të zezë. Dua të bëj gjithçka në mënyrë që të ketë teknologji, e jo intuitë në të gjitha këto.
Shembuj nga jeta
KĂ«tĂ« e kam vĂ«zhguar nĂ« tĂ« paktĂ«n dy projekte, pĂ«rfshirĂ« tĂ« mien. NjĂ« postim i ri nĂ« blog na tregon se vlera 1 000 pĂ«r default_statistict_target â Ă«shtĂ« e mirĂ«. MirĂ«, le tĂ« provojmĂ« nĂ« production.
Dhe këtu ne, duke përdorur mjetin tonë dy vjet më vonë me eksperimente mbi bazat e të dhënave për të cilat po flasim sot, mund të krahasojmë çfarë ka qenë dhe çfarë është bërë.
Dhe për këtë na nevojitet të krijojmë një eksperiment. Ai përbëhet nga katër pjesë.
- E para â Ă«shtĂ« mjedisi. Na nevojitet harduer. Dhe kur shkoj nĂ« ndonjĂ« kompani dhe lidh njĂ« kontratĂ«, unĂ« them qĂ« tĂ« mĂ« japin harduerin e njĂ«jtĂ« si nĂ« production. PĂ«r secilin nga Master-at tuaja, mĂ« nevojitet tĂ« paktĂ«n njĂ« harduer i tillĂ«. QoftĂ« kjo njĂ« makinĂ« virtuale instance nĂ« Amazon ose nĂ« Google, ose mĂ« nevojitet pikĂ«risht njĂ« harduer i njĂ«jtĂ«. Pra, dua ta riprodhoj mjedisin. Dhe nĂ« konceptin e mjedisit 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Ă«, pra çfarĂ« do tĂ« krahasojmĂ«. Le tĂ« themi, mund tĂ« ndryshojmĂ« njĂ« ose disa parametra nĂ« konfigurim, ose mund tĂ« krijojmĂ« njĂ« indeks dhe kĂ«shtu me radhĂ«.
Ne fillojmĂ« eksperimentin. Ja pg_stat_statements. Nga e majta â ajo qĂ« ishte. Nga e djathta â sidomos si Ă«shtĂ« bĂ«rĂ«.
Nga e majta default_statistics_target = 100, nga e djathta = 1 000. Shohim se na ndihmoi. Në 8% gjithçka është përmirësuar.
Por nëse rrokullisim poshtë, do të ketë grupe kërkesash nga pgBadger ose nga pg_stat_statements. Këtu ka dy variante. Ne do të shohim që ndonjë kërkesë ka rënë me 88%. Dhe këtu është një qasje inxhinierike. Ne mund të thellojmë më tej, sepse na intereson, pse ra. Duhet të kuptojmë se çfarë ndodhi me statistikën. Pse më shumë bakete në statistikë çojnë në një rezultat më të keq.
Ose mund të mos thellohemi, por të bëjmë "ALTER TABLE ⊠ALTER COLUMN" dhe t'i kthejmë sërish 100 bakete në statistikën e kësaj kolone. Dhe më tej, me një eksperiment, ne mund të sigurohemi se kjo zgjidhje ndihmoi. Kjo është qasje inxhinierike, që na ndihmon të shohim imazhin dhe të marrim vendime mbi të dhëna, dhe jo mbi intuitë.
Pak shembuj nga fusha të tjera. Në testime ka CI-testime për shumë vite. Dhe asnjë projekt tashmë në mendjen e shëndoshë nuk do të ekzistojë pa teste automatike.
Në fusha të tjera: në aviacion, në automobilizëm, kur testojmë aerodinamikën, ne gjithashtu kemi mundësinë të bëjmë eksperimente. Nuk do të hedhim ndonjë gjë të hartuar menjëherë në hapësirë ose nuk do të nxjerrim ndonjë makinë menjëherë në rrugë. Për shembull, ka një tunel aerodinamik.
Nga vëzhgimet në fusha të tjera, ne mund të nxjerrim përfundime.
Së pari, kemi një mjedis të specializuar. Ai është afër production, por nuk është afër. Karakteristika kryesore është se duhet të jetë i lirë, i riprodhueshëm dhe maksimalisht i automatizuar. Dhe gjithashtu duhet të kemi mjete speciale për një analizë të detajuar.
Shumë mundësi, kur hedhim avionin dhe flasim, në kemi më pak mundësi për të studiuar çdo milimetër të sipërfaqes së krahut, sesa kemi në tunelin aerodinamik. Ne kemi më shumë mjete për diagnostikim. Mund të lejojmë veten të vendosim më shumë peshë, që nuk mund ta vendosim në avion ndërsa fluturojmë. Po ashtu edhe me Postgres. Në disa raste, mund të aktivizojmë regjistrimin e plotë të kërkesave gjatë eksperimenteve. Dhe ne nuk duam ta bëjmë këtë në production. Ndoshta madje këtë do ta aktivizojmë me planet duke përdorur auto_explain.
Dhe siç thashë, niveli i lartë i automatizimit do të thotë që ne e shtypëm butonin dhe e kemi përsëritur. Kështu duhet të jetë që të ketë shumë eksperimente, që të jetë në fluks.
Nancy CLI â baza e "laboratorit tĂ« DB"
Dhe ja çfarë kemi bërë. Domethënë, për këto ide kam folur në qershor, gati një vit më parë. Dhe ne tashmë kemi në Open Source atë që quhet Nancy CLI. Ky është themeli për ndërtimin e laboratorit të bazës së të dhënave.
â Kjo Ă«shtĂ« nĂ« Open Source, nĂ« Gitlab. Mund ta shikoni, mund ta provoni. Kam lĂ«nĂ« njĂ« lidhje nĂ« slidet. Mund tĂ« klikoni dhe atje do tĂ« jetĂ« pĂ«r tĂ« gjitha parametrat.
Sigurisht, aty ka shumĂ« qĂ« janĂ« ende nĂ« zhvillim. Ka shumĂ« ide. Por kjo Ă«shtĂ« diçka qĂ« ne e aplikojmĂ« nĂ« pĂ«rditshmĂ«ri. Dhe kur na vjen njĂ« ide â a çfarĂ« ndodh kur fshihet 40 000 000 rreshta dhe gjithçka pĂ«rfundon nĂ« IO, ne mund tĂ« kryejmĂ« njĂ« eksperiment dhe tĂ« shohim mĂ« nĂ« detaje, pĂ«r tĂ« kuptuar çfarĂ« po ndodh dhe pastaj tĂ« pĂ«rpiqemi ta rregullojmĂ« atĂ« nĂ« moment. DomethĂ«nĂ«, ne bĂ«jmĂ« njĂ« eksperiment. PĂ«r shembull, ndryshojmĂ« diçka dhe shohim çfarĂ« rezultati merrim. Dhe ne e bĂ«jmĂ« kĂ«tĂ« jo nĂ« prodhim. Kjo Ă«shtĂ« thelbi i ideve.
Ku mund të funksionojë kjo? Mund të funksionojë lokalisht, domethënë mund ta bëni kudo, mund ta nisni edhe në MacBook. Duhet Docker, le të nisim. Dhe gjithë kjo. Mund ta nisim në ndonjë instancë në harduer, ose në një makinë virtuale, kudo.
Dhe ka gjithashtu mundĂ«sinĂ« pĂ«r ta nisur nga larg nĂ« Amazon nĂ« EC2 Instance, nĂ« spot. Dhe kjo Ă«shtĂ« njĂ« mundĂ«si shumĂ« e shkĂ«lqyer. PĂ«r shembull, dje ne kryem mbi 500 eksperimentet nĂ« instancĂ«n i3, duke filluar nga mĂ« e vogla dhe duke pĂ«rfunduar me i3-16-xlarge. Dhe na kushtuan 500 eksperimente 64 dollarĂ«. Ădo njĂ«ra zgjati 15 minuta. DomethĂ«nĂ«, pĂ«r shkak se aty pĂ«rdoren spotet, kjo Ă«shtĂ« shumĂ« e lirĂ« â zbritje 70%, tarifimi pĂ«r sekondĂ« nga Amazon. Mund tĂ« bĂ«ni shumĂ«. Mund tĂ« kryeni njĂ« studim tĂ« vĂ«rtetĂ«.
Dhe tri versione kryesore të Postgres mbështeten. Nuk është aq e vështirë të përshtatni disa të vjetra dhe versionin e ri 12 gjithashtu.
Objektin mund ta përcaktojmë në tri mënyra. Këto janë:
- Dump/sql-file.
- MĂ«nyra kryesore â Ă«shtĂ« kloni i drejtorisĂ« PGDATA. NĂ« pĂ«rgjithĂ«si merret nga serveri i backup-it. NĂ«se keni backup-e binarĂ« tĂ« mira, mund tĂ« bĂ«ni klona atje. NĂ«se keni cloud, atĂ«herĂ« kjo do tĂ« bĂ«het nga kompania cloud si Amazon ose Google. Kjo Ă«shtĂ« mĂ«nyra kryesore pĂ«r klonat e prodhimit real. NĂ« kĂ«tĂ« mĂ«nyrĂ« ne po e zbatojmĂ«.
- Dhe mënyra e fundit është e përshtatshme për hulumtime, kur dëshirojmë të kuptojmë se si funksionon diçka në Postgres. Kjo është pgbench. Mund të gjeneroni me ndihmën e pgbench. Kjo është thjesht një zgjedhje "db-pgbench". I thoni atij se çfarë shkalle. Dhe gjithçka do të gjenerohet në cloud, siç thuhet.
Dhe ngarkesa:
- Ngarkesën mund ta ekzekutojmë në një rrjedhë SQL. Kjo është mënyra më primitive.
- Ose mund të emulojmë ngarkesën. Dhe emulimi mund të bëhet kryesisht në këtë mënyrë. Duhet të mbledhim të gjitha log-et. Dhe kjo është e dhimbshme. Do të tregoj pse. Dhe me ndihmën e pgreplay, që është i integruar në Nancy.
- Ose një alternativë tjetër. E ashtuquajtura ngarkesë artizanal, që ne e bëjmë me disa përpjekje. Duke analizuar ngarkesën tonë aktuale në sistemin aktiv, ne tërheqim grupet kryesore të kërkesave. Dhe me ndihmën e pgbench mund të emulojmë këtë ngarkesë në laborator.
- Ose ndoshta duam të ekzekutojmë ndonjë SQL, domethënë kontrollojmë migrimin, krijojmë një indeks, përfundojmë një ANALAZE. Dhe shohim çfarë ndodhi para dhe pas vakuumit. Në përgjithësi, çdo SQL.
- Ose ne në konfigurim ndryshojmë një ose disa parametra. Mund të themi që të kontrollojmë, për shembull, 100 vlera në Amazon për bazën tonë një terabajt. Dhe pas disa orësh do të keni rezultatin. Në përgjithësi, baza e të dhënave një terabajt do të zgjerohet për disa orë. Por në zhvillim ka njollë, kemi mundësi serike, domethënë mund të përdorni rendin e njëjtë të pgdata në të njëjtin server dhe të kontrolloni. Postgres do të rindezë, cache-et do të fshihen. Dhe mund të provoni ngarkesën.
- Vjen njĂ« direktorĂ«, nĂ« tĂ« cilĂ«n ka shumĂ« skedarĂ«, duke filluar nga snapshot-et pgstat***. Dhe aty mĂ« e rĂ«ndĂ«sishmja â janĂ« 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 informacion pĂ«r checkpoint dhe si backend-at vetĂ« shtyjnĂ« buferat e ndotura. Dhe gjithçka Ă«shtĂ« interesante pĂ«r t'u parĂ«. PĂ«r shembull, kur e konfiguroni shared_buffers, Ă«shtĂ« shumĂ« interesante tĂ« shihni sa shumĂ« janĂ« kaluar.
- Po ashtu vijnĂ« log-et e Postgres. Dy log-e â log-u i pĂ«rgatitjes dhe log-u i ekzekutimit tĂ« ngarkesĂ«s.
- Tipar relativisht i ri â janĂ« FlameGraphs.
- Po të njëjtën mënyrë, nëse keni përdorur pgreplay ose pgbench opsionet e ngarkesës, do të keni daljen e tyre natyrale. Dhe do të shihni latencën dhe TPS-in. Do t'ju ndihmojë të kuptoni si i kanë parë ato.
- Informacion në lidhje me sistemin.
- Kontrolli bazik i CPU-së dhe IO. Kjo është më shumë për instancat EC2 në Amazon, kur dëshironi të ekzekutoni 100 instanca të njëjta dhe të ekzekutoni 100 teste të ndryshme, do të keni 10,000 eksperimente. Dhe duhet të siguroheni që të mos përfshiheni me një instancë të dëmtuar që dikush tjetër e ka shkarkuar. Në këtë pajisje, të tjerë janë aktivizuar dhe juve ju mbetet pak burim. Të tilla rezultate është më mirë t'i hidhni poshtë. Dhe pikërisht me ndihmën e sysbench nga Aleksei Kopytov, realizojmë disa kontrole të shkurtra, të cilat vijnë dhe mund të krahasohen me të tjerët, pra do të kuptoni si sillet CPU dhe si sillet IO.
ĂfarĂ« Ă«shtĂ« e komplikuar teknikisht pĂ«rmes shembujve tĂ« ndryshĂ«m tĂ« kompanive?
Supozoni se dëshirojmë të ripërsërisim ngarkesën reale me ndihmën e skedarëve të log. Një ide e shkëlqyer nëse është shkruar në Open Source pgreplay. Ne e përdorim. Por, për të punuar mirë, duhet të aktivizoni regjistrimin e plotë të kërkesave me parametra dhe kohë.
Ka disa vĂ«shtirĂ«si sa i pĂ«rket kohĂ«zgjatjes dhe timestamp-eve. Ne do ta lemĂ« kĂ«tĂ« pĂ«r momentin. Pyetja kryesore Ă«shtĂ« â a mund ta lejoni kĂ«tĂ« apo jo?
Problemi është se kjo mund të mos jetë e disponueshme. Duhet të kuptoni së pari se çfarë lloj fluksi do të shkruhet në log. Nëse keni pg_stat_statements, mund të përdorni këtë pyetje (linku do të jetë i disponueshëm në slidet) për të kuptuar se sa shumë byte do të shkruhen për sekondë.
Shikojmë në gjatësi të pyetjes. Në këtë rast injorojmë faktin se nuk ka parametra, por e dimë gjatësi e pyetjes dhe e dimë sa herë për sekondë ajo është ekzekutuar. Kështu, mund të bëjmë një vlerësim se sa byte do të shkruhet për sekondë. Mund të gabojmë dy herë, por rendi do ta kuptojmë me siguri në këtë mënyrë.
Mund tĂ« shohim qĂ« kjo pyetje ekzekutohet 802 herĂ« nĂ« sekondĂ«. Dhe shohim se bytes_per sec â 300 kB/s do tĂ« shkruhen plus minus. Dhe, zakonisht, ne mund ta lejojmĂ« njĂ« fluks tĂ« tillĂ«.
Por! Problemi është se ka sisteme të ndryshme regjistrimi. Dhe, në përgjithësi, njerëzit zakonisht kanë «syslog».
Dhe nëse keni syslog, mund të ndodheni me një pamje të tillë. Do të marrim pgbench, do të aktivizojmë regjistrimin e kërkesave dhe do të shikojmë se çfarë ndodh.
Pa regjistrim â ky Ă«shtĂ« kolona e majtĂ«. Ne kishim 161,000 TPS. Me syslog â kjo nĂ« Ubuntu 16.04 nĂ« Amazon rezulton 37,000 TPS. Dhe nĂ«se ne ndryshojmĂ« nĂ« dy metoda tĂ« tjera regjistrimi, situata Ă«shtĂ« shumĂ« mĂ« e mirĂ«. Pra, prisnim qĂ« do tĂ« bjerĂ«, por jo kaq shumĂ«.
Ndërsa në CentOS 7, ku merr pjesë edhe journald, regjistrimi i logeve në formatin binar për kërkime më të lehta, atje ndodh një situatë katastrofike, me 44 herë rënie në TPS.
Dhe kjo është diçka me të cilën përballen njerëzit. Dhe shpesh në kompanitë, veçanërisht në ato të mëdha, është shumë e vështirë të ndryshohet diçka. nëse mund të largoheni nga syslog, atëherë shkoni.
- Vlerësoni IOPS-in dhe fluksin e shkrimit.
- Kontrolloni sistemin tuaj të regjistrimit.
- Nëse ngarkesa e parashikuar është tepër e lartë, konsideroni mundësinë e kampionimit.
Ne kemi pg_stat_statements. Siç thashĂ«, ai duhet tĂ« jetĂ« patjetĂ«r. Dhe mund tĂ« marrim dhe tĂ« pĂ«rshkruajmĂ« çdo grup kĂ«rkesash nĂ« njĂ« skedar tĂ« veçantĂ«. Pastaj mund tĂ« pĂ«rdorim njĂ« veçori shumĂ« tĂ« rehatshme nĂ« pgbench â mundĂ«sinĂ« pĂ«r tĂ« futur disa skedare pĂ«rmes opsionit «-f».
Ai kupton shumë «-f». Dhe mund të themi me ndihmën e «@» në fund, se cila është përqindja për secilin skedar. Pra, mund të themi se ky do të ekzekutohet në 10% të rasteve, ndërsa ky në 20%. Dhe kjo do të na afrojë më afër asaj që shohim në prodhim.
Si do të kuptojmë se çfarë ka në prodhim? Cila është përqindja dhe çfarë? Këtu pak dalim nga tema. Kemi edhe një produkt tjetër . Gjithashtu një bazë në Open Source. Dhe ne tani po e zhvillojmë me përkushtim.
Ai lindi pĂ«r disa arsye tĂ« tjera. PĂ«r shkak tĂ« faktit qĂ« monitorimi Ă«shtĂ« i pamjaftueshĂ«m. Pra, ju erdhni, shikoni bazĂ«n, shikoni problemet qĂ« ka. Dhe, nĂ« pĂ«rgjithĂ«si, ju bĂ«ni njĂ« kontrolle shĂ«ndeti. NĂ«se jeni njĂ« DBA me pĂ«rvojĂ«, ju bĂ«ni njĂ« kontroll shĂ«ndeti. Shikoni pĂ«rdorimin e indekseve, etj. NĂ«se keni OKmeter, atĂ«herĂ« shkĂ«lqyer. Ky Ă«shtĂ« njĂ« monitorim fantastik pĂ«r Postgres. OKmeter.io â ju lutemi, installoni atĂ«, gjithçka Ă«shtĂ« bĂ«rĂ« shumĂ« mirĂ« atje. Ai Ă«shtĂ« me pagesĂ«.
Nëse nuk e keni, zakonisht nuk keni shumë. Në monitorim zakonisht kemi CPU, IO dhe këtë me kusht, dhe asgjë më shumë. Por na nevojitet më shumë. Na nevojitet të shohim si funksionon avtokorrigjimi, si funksionon pikënisja, në io duhet të ndahen pikënisja nga bgwriter dhe nga backend-et etj.
Problemi është se kur ndihmon një kompani të madhe, ata nuk mund të implementojnë diçka shpejt. Nuk mund të blejnë shpejt OKmeter-in. Mbase do ta blejnë pas gjashtë muajsh. Nuk mund të instalohet ndonjë paketë shpejt.
Na kemi erdhi ideja se na nevojitet një mjet i veçantë, i cili nuk kërkon ndonjë instalim, pra nuk keni nevojë të instaloni asgjë në prodhim. E vendosni në laptopin tuaj, ose në serverin e vëzhgimit, nga ku do ta lanconi. Dhe ai do të analizojë shumë gjëra: sistemin operativ, sistemin e skedarëve, dhe vetë Postgres, duke bërë disa kërkesa të lehta, të cilat mund t'i dërgoni direkt në prodhim dhe asgjë nuk do të dështojë.
Ne e quajtam atë Postgres-checkup. Nëse flasim në terma mjekësorë, kjo është një kontroll i rregullt i shëndetit. Nëse e shohim nga perspektiva automobilistike, kjo është si një kontroll teknik. Ju bëni kontrollin teknik për makinën tuaj çdo gjashtë muaj apo një herë në vit, në varësi të markës. Po, a bëni kontroll teknik për bazën tuaj? Kjo është, a bëni kërkime të thella rregullisht? Kjo është e nevojshme. Nëse bëni backup, atëherë bëni edhe një kontroll, kjo është po aq e rëndësishme.
Dhe ne kemi një mjet të tillë. Ai ka filluar të zhvillohet aktivisht vetëm për tre muaj. Ai është ende i ri, por ka shumë funksionalitete.
Mblidhni grupet më "të influencueshme" të kërkesave - raporti K003 në Postgres-checkup.
Dhe aty ka një grup raportesh K. Një grup raportesh të tillë. Tani ka tre raporte. Dhe ka një raport të tillë K003. Aty është maja nga pg_stat_statements, e renditur sipas total_time.
Kur ne rendisim sipas total_time grupet e kërkesave, ne shohim një grup në krye, i cili ngarkon sistemin tonë më së shumti, pra konsumon më shumë burime. Pse e quaj grupet e kërkesave? Sepse ne e kemi hequr parametrin. Këto nuk janë më kërkesa, por grupe kërkesash, pra ato janë të abastraktuara.
Dhe nëse ne do të optimizojmë nga lart poshtë, do t'i lehtësojmë burimet tona dhe do ta shtyjmë momentin kur na duhen përmirësime. Ky është një mënyrë e shkëlqyer për të kursyer para.
Mund të mos jetë mënyra më e mirë për të kujdesur për përdoruesit, sepse ndoshta ne nuk i shohim rastet e rralla, por shumë të bezdisshme, kur dikush pret 15 sekonda. Në total ato janë aq të rralla sa që ne nuk i shohim, por ne jemi duke u marrë me burimet.
ĂfarĂ« ndodhi nĂ« kĂ«tĂ« tabelĂ«? BĂ«mĂ« dy snapshot-e. Postgres_checkup do t'ju bĂ«jĂ« diferencĂ«n pĂ«r çdo metrikĂ«: pĂ«r total-time, calls, rows, shared_blks_read, etj. E gjitha, diferenca Ă«shtĂ« llogaritur. NjĂ« problem i madh me pg_stat_statements Ă«shtĂ« se ai nuk mban mend kur u resetua. NĂ«se pg_stat_database mban mend, pg_stat_statements nuk mban mend. Ju shihni atje numrin 1,000,000, por nuk e dimĂ« se nga e kemi llogaritur.
Por këtu ne e dimë, këtu kemi dy snapshot-e. Ne e dimë që diferenca ka qenë në këtë rast 56 sekonda. Një interval shumë i vogël. E renditëm sipas total_time. Dhe më pas mund të diferencojmë, pra ne i ndajmë të gjitha metrikat sipas kohës së gjatë. Nëse ne e ndajmë secilën metrikë me kohën e gjatë, 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Ă«, pra sa sekonda iu desh sistemit tonĂ« pĂ«r tĂ« ekzekutuar kĂ«tĂ« grup kĂ«rkesash nĂ« sekondĂ«. NĂ«se ju shihni atje mĂ« shumĂ« se njĂ« sekondĂ« nĂ« sekondĂ«, kjo do tĂ« thotĂ« se ju kishit nevojĂ« pĂ«r mĂ« shumĂ« se njĂ« bĂ«rthamĂ«. Kjo Ă«shtĂ« njĂ« metrikĂ« shumĂ« e mirĂ«. Ju mund tĂ« kuptoni se ky person, pĂ«r shembull, ka nevojĂ« pĂ«r tĂ« paktĂ«n tre bĂ«rthama.
Kjo Ă«shtĂ« noviteti ynĂ«, nuk kam parĂ« asnjĂ«herĂ« diçka tĂ« tillĂ«. VĂ«reni â kjo Ă«shtĂ« diçka shumĂ« e thjeshtĂ« â sekonda nĂ« sekondĂ«. N sometimes, kur CPU Ă«shtĂ« 100 %, ju keni gjysmĂ« ore nĂ« sekondĂ«, pra ju keni kaluar gjysmĂ« ore vetĂ«m me kĂ«to kĂ«rkesa.
Më pas shohim rreshta në sekondë. Ne e dimë se sa rreshta janë kthyer në sekondë.
Dhe më pas është gjithashtu diçka interesante. Sa shared_buffers kemi lexuar në sekondë nga shared_buffers. Goditjet tashmë ishin atje, ndërsa rreshtat i morëm nga memorieja e sistemit operativ, ose nga disku. Opcioni i parë është i shpejtë, ndërsa i dyti, ndoshta është i shpejtë, ndoshta jo, varet nga situata.
Dhe mĂ«nyra e dytĂ« e diferencimit â ne ndajmĂ« numrin e kĂ«rkesave nĂ« kĂ«tĂ« grup. NĂ« kolonĂ«n e dytĂ« gjithmonĂ« do tĂ« keni njĂ« kĂ«rkesĂ« pĂ«r tĂ« ndarĂ« me kĂ«rkesĂ«n. Dhe mĂ« pas Ă«shtĂ« interesante â sa milisekonda ishte nĂ« kĂ«tĂ« kĂ«rkesĂ«. Ne e dimĂ« se si sillet mesatarisht kjo kĂ«rkesĂ«. 101 milisekonda nevojiteshin pĂ«r çdo kĂ«rkesĂ«. Kjo Ă«shtĂ« njĂ« metrikĂ« tradicionale qĂ« na nevojitet pĂ«r kuptimin.
Sa rreshta ktheu çdo kërkesë në mesatare. Ne shohim se grupi kthen 8. Sa mesatarisht mori dhe lexoi nga cache. Ne shohim se gjithçka është e ruajtur në memory. Goditje të përgjithshme për grupin e parë.
Dhe substrati i katĂ«rt nĂ« çdo rresht â Ă«shtĂ« pĂ«rqindja e pĂ«rgjithshme. Ne kemi thirrje. Le ta themi, nĂ« 1,000,000. Dhe ne mund tĂ« kuptojmĂ« se çfarĂ« kontributi sjell ky grup. Ne shohim se nĂ« kĂ«tĂ« rast grupi i parĂ« kontribuon mĂ« pak se 0,01%. Kjo Ă«shtĂ«, ajo Ă«shtĂ« kaq e ngadalshme sa qĂ« ne nuk e shohim nĂ« pamjen e pĂ«rgjithshme. NdĂ«rsa grupi i dytĂ« â 5% nga thirrjet. Kjo Ă«shtĂ«, 5% e tĂ« gjitha thirrjeve janĂ« nga grupi i dytĂ«.
ĂshtĂ« gjithashtu interesante pĂ«r total_time. PĂ«r grupin e parĂ« tĂ« kĂ«rkesave, harxhuam 14% tĂ« gjithĂ« kohĂ«s sĂ« punĂ«s. NdĂ«rsa pĂ«r tĂ« dytin â 11% etj.
Nuk do të hyj në detaje, por aty ka nuanca. Ne nxjerrim një gabim në sipërfaqe, sepse kur krahasojmë, snapshotet mund të lëkunden, dmth disa kërkesa mund të humbasin dhe në të dytin nuk mund të jenë më të pranishme, ndërsa disa mund të shfaqen të reja. Dhe aty ne llogarisim gabimin. Nëse shihni 0, atëherë është mirë. Nuk ka gabime. Nëse treguesi i gabimeve është deri në 20%, është OK.
Më pas kthehemi në temën tonë. Ne duhet të konceptojmë workload. Shkojmë nga lart poshtë derisa të mbledhim 80% ose 90%. Zakonisht kjo është 10-20 grupe. Dhe bëmë skedarët për pgbench. Atje përdorim random. Ndonjëherë, për fat të keq, kjo nuk funksionon. Dhe në Postgres 12 do të ketë më shumë mundësi për të përdorur këtë qasje.
MĂ« pas kĂ«shtu ne mbledhim 80-90% nĂ« total_time. ĂfarĂ« tĂ« vendosim mĂ« pas pas «@»? Ne shohim thirrjet, shohim sa pĂ«rqindje dhe kuptojmĂ« se kĂ«tu duhet tĂ« kemi kaq pĂ«rqindje. Nga kĂ«to pĂ«rqindje ne mund tĂ« kuptojmĂ« se si tĂ« balancojmĂ« secilin nga skedarĂ«t. Pas kĂ«saj ne pĂ«rdorim pgbench dhe fillojmĂ« tĂ« punojmĂ«.
Ka gjithashtu K001 dhe K002.
K001 â Ă«shtĂ« njĂ« varg i madh me katĂ«r nĂ«nvargje. Kjo Ă«shtĂ« karakteristika e gjithĂ« ngarkesĂ«s sonĂ«. Shihni kolonĂ«n e dytĂ« dhe nĂ«nvargun e dytĂ«. Ne shohim se rreth njĂ« sekond nĂ« sekondĂ«, dmth nĂ«se do tĂ« ketĂ« dy bĂ«rthama, do tĂ« jetĂ« mirĂ«. Do tĂ« ketĂ« rreth 75% ngarkesĂ«. Dhe kĂ«shtu do tĂ« funksionojĂ«. NĂ«se kemi 10 bĂ«rthama, do tĂ« jemi plotĂ«sisht tĂ« qetĂ«. KĂ«shtu mund tĂ« vlerĂ«sojmĂ« burimet.
K002 â kĂ«to i quaj klasat e kĂ«rkesave, dmth SELECT, INSERT, UPDATE, DELETE. Dhe veçmas SELECT FOR UPDATE, sepse ai bllokon.
Dhe kĂ«tu mund tĂ« pĂ«rfundojmĂ« se SELECT tĂ« zakonshmet lexuese â 82% e tĂ« gjitha thirrjeve, por nĂ« tĂ« njĂ«jtĂ«n kohĂ« â 74% nĂ« total_time. Pra, ato thirren shpesh, por konsumojnĂ« mĂ« pak burime.
Dhe kthehemi nĂ« pyetjen: «Si tĂ« pĂ«rshtatim saktĂ«sisht shared_buffers?». VĂ«rej qĂ« shumica e benchmarking-ve janĂ« ndĂ«rtuar mbi idenĂ« â le tĂ« shohim se cili do tĂ« jetĂ« throughput, dmth cili do tĂ« jetĂ« kapaciteti. Ajo zakonisht matet nĂ« TPS ose QPS.
Dhe ne mundohemi të nxjerrim sa më shumë transaksione në sekondë nga makina me parametrat e tuningut. Këtu saktësisht 311 në sekondë për select.
Por askush nuk shkon në punë dhe për të rikthyer shtëpinë me makinë me shpejtësi maksimale. Kjo është e budallallëk. Ashtu është dhe me bazat e të dhënave. Ne nuk duhet të ecim me shpejtësi maksimale, askush nuk e bën këtë. Askush nuk jeton në production që ka 100% CPU. Megjithatë, ndoshta dikush jeton, por kjo nuk është e mirë.
Ideja është që zakonisht ne ecim në 20% të mundësive, preferohet të mos kalojmë 50%. Dhe ne mundohemi të optimizojmë kohën e përgjigjes për përdoruesit tanë, së pari. Pra, duhet të manovrojmë dorët tona për të pasur latency minimale në 20% shpejtësi, në parim. Kjo është një ide që ne gjithashtu mundohemi ta përdorim në eksperimentet tona.
Dhe në përfundim, rekomandimet:
- Sigurisht, bëni Database Lab.
- Sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur, bĂ«ni on demand, qĂ« tĂ« krijohet pĂ«r njĂ« periudhĂ« â luani dhe pastaj hidhni. NĂ«se keni nĂ« oblake, kjo Ă«shtĂ« e natyrshme, dmth, keni shumĂ« standing.
- Jini kureshtarë. Dhe nëse diçka nuk shkon, kontrolloni me eksperimente se si sillet. Nancy mund të jetë përdorur për të mësuar veten, për të verifikuar si funksionon baza.
- Dhe qëndroni të fokusuar në kohën minimale të përgjigjes.
- Dhe mos kini frikë nga burimet e Postgres. Kur punoni me burimet, duhet të dini anglisht. Atje ka shumë komente, gjithçka është shpjeguar.
- Dhe kontrolloni shëndetin e bazës rregullisht, të paktën një herë në tre muaj me duar, ose Postgres-checkup.
Pyetje
Faleminderit shumë! Një gjë shumë interesante.
Dy gjëra.
Po, dy gjëra. Por unë nuk e kuptova plotësisht. Kur punojmë me Nancy, a mund të rregullojmë vetëm një parameter apo një grup të tërë?
Ne kemi parameterin e dëlta-konfigurimit. Mund të sjellësh sa më shumë të duash njëherësh. Por duhet të kuptosh, kur ndryshon shumë gjëra, mund të jesh në një përfundim të gabuar.
Po. Pse e pyeta? Sepse është e vështirë të kryesh eksperimente kur ke vetëm një parameter. E rregullon atë, e ke parë si punon. E vendos atë. Pastaj fillon me tjetrin.
Mund të rregullohen njëherësh, por varet nga situata, natyrisht. Por më mirë është të kontrollosh një ide. Dje na erdhi një ide. Kemi patur një situatë shumë të ngjashme. Kishim dy konfigurime. Dhe nuk mund të kuptonim pse kishte një diferencë të madhe. Dhe erdhi ideja që të përdorim dykahësinë, për të kuptuar në radhë dhe për të gjetur se çfarë është ndryshe. Mund të bëjmë menjëherë gjysmën e parametrave të njëjtë, pastaj një të katërtin, etj. Të gjitha fleksibel.
Dhe ka një pyetje tjetër. Projekti është i ri, në zhvillim. Dokumentacioni është tashmë i gatshëm, ka një përshkrim të detajuar?
E kam bĂ«rĂ« lidhjen nĂ« pĂ«rshkrimin e parametrave. Kjo Ă«shtĂ« aty. Por ka shumĂ« gjĂ«ra qĂ« akoma mungojnĂ«. Po kĂ«rkoj njerĂ«z tĂ« ngjashĂ«m. I gjej kur kam paraqitje. Kjo Ă«shtĂ« shumĂ« e mrekullueshme. Disa tashmĂ« po punojnĂ« me mua, disa ndihmuan dhe bĂ«nĂ« diçka. Dhe nĂ«se jeni tĂ« interesuar pĂ«r kĂ«tĂ« temĂ«, lutem jepni komentet tuaja â çfarĂ« mungon.
Kur të realizojmë laboratorin, ndoshta do të kemi përgjigje. Do ta shohim. Faleminderit!
Përshëndetje! Faleminderit për prezantimin! Vura re që ka mbështetje për Amazon. A është planifikuar mbështetje për GSP?
NjĂ« pyetje e mirĂ«. Kemi filluar punĂ«n. Dhe pĂ«r momentin e kemi pezulluar, sepse duam tĂ« kursejmĂ«. Pra, ka mbĂ«shtetje pĂ«rmes run on localhost. Ju mund tĂ« krijoni vetĂ« njĂ« instance dhe tĂ« punoni lokal. PĂ«r mĂ« tepĂ«r, ne ashtu e bĂ«jmĂ«. NĂ« Getlab e bĂ«j kĂ«shtu, atje nĂ« GSP. Por pĂ«r tĂ« realizuar njĂ« orkestrim tĂ« tillĂ« nuk shohim ende sens, sepse Google nuk ka oferta tĂ« lira. Aty ka ??? instances, por ato kanĂ« kufizime. SĂ« pari, ata gjithmonĂ« kanĂ« vetĂ«m 70% zbritje dhe nuk mund tĂ« luani me çmimin. Ne rrisim çmimin e spoteve me 5-10% pĂ«r tĂ« ulur probabilitetin qĂ« t'ju nxjerrin jashtĂ«. DomethĂ«nĂ«, me spote ju kurseni, por mund t'ju marrin nĂ« çdo moment. NĂ«se vendosni njĂ« çmim pak mĂ« tĂ« lartĂ« se tĂ« tjerĂ«t, mund t'ju vrasin mĂ« vonĂ«. Google ka njĂ« specifik tjetĂ«r krejtĂ«sisht. Dhe ka njĂ« kufizim qĂ« nuk Ă«shtĂ« i mirĂ« â ata jetojnĂ« vetĂ«m 24 orĂ«. E ndonjĂ«herĂ« ne duam tĂ« bĂ«jmĂ« eksperimente pĂ«r 5 ditĂ«. Por me spote kjo mund tĂ« bĂ«het, spote ndonjĂ«herĂ« jetojnĂ« pĂ«r muaj.
Përshëndetje! Faleminderit për prezantimin! Përmendët për checkup. Si llogaritni gabimet stat_statements?
Pyetje shumĂ« e mirĂ«. Mund tĂ« tregoj dhe shpjegoj shumĂ« detajisht. NĂ« shkurt â ne shikojmĂ« si evoluon grupi i kĂ«rkesave: sa u shkĂ«put dhe sa u shfaqen tĂ« reja. Pastaj shikojmĂ« dy metri: total_time dhe calls, prandaj ka dy gabime. ShikojmĂ« gjithashtu, cila Ă«shtĂ« kontributi i grupeve tĂ« shkĂ«putura. Ka dy nĂ«ngrupe: tĂ« larguara dhe tĂ« ardhura. ShikojmĂ«, cila Ă«shtĂ« kontributi i tyre nĂ« pĂ«rgjithĂ«sinĂ«.
A nuk keni frikë se ajo mund të rrotullohet dy-tre herë gjatë kohës midis snapshot-ve?
Domethënë, ata u regjistruan përsëri ose si?
Për shembull, kjo kërkesë është shtypur një herë, pastaj erdhi përsëri dhe u shtyp, pastaj përsëri erdhi dhe u shtyp. Dhe ju keni bërë disa llogaritje, dhe ku janë të gjithë ata?
Pyetje e mirë, duhet të shohim.
Unë kam bërë një gjë të ngjashme. Sigurisht më e thjeshtë, e kam bërë vetëm. Por më duhej të shlyej, të bëj një reset stat_statements dhe të orientohem në momentin e snapshot, që atje të ketë një pjesë përkatëse, që përsëri nuk është arritur në kufirin e maksimalit sa stat_statements mund të grumbullohen. Dhe unë orientohem, që me gjasë nuk është zhdukur asgjë.
Po-po.
Por si mund ta bësh ndryshe në mënyrë të besueshme, nuk e kuptoj.
MĂ« vjen keq, nuk e mbaj mend saktĂ«sisht â a pĂ«rdorim tekstin e kĂ«rkesĂ«s apo queryid me pg_stat_statements dhe nĂ« atĂ« orientohemi. NĂ«se orientohemi nĂ« queryid, atĂ«herĂ« teorikisht po krahasonim gjĂ«ra tĂ« krahasueshme.
Jo, ai mund të shtypet disa herë midis snapshot-ve dhe të vijë përsëri.
Me këtë id?
Po.
Ne do ta studiojmë këtë. Pyetje e mirë. Duhet ta studiojmë. Por për momentin, ajo që shohim është ose shkruhet 0...
Sigurisht, ky është një rast i rrallë, por jam tronditur kur mësova se stat_statements mund të shtypet.
Në Pg_stat_statements mund të ketë shumë gjëra. Ndeshim se nëse keni track_utility = e aktivizuar, atëherë kurset gjithashtu regjistrohen.
Po, sigurisht.
Dhe nëse keni java hibernate, që është rastësor, atëherë fillon të bllokohet tabela e hasheve. Dhe sapo të fikni një aplikacion shumë të ngarkuar, ju mbeteni me 50-100 grupe. Dhe aty gjithçka bëhet më shumë-më pak e stabilizuar. Një nga mënyrat për të luftuar këtë është të rrisni pg_stat_statements.max.
Po, por duhet të dini, sa. Dhe duhet të mbani ndjekje. Unë e bëj kështu. Domethënë, unë kam pg_stat_statements.max. Dhe shikoj që në momentin e snapshot nuk kam arritur më shumë se 70%. Mirë, domethënë nuk kemi humbur asgjë. Bëjmë reset. Dhe grumbullojmë përsëri. Nëse në snapshot-in tjetër është nën 70, atëherë me gjasë përsëri nuk kemi humbur asgjë.
Po. Në mënyrë të paracaktuar tani janë 5,000. Dhe shumë njerëz mjaftojnë me këtë.
Zakonisht â po.
Video:
P.S. Nga vetja do të shtoja se nëse në Postgres ka të dhëna konfidenciale dhe nuk duhet të hyjnë në ambientin e testimit, atëherë mund të përdorni . Schemi është përafërsisht si vijon:
Burimi: habr.com
