Alexey Lesovsky-ren 2015eko txostenaren transkripzioa "PostgreSQL barne-estatistiketan sakondu"
Txostenaren egilearen oharra: Txosten honek 2015eko azaroko data duela ohartzen naiz, 4 urte baino gehiago igaro dira eta denbora asko igaro dira. Txostenean eztabaidatutako 9.4 bertsioa jada ez da onartzen. Azken 4 urteotan, 5 bertsio berri kaleratu dira eta horietan estatistikei buruzko berrikuntza, hobekuntza eta aldaketa ugari agertu dira, eta material batzuk zaharkituta daude eta ez dago garrantzitsua. Berrikusi dudanez, leku hauek markatzen saiatu naiz irakurlea engainatzeko. Ez ditut leku hauek berridatzi, asko daude eta, ondorioz, erreportaje guztiz ezberdina aterako da.
PostgreSQL DBMS mekanismo izugarria da, eta mekanismo honek azpisistema asko ditu, eta horien lan koordinatuak DBMSren errendimenduari zuzenean eragiten dio. Funtzionamenduan zehar, osagaien funtzionamenduari buruzko estatistikak eta informazioa biltzen dira, eta horri esker, PostgreSQL-ren eraginkortasuna ebaluatu eta errendimendua hobetzeko neurriak hartzen dira. Hala ere, informazio hori asko dago eta nahiko forma sinplifikatu batean aurkezten da. Informazio hau prozesatzea eta interpretatzea, batzuetan, guztiz ez-hutsezkoa da, eta tresna eta utilitateen "zoo"-ak erraz nahas dezake DBA aurreratu bat ere.
Arratsalde on Nire izena Aleksey da. Ilyak esan bezala, PostgreSQL estatistikei buruz hitz egingo dut.
PostgreSQL jarduera-estatistikak. PostgreSQL-k bi estatistika ditu. Jardueren estatistikak, eztabaidatuko direnak. Eta datuen banaketari buruzko programatzaileen estatistikak. Zehazki, PostgreSQL jarduera-estatistikari buruz hitz egingo dut, errendimendua epaitzeko eta nolabait hobetzeko aukera ematen digutenak.
Esango dizut nola erabili estatistikak modu eraginkorrean dituzun edo izan ditzakezun hainbat arazo konpontzeko.
Zer ez da egongo txostenean? Txostenean, ez ditut programatzailearen estatistikak ukituko, zeren. hau da, datu-basean datuak nola gordetzen diren eta kontsulta-planifikatzaileak datu horien ezaugarri kualitatibo eta kuantitatiboei buruzko ideia bat nola lortzen duen txosten bereizi baterako.
Eta ez da tresnaren berrikuspenik izango, ez dut produktu bat beste batekin alderatuko. Ez da publizitaterik egongo. Utz dezagun hau.
Erakutsi nahi dizut estatistikak erabiltzea erabilgarria dela. Beharrezkoa da. Erabili beldurrik gabe. Behar dugun guztia SQL arrunta eta SQLren oinarrizko ezagutza da.
Eta problemak ebazteko zein estatistikari buruz hitz egingo dugu.
PostgreSQL-ra begiratu eta sistema eragilean komando bat exekutatzen badugu prozesuak ikusteko, "kutxa beltz" bat ikusiko dugu. Zerbait egiten duten prozesu batzuk ikusiko ditugu, eta izenaz gutxi gorabehera imajina dezakegu han zer egiten duten, zer egiten duten. Baina, egia esan, hau kutxa beltza da, ezin dugu barrura begiratu.
PUZaren karga ikus dezakegu top, sistemaren erabilgarritasun batzuek memoriaren erabilera ikus dezakegu, baina ezin izango dugu PostgreSQL-ren barruan begiratu. Horretarako beste tresna batzuk behar ditugu.
Eta aurrerago jarraituz, denbora non igarotzen den esango dizut. PostgreSQL eskema baten moduan irudikatzen badugu, orduan denbora non igarotzen den erantzutea posible izango da. Hauek bi gauza dira: aplikazioen bezeroen eskaerak prozesatzea eta PostgreSQL-k funtzionatzen jarraitzeko egiten dituen atzeko zereginak dira.
Goiko ezkerreko izkinan begiratzen hasten bagara, bezeroen eskaerak nola prozesatzen diren ikus dezakegu. Eskaera aplikaziotik dator eta bezeroaren saio bat irekitzen da lan gehiago egiteko. Eskaera programatzailera pasatzen da. Antolatzaileak kontsulta-plan bat eraikitzen du. Gehiago bidaltzen du exekutatzeko. Taulekin eta indizeekin lotutako I/O datu mota batzuk daude. Beharrezko datuak diskoetatik memoriara irakurtzen dira "buffer partekatuak" izeneko eremu berezi batean. Kontsulten emaitzak, eguneratzeak edo ezabatzeak badira, transakzioen erregistroan erregistratzen dira WAL-en. Informazio estatistiko batzuk erregistroan edo estatistiken biltzailean sartzen dira. Eta eskaeraren emaitza bezeroari itzultzen zaio. Horren ostean, bezeroak dena errepikatu dezake eskaera berri batekin.
Zer dugu atzeko planoko zereginekin eta atzeko prozesuekin? Datu-basea normal exekutatzen eta martxan mantentzen duten hainbat prozesu ditugu. Txostenean prozesu hauek ere landuko dira: hauek dira: autovacuum, checkpointer, errepikapenarekin lotutako prozesuak, background writer. Jakinarazten dudan heinean horietako bakoitza ukituko dut.
Zeintzuk dira estatistikekin arazoak?
- Informazio asko. PostgreSQL 9.4-k 109 metrika eskaintzen ditu estatistika-datuak ikusteko. Hala ere, datu-baseak taula, eskema, datu-base asko gordetzen baditu, orduan metrika horiek guztiak dagokion taula, datu-basearekin biderkatu beharko dira. Hau da, informazio gehiago dago. Eta oso erraza da bertan itotzea.
- Hurrengo arazoa da estatistikak kontagailuen bidez adierazten direla. Estatistika horiei erreparatzen badiegu, etengabe hazten diren kontagailuak ikusiko ditugu. Eta estatistikak berrezarri zirenetik denbora asko igaro bada, milaka milioi balio ikusiko ditugu. Eta ez digute ezer esaten.
- Ez dago historiarik. Nolabaiteko hutsegiterik baduzu, duela 15-30 minutu zerbait erori zen, ezin izango duzu estatistikak erabili eta duela 15-30 minutu zer gertatu zen ikusi. Hau arazoa da.
- PostgreSQL-n integratutako tresnarik ez izatea arazo bat da. Nukleoko garatzaileek ez dute inolako erabilgarritasunik ematen. Ez dute horrelakorik. Datu-basean estatistikak besterik ez dituzte ematen. Erabili, egin eskaera, nahi duzuna, gero egin.
- PostgreSQL-n tresnarik ez dagoenez, honek beste arazo bat sortzen du. Hirugarrenen tresna asko. Esku gehiago edo gutxiago zuzenak dituen enpresa bakoitza bere programa idazten saiatzen ari da. Eta, ondorioz, komunitateak estatistikekin lan egiteko erabil ditzakezun tresna asko ditu. Eta tresna batzuetan ezaugarri batzuk daude, beste tresnetan ez dago beste ezaugarririk edo ezaugarri berri batzuk daude. Eta bata bestearen gainjarri diren eta funtzio desberdinak dituzten bizpahiru edo lau tresna erabili behar dituzun egoera sortzen da. Hau oso gogaikarria da.
Zer ateratzen da honetatik? Garrantzitsua da estatistikak zuzenean hartu ahal izatea programen menpe ez egoteko, edo nolabait programa hauek zuk zeuk hobetzeko: gehitu funtzio batzuk zure onura lortzeko.
Eta SQLren oinarrizko ezagutzak behar dituzu. Estatistiketatik datu batzuk lortzeko, SQL kontsultak egin behar dituzu, hau da, jakin behar duzu nola hautatu, batzen diren.
Estatistikak hainbat gauza esaten dizkigu. Kategorietan banatu daitezke.
- Lehenengo kategoria datu-basean gertatzen diren gertaerak dira. Hau da datu-basean gertaeraren bat gertatzen denean: kontsulta bat, taularako sarbidea, hutsune automatikoa, konpromezuak, gero hauek guztiak gertaerak dira. Gertaera horiei dagozkien kontagailuak gehitzen dira. Eta gertaera horien jarraipena egin dezakegu.
- Bigarren kategoria objektuen propietateak dira, hala nola, taulak, datu-baseak. Propietateak dituzte. Hau da taulen tamaina. Taulen hazkundearen jarraipena egin dezakegu, indizeen hazkundea. Dinamiketan aldaketak ikus ditzakegu.
- Eta hirugarren kategoria ekitaldian emandako denbora da. Eskaera ekitaldi bat da. Bere iraupen neurri zehatza du. Hemen hasi, hemen amaitu. Jarraitu dezakegu. Edo diskotik bloke bat irakurtzeko edo idazteko ordua. Gauza hauek ere jarraipena egiten zaie.
Estatistiken iturriak honela aurkezten dira:
- Memoria partekatuan (buffer partekatuak) datu estatikoak bertan jartzeko segmentu bat dago, badira gertaera batzuk gertatzen direnean edo datu-basearen funtzionamenduan momentu batzuk sortzen direnean etengabe handitzen diren kontagailuak ere.
- Kontadore horiek guztiak ez daude erabiltzailearentzat eskuragarri eta administratzaileak ere ez daude eskuragarri. Maila baxuko gauzak dira. Horietara sartzeko, PostgreSQL-k interfaze bat eskaintzen du SQL funtzioen moduan. Funtzio hauek erabiliz hautaketak egin ditzakegu eta metrika (edo metrika multzoa) moduko bat lor dezakegu.
- Dena den, ez da beti komenigarria funtzio hauek erabiltzea, beraz, funtzioak dira bistetarako (IKUSTEA) oinarria. Azpisistema zehatz bati buruzko edo datu-baseko gertaera batzuen estatistikak ematen dituzten taula birtualak dira.
- Ikuspegi integratuak (VIEWS) hauek estatistikekin lan egiteko erabiltzailearen interfaze nagusia dira. Berez eskuragarri daude ezarpen gehigarririk gabe, berehala erabil ditzakezu, ikusi, informazioa handik hartu. Eta ekarpenak ere badaude. Ekarpenak ofizialak dira. Postgresql-contrib paketea instalatu dezakezu (adibidez, postgresql94-contrib), beharrezko modulua konfigurazioan kargatu, parametroak zehaztu, PostgreSQL berrabiarazi eta erabil dezakezu. (Ohar. Banaketaren arabera, contrib-en azken bertsioetan paketea pakete nagusiaren parte da).
- Eta ekarpen ez-ofizialak daude. Ez dira PostgreSQL banaketa estandarrarekin hornitzen. Liburutegi gisa konpilatu edo instalatu behar dira. Aukerak oso desberdinak izan daitezke, ekarpen ez-ofizial honen garatzaileak asmatu duenaren arabera.
Diapositiba honek PostgreSQL 9.4-n erabilgarri dauden bista guztiak (IKUSPENAK) eta funtzio horietako batzuk erakusten ditu. Ikusten dugunez, asko daude. Eta nahiko erraza da nahastea lehen aldiz bizitzen ari bazara.
Hala ere, aurreko argazkia ateratzen badugu ΠΠ°ΠΊ ΡΡΠ°ΡΠΈΡΡΡ Π²ΡΠ΅ΠΌΡ Π½Π° PostgreSQL eta zerrenda honekin bateragarria, argazki hau lortzen dugu. Ikuspegi bakoitza (IKUSTEA), edo funtzio bakoitza, helburu batera edo bestera erabil dezakegu PostgreSQL martxan dugunean estatistika egokiak lortzeko. Eta dagoeneko azpisistemaren funtzionamenduari buruzko informazio pixka bat lor dezakegu.
Ikusiko dugun lehenengo gauza da pg_stat_database. Ikus dezakegunez, hau irudikapen bat da. Informazio asko dauka. Informaziorik askotarikoa. Eta datu-basean gertatzen ari garenaren ezagutza oso baliagarria ematen du.
Zer hartu dezakegu hortik? Has gaitezen gauza errazenetatik.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;Ikus dezakegun lehenengo gauza cache-aren arrakasta-ehunekoa da. Cachearen aipamenaren ehunekoa baliogarria da. Buffer partekatutako cachetik zenbat datu hartzen diren eta diskotik zenbat irakurtzen diren kalkulatzeko aukera ematen du.
Argi dago hori zenbat eta cache hit gehiago izan, orduan eta hobeto. Neurri hau ehuneko gisa ebaluatzen dugu. Eta, adibidez, cache-aipatu horien ehunekoa % 90 baino handiagoa bada, ona da. %90etik behera jaisten bada, orduan ez dugu nahikoa memoria datuen buru beroa memorian mantentzeko. Eta datu hauek erabiltzeko, PostgreSQL diskora sartzera behartuta dago eta hau datuak memoriatik irakurriko balira baino motelagoa da. Eta memoria handitzea pentsatu behar duzu: edo partekatutako buffer-ak handitu, edo burdinazko memoria (RAM) handitu.
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;Zer gehiago atera daiteke emanaldi honetatik? Datu-basean gertatzen diren anomaliak ikus ditzakezu. Zer erakusten da hemen? Konpromisoak, atzerapenak, aldi baterako fitxategiak sortzea, haien tamaina, blokeoak eta gatazkak daude.
Eskaera hau erabil dezakegu. SQL hau nahiko erraza da. Eta datu hauek guk geuk ikus ditzakegu.
Eta hona hemen atalasearen balioak. Konpromisoen eta itzulketen ratioa aztertzen dugu. Konpromisoak transakzioaren berrespen arrakastatsua da. Rollback-ak itzulera bat dira, hau da, transakzioak lan bat egin zuen, datu-basea tentsioa egin zuen, zerbait kontuan hartu zuen eta, ondoren, hutsegite bat gertatu zen eta transakzioaren emaitzak baztertu egiten dira. hau da. etengabe handitzen ari diren atzerapen kopurua txarra da. Eta nolabait saihestu beharko zenituzke eta kodea editatu, hori gerta ez dadin.
Gatazkak errepikapenarekin lotuta daude. Eta horiek ere saihestu behar dira. Erreplikan exekutatzen diren kontsulta batzuk badituzu eta gatazkak sortzen badira, gatazka horiek aztertu eta zer gertatzen den ikusi behar duzu. Xehetasunak erregistroetan aurki daitezke. Eta konpondu gatazkak, aplikazioen eskaerak akatsik gabe funtzionatzeko.
Blokeoak ere egoera txarra da. Eskaerak baliabideengatik lehiatzen direnean, eskaera batek baliabide batera atzitzen zuen eta blokeoa hartu zuen, bigarren eskaerak bigarren baliabidera sartu eta blokeoa ere hartu zuen, eta, ondoren, bi eskaerak elkarren baliabideetara sartzen ziren eta bizilagunak blokeoa askatzeko zain zegoen. Hau ere egoera problematikoa da. Aplikazioak berridazteko eta baliabideetarako sarbidea serializatzeko mailan jorratu behar dira. Eta zure blokeoak etengabe handitzen ari direla ikusten baduzu, erregistroetan xehetasunak aztertu, sortu diren egoerak aztertu eta arazoa zein den ikusi behar duzu.
Aldi baterako fitxategiak (temp_files) ere txarrak dira. Erabiltzaile-eskaerak aldi baterako datu operatiboak gordetzeko memoria nahikoa ez duenean, fitxategi bat sortzen du diskoan. Eta memorian aldi baterako buffer batean egin ditzakeen eragiketa guztiak, dagoeneko diskoan egiten hasten da. Motela da. Horrek kontsultaren exekuzio denbora handitzen du. Eta PostgreSQL-i eskaera bidali dion bezeroak erantzun bat jasoko du pixka bat geroago. Eragiketa hauek guztiak memorian egiten badira, Postgres-ek askoz azkarrago erantzungo du eta bezeroak gutxiago itxarongo du.
pg_stat_bgwriter - Ikuspegi honek PostgreSQL atzeko planoko bi azpisistemen funtzionamendua deskribatzen du: checkpointer ΠΈ background writer.
Hasteko, azter ditzagun kontrol puntuak, deitzen direnak. checkpoints. Zer dira kontrol-puntuak? Kontrol-puntua transakzioen erregistroko posizio bat da, erregistroan egindako datu-aldaketa guztiak diskoko datuekin behar bezala sinkronizatzen direla adierazten duena. Prozesua, lan-kargaren eta ezarpenen arabera, luzea izan daiteke eta, gehienbat, partekatutako bufferetan orrialde zikinak diskoko datu-fitxategiekin sinkronizatzean datza. Zertarako da? PostgreSQL denbora guztian diskora sartzen eta handik datuak hartzen eta sarbide bakoitzean datuak idatziz gero, motela izango litzateke. Hori dela eta, PostgreSQL-k memoria-segmentu bat du, eta horren tamaina konfigurazioko parametroen araberakoa da. Postgres-ek memoria honetan datu operatiboak esleitzen ditu gehiago prozesatzeko edo kontsultatzeko. Datuak aldatzeko eskaeren kasuan, aldatu egiten dira. Eta datuen bi bertsio lortzen ditugu. Bata memorian dago, bestea diskoan. Eta aldian-aldian datu hauek sinkronizatu behar dituzu. Memorian aldatutakoa diskoarekin sinkronizatzeko behar dugu. Horrek kontrol-puntu bat behar du.
Checkpoint-ek partekatutako bufferetatik pasatzen du, kontrol punturako beharrezkoak diren orrialde zikinak markatzen ditu. Ondoren, buffer partekatuetatik bigarren pasabidea hasten du. Eta kontrolerako markatuta dauden orriak, dagoeneko sinkronizatzen ditu. Horrela, datuak dagoeneko diskoarekin sinkronizatuta daude.
Bi kontrol puntu mota daude. Kontrol-puntu bat denbora-muga batean exekutatzen da. Kontrol-puntu hau erabilgarria eta ona da - checkpoint_timed. Eta eskaeraren arabera kontrolak daude - checkpoint required. Halako kontrol-puntu bat datu-erregistro oso handia dugunean gertatzen da. Transakzio-erregistro asko erregistratu ditugu. Eta PostgreSQL-k uste du hori guztia sinkronizatu behar duela ahalik eta azkarren, kontrol puntu bat egin eta aurrera.
Eta estatistikak begiratuz gero pg_stat_bgwriter eta ikusi zer daukazun checkpoint_req checkpoint_timed baino askoz handiagoa da, orduan hau txarra da. Zergatik txarra? Horrek esan nahi du PostgreSQL etengabeko tentsioan dagoela datuak diskoan idatzi behar dituenean. Checkpoint by timeout ez da hain estresagarria eta barne-programazioaren arabera exekutatzen da eta, nolabait, denboran luzatuta. PostgreSQL-k lana pausatzeko eta diskoaren azpisistema ez estutzeko gaitasuna du. Hau erabilgarria da PostgreSQL-rentzat. Eta kontrol-puntuan exekutatzen diren eskaerek ez dute estresik izango diskoaren azpisistema okupatuta dagoelako.
Eta hiru parametro daude kontrol-puntua doitzeko:
-
Ρheckpoint_segments. -
Ρheckpoint_timeout. -
Ρheckpoint_competion_target.
Kontrol puntuen funtzionamendua kontrolatzeko aukera ematen dute. Baina ez naiz haietan luzatuko. Haien eragina aparteko gaia da.
Abisua: Txostenean kontuan hartutako 9.4 bertsioa jada ez da garrantzitsua. PostgreSQL-ren bertsio modernoetan, parametroa checkpoint_segments parametroek ordezkatuta min_wal_size ΠΈ max_wal_size.
Hurrengo azpisistema hondo-idazlea β da background writer. Zertan ari da? Etengabe exekutatzen da amaigabeko begizta batean. Orriak partekatutako bufferetan eskaneatzen ditu eta aurkitzen dituen orrialde zikinak diskora garbitzen ditu. Modu honetan, kontrol-puntulariari lan gutxiago egiten laguntzen dio kontrol-puntuetan.
Zertarako behar da gehiago? Buffer partekatuetan orri garbien beharra eskaintzen du, bat-batean behar badira (kantitate handietan eta berehala) datuak sartzeko. Demagun egoera bat sortu dela eskaerak orri garbiak behar zituenean eta dagoeneko partekatutako bufferetan daudela. Postgres backend hartu eta erabiltzen ditu, ez du berak ezer garbitu behar. Baina bat-batean horrelako orrialderik ez badago, backend-ak eten egiten du eta orrialdeak bilatzen hasten da diskora hustu eta bere beharretara eramateko, eta horrek negatiboki eragiten du unean exekutatzen den eskaeraren denbora. Parametro bat duzula ikusten baduzu maxwritten_clean handia, horrek esan nahi du atzeko planoko idazleak ez duela bere lana egiten eta parametroak handitu behar dituzula bgwriter_lru_maxpagesziklo batean lan gehiago egin dezan, orrialde gehiago garbitu.
Eta beste adierazle oso erabilgarria da buffers_backend_fsync. Backendek ez dute fsync egiten, motela delako. fsync IO pilaren kontrol-puntutik gora pasatzen dute. Checkpointer-ak bere ilara propioa du, aldian-aldian fsync prozesatzen du eta memoriako orriak diskoko fitxategiekin sinkronizatzen ditu. Checkpointer ilara handia eta beteta badago, backend-a fsync bera egitera behartuta dago eta honek backend-a moteldu egiten du., hau da, bezeroak ahal baino beranduago jasoko du erantzuna. Balio hori zero baino handiagoa duzula ikusten baduzu, hori arazo bat da dagoeneko eta atzeko planoko idazlearen ezarpenei erreparatu behar diezu eta disko azpisistemaren errendimendua ere ebaluatu behar duzu.
Abisua: _Ondoko testuan erreplikazioarekin lotutako ikuspegi estatistikoak deskribatzen dira. Ikuspegi eta funtzio-izen gehienak Postgres 10-en izena aldatu dute. Berrizenen funtsa ordezkatzea zen. xlog on wal ΠΈ location on lsn funtzio/ikuspegi izenetan, etab. Adibide berezia, funtzioa pg_xlog_location_diff() izena aldatu zitzaion pg_wal_lsn_diff()._
Hemen ere asko dugu. Baina kokapenari lotutako elementuak baino ez ditugu behar.
Balio guztiak berdinak direla ikusten badugu, hau aproposa da eta erreplika ez da maisuaren atzean geratzen.
Kokapen hamaseimal hau transakzioen erregistroko posizioa da. Etengabe handitzen da datu-basean jardueraren bat badago: txertaketak, ezabaketak, etab.
ΡΠΊΠΎΠ»ΡΠΊΠΎ Π·Π°ΠΏΠΈΡΠ°Π½ΠΎ xlog Π² Π±Π°ΠΉΡΠ°Ρ
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
Π»Π°Π³ ΡΠ΅ΠΏΠ»ΠΈΠΊΠ°ΡΠΈΠΈ Π² Π±Π°ΠΉΡΠ°Ρ
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
Π»Π°Π³ ΡΠ΅ΠΏΠ»ΠΈΠΊΠ°ΡΠΈΠΈ Π² ΡΠ΅ΠΊΡΠ½Π΄Π°Ρ
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());Gauza hauek desberdinak badira, orduan nolabaiteko atzerapena dago. Lag maisuaren erreplikaren atzerapena da, hau da, datuak desberdinak dira zerbitzarien artean.
Hiru dira atzerapenaren arrazoiak:
- Fitxategien sinkronizazio idazketak kudeatu ezin dituen diskoaren azpisistema da.
- Hauek sareko akatsak edo sareko gainkarga izan daitezke, datuak erreplikara iristeko denborarik ez dutenean eta ezin direnean erreproduzitu.
- Eta prozesadorea. Prozesadorea oso kasu arraroa da. Eta hori bizpahiru aldiz ikusi dut, baina hori ere gerta daiteke.
Eta hona hemen estatistikak erabiltzeko aukera ematen diguten hiru kontsulta. Gure transakzioen erregistroan zenbat erregistratu den kalkula dezakegu. Badago halako funtzio bat pg_xlog_location_diff eta erreplikazio-lag-a byte eta segundotan kalkula dezakegu. Ikuspegi honetako balioa (IKUSPAK) ere erabiltzen dugu horretarako.
Oharra: _Pg_xlog_location-en ordezdiff() funtzioa, kenketa operadorea erabil dezakezu eta kokapen bat beste batetik ken dezakezu. Eroso.
Lag batekin, hau da, segundotan, une bat dago. Masterrean jarduerarik ez badago, transakzioa duela 15 minutu inguru egon zen eta ez dago jarduerarik, eta erreplikaren atzerapen hori ikusten badugu, 15 minutuko atzerapena ikusiko dugu. Hau gogoratzea merezi du. Eta estupora ekar dezake atzerapen hori ikustean.
pg_stat_all_tables beste ikuspegi erabilgarria da. Tauletan estatistikak erakusten ditu. Datu-basean taulak ditugunean, jardueraren bat dago horrekin, ekintza batzuk, informazio hau ikuspegi honetatik lor dezakegu.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;Ikus dezakegun lehenengo gauza taula sekuentzialak aztertzea da. Pasarte horien ondorengo zenbakiak berak ez du zertan txarra izan eta ez du adierazten jada zerbait egin behar dugunik.
Hala ere, bigarren metrika bat dago - seq_tup_read. Hau da bilaketa sekuentzialetik itzuli den errenkada kopurua. Batez besteko kopurua 1, 000, 10, 000 gainditzen badu, hori dagoeneko indize bat eraiki behar duzula nonbait, sarbideak indize bidez izan daitezen, edo bilaketa sekuentzialak erabiltzen dituzten kontsultak optimizatu daitezke. hau ez da gertatzen. zen.
Adibide sinple bat - demagun OFFSET eta LIMIT handi batekin eskaerak merezi duela. Adibidez, taula bateko 100 errenkada eskaneatzen dira eta horren ondoren beharrezko 000 errenkada hartzen dira, eta eskaneatutako aurreko errenkadak baztertzen dira. Hau ere kasu txarra da. Eta horrelako eskaerak optimizatu egin behar dira. Eta hona hemen SQL kontsulta sinple bat, bertan ikusi eta jasotako zenbakiak ebaluatu ditzakezun.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;Taulen tamainak ere lor daitezke taula hau erabiliz eta funtzio osagarriak erabiliz pg_total_relation_size(), pg_relation_size().
Oro har, metakomandoak daude dt ΠΈ di, PSQL-n erabil dezakezuna eta taula eta indizeen tamainak ere ikus ditzakezu.
Hala ere, funtzioen erabilerak taulen tamainak aztertzen laguntzen digu, nahiz eta indizeak kontuan hartuz, edo indizeak kontuan hartu gabe, eta dagoeneko datu-basearen hazkuntzaren arabera estimazio batzuk egiten, hau da, gurekin nola hazten den, zer intentsitate, eta dagoeneko atera ondorio batzuk dimentsioaren optimizazioari buruz.
Idatzi jarduera. Zer da disko bat? Ikus dezagun funtzionamendua UPDATE β taulako errenkadak eguneratzeko eragiketa. Izan ere, eguneratzea bi eragiketa da (edo are gehiago). Hau errenkada-bertsio berri bat txertatzen da eta errenkada-bertsio zaharra zaharkituta bezala markatzen da. Geroago, hutsune automatikoa etorriko da eta lerroen bertsio zaharkitu hauek garbituko ditu, markatu leku hau berrerabiltzeko erabilgarri gisa.
Gainera, eguneratzea ez da taula bat eguneratzea soilik. Indizearen eguneraketa da oraindik. Taulan indize asko badituzu, eguneraketarekin, kontsultan eguneratutako eremuek parte hartzen duten indize guztiak ere eguneratu beharko dira. Indize hauek garbitu beharko diren errenkada bertsio zaharkituak ere izango dituzte.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;Eta bere diseinuagatik, UPDATE pisu handiko eragiketa da. Baina erraztu egin daitezke. Jan hot updates. PostgreSQL 8.3 bertsioan agertu ziren. Eta zer da hau? Indizeak berreraikitzea eragiten ez duen eguneratze arina da hau. Hau da, erregistroa eguneratu dugu, baina orrialdeko erregistroa (taulari dagokiona) bakarrik eguneratu da, eta aurkibideek oraindik orrialdeko erregistro bera adierazten dute. Badago lanaren logika interesgarri bat, hutsunea iristen denean, kate hauek ditu hot berreraikitzen da eta denak funtzionatzen jarraitzen du indizeak eguneratu gabe, eta dena baliabide gutxiago xahutuz gertatzen da.
Eta daukazunean n_tup_hot_upd handia, oso ona da. Horrek esan nahi du eguneratze arinak nagusitzen direla eta hau baliabideei dagokienez merkeagoa dela eta dena ondo dago.
ALTER TABLE table_name SET (fillfactor = 70);Nola handitu bolumena hot updateov? Erabili dezakegu fillfactor. Erreserbatutako espazio librearen tamaina zehazten du txertaketak erabiliz taula bateko orri bat betetzean. Txertaketak mahaira joaten direnean, orria guztiz betetzen dute, ez dute leku hutsik utzi. Ondoren, orrialde berri bat nabarmentzen da. Datuak berriro betetzen dira. Eta hau da portaera lehenetsia, fillfactor = % 100.
Bete-faktorea %70ean ezar dezakegu. Hau da, txertatzeekin, orri berri bat esleitu zen, baina orriaren %70 baino ez zen bete. Eta %30 geratzen zaigu erreserban. Eguneratze bat egin behar duzunean, ziurrenik orri berean gertatuko da, eta errenkadaren bertsio berria orrialde berean sartuko da. Eta hot_update egingo da. Horri esker, errazagoa da tauletan idaztea.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Auto-hutseko ilara. Autovacuum PostgreSQL-en estatistikak oso gutxi dituen azpisistema bat da. pg_stat_activity-ko tauletan soilik ikus dezakegu zenbat huts ditugun momentu honetan. Hala ere, oso zaila da ulertzea ilaran zenbat mahai dituen edonon.
Oharra: _Postgres 10az geroztik, hutsaren hutsaren jarraipenaren egoera asko hobetu da - pg_stat_progress ikuspegia agertu dahutsean, eta horrek asko errazten du auto-hutsean kontrolatzearen arazoa.
Kontsulta sinplifikatu hau erabil dezakegu. Eta hutsa noiz egin behar den ikus dezakegu. Baina, nola eta noiz hasi behar da hutsean? Hauek dira lehen hitz egin ditudan kateen bertsio zaharrak. Eguneraketa gertatu da, errenkadaren bertsio berria txertatu da. Katearen bertsio zaharkitua agertu da. Taula pg_stat_user_tables badago halako parametro bat n_dead_tup. "Hildako" errenkada kopurua erakusten du. Eta hildako errenkaden kopurua atalase jakin bat baino gehiago bihurtu bezain laster, hutsune automatikoa etorriko da mahaira.
Eta nola kalkulatzen da atalase hori? Hau taulako errenkada kopuru osoaren ehuneko oso zehatza da. Parametro bat dago autovacuum_vacuum_scale_factor. Ehunekoa definitzen du. Demagun % 10 + 50 lerroko oinarrizko atalase gehigarri bat dagoela. Eta zer gertatzen da? Taularen errenkada guztien "% 10 + 50" baino hildako errenkada gehiago ditugunean, mahaia hutsean jartzen dugu.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Hala ere, bada puntu bat. Parametroen oinarrizko atalaseak av_base_thresh ΠΈ av_scale_factor banaka esleitu daitezke. Eta, horren arabera, atalasea ez da globala izango, mahairako indibiduala baizik. Hori dela eta, kalkulatzeko, trikimailuak eta trikimailuak erabili behar dituzu. Eta interesatzen bazaizu, Avitoko gure lankideen esperientzia ikus dezakezu (diapositibako esteka baliogabea da eta testuan eguneratuta dago).
rentzat idatzi zuten gauza hauek kontuan hartzen dituena. Bi maindire gainean oin-oihal bat dago. Baina zuzen eta nahiko eraginkorrean pentsatzen du gutxi dagoen mahaietarako huts handia non behar dugun baloratzeko aukera ematen digu.
Zer egin dezakegu horri buruz? Ilara luzea badugu eta hutsune automatikoak ezin badu aurre egin, orduan hutsean langileen kopurua handitu dezakegu, edo, besterik gabe, hutsa oldarkorrago bihurtu.beraz, lehenago piztu dadin, taula zati txikietan prozesatzen du. Eta horrela ilara gutxituko da. - Hemen gauza nagusia diskoen karga kontrolatzea da, zeren. Hutsean gauza ez da doakoa, nahiz eta SSD / NVMe gailuen etorrerarekin arazoa gutxiago nabaritu den.
pg_stat_all_indexes indizeei buruzko estatistikak dira. Ez da handia. Eta indizeen erabilerari buruzko informazioa lor dezakegu bertatik. Eta adibidez, gehigarri ditugun indizeak zehaztu ditzakegu.
Lehen esan dudan bezala, eguneratzea ez da soilik taulak eguneratzea, indizeak ere eguneratzea ere bada. Horren arabera, taulan indize asko baditugu, orduan taulako errenkadak eguneratzean, indexatutako eremuen indizeak ere eguneratu behar dira, eta Erabiltzen ez diren indizeak baditugu, indize-eskaerarik ez dutenentzat, orduan gurekin zintzilikatzen dira balasto gisa. Eta horiek kendu behar dituzu. Horretarako eremu bat behar dugu idx_scan. Indizeen eskaneatu kopuruari erreparatu besterik ez dugu egiten. Indizeek estatistikak biltegiratzeko aldi nahiko luzean (gutxienez 2-3 aste) eskaneatzen badute, ziurrenik indize txarrak dira, kendu egin behar ditugu.
Oharra: Erabili ez diren indizeak bilatzen dituzunean, streaming-erreplika-klusterren kasuan, klusterreko nodo guztiak egiaztatu behar dituzu, izan ere estatistikak ez dira globalak, eta indizea maisuan erabiltzen ez bada, errepliketan erabil daiteke (karga badago).
Bi esteka:
Hauek dira erabili gabeko indizeak bilatzeko kontsulta-adibide aurreratuagoak.
Bigarren esteka nahiko kontsulta interesgarria da. Oso logika ez hutsala dago bertan. Berrikusteko gomendatzen dut.
Zer gehiago laburtu behar da indizeen bidez?
-
Erabili gabeko indizeak txarrak dira.
-
Espazioa hartzen dute.
-
Moteldu eguneratze-eragiketak.
-
Lan gehigarria hutsean egiteko.
Erabiltzen ez diren indizeak kentzen baditugu, datu-basea hobetuko dugu.
Hurrengo ikuspegia da pg_stat_activity. Hau erabilgarritasunaren analogoa da ps, PostgreSQL-n bakarrik. Bada ps'Ohm, sistema eragileko prozesuak ikusten dituzu, orduan pg_stat_activity PostgreSQL barruko jarduera erakutsiko dizu.
Zer hartu dezakegu hortik?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;Datu-basean gertatzen ari den jarduera orokorra ikus dezakegu. Inplementazio berri bat egin dezakegu. Bertan dena lehertu zen, konexio berriak ez dira onartzen, akatsak isurtzen ari dira aplikazioan.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;Horrelako kontsulta bat exekutatu eta konexioen ehuneko osoa ikus dezakegu gehienezko konexio-mugarekiko eta ikusi zeintzuk ditugun konexio gehien. Eta emandako kasu honetan, erabiltzaile hori ikusten dugu cron_role 508 konexio ireki zituen. Eta zerbait gertatu zitzaion. Horri aurre egin eta ikusi behar duzu. Eta oso posible da hau konexio kopuru anormal bat izatea.
OLTP karga badugu, kontsultak azkarrak izan behar dira, oso azkarrak eta ez dira kontsulta luzeak egon behar. Hala ere, eskaera luzeak badira, epe laburrean ez dago ezer kezkatu, baina epe luzera, kontsulta luzeek datu-baseari kalte egiten diote, taulen bloat efektua areagotzen dute taula zatiketa gertatzen denean. Kontsulta puzgarriak eta luzeak ezabatu behar dira.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;Kontuan izan: eskaera horrekin, eskaera eta transakzio luzeak defini ditzakegu. Funtzioa erabiltzen dugu clock_timestamp() lanaldia zehazteko. Aurkitu ditugun eskaera luzeak, gogoratu ditzakegu, exekutatu explain, begiratu planak eta nolabait optimizatu. Egungo eskaera luzeak filmatzen ditugu eta bizi dira.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Transakzio txarrak inaktibo daude transakzioetan eta inaktibo daude transakzioetan (abortu) transakzioetan.
Zer esan nahi du? Transakzioek hainbat egoera dituzte. Eta egoera horietako batek edozein unetan har dezake. Estatuak definitzeko eremu bat dago state ikuspegi honetan. Eta egoera zehazteko erabiltzen dugu.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Eta, gorago esan dudan bezala, bi estatu hauek inaktibo transakzioan eta idle transakzioan (abortu) txarrak dira. Zer da hau? Hau da aplikazioak transakzio bat ireki, ekintza batzuk egin eta bere negozioari ekin dio. Transakzioak irekita jarraitzen du. Zintzilikatzen da, ez da ezer gertatzen bertan, konexio bat hartzen du, aldatutako errenkadetan blokeatzen da eta, potentzialki, beste taulen bloat areagotzen du, Postrges transakzio-motorraren arkitektura dela eta. Eta horrelako transakzioak ere tirokatu behar dira, orokorrean kaltegarriak direlako, edonola ere.
Zure datu-basean horietako 5-10-20 baino gehiago dituzula ikusten baduzu, orduan kezkatu eta haiekin zerbait egiten hasi behar zara.
Hemen ere kalkulu denborarako erabiltzen dugu clock_timestamp(). Transakzioak filmatzen ditugu, aplikazioa optimizatzen dugu.
Goian esan dudan bezala, blokeoak bi transakzio edo gehiago baliabide bat edo talde batengatik lehiatzen direnean dira. Horretarako eremu bat dugu waiting balio boolearrarekin true edo false.
Egia da - horrek esan nahi du prozesua zain dagoela, zerbait egin behar dela. Prozesu bat zain dagoenean, orduan prozesua hasi zuen bezeroa ere zain dago. Arakatzailean bezeroa esertzen da eta itxaron egiten du.
Abisua: _Postgres 9.6tik hasita, eremua waiting kendu eta beste bi eremu informatiborekin ordezkatu wait_event_type ΠΈ wait_event._
Zer egin? Denbora luzez egia ikusten baduzu, horrelako eskaerak kendu behar dituzu. Horrelako transakzioak filmatzen ditugu. Garatzaileei nolabait optimizatu beharrekoa idazten diegu, baliabideen lasterketarik egon ez dadin. Eta gero garatzaileek aplikazioa optimizatzen dute, hori gerta ez dadin.
Eta muturreko kasu bat, baina potentzialki ez hilgarria da blokeoak agertzea. Bi transakziok bi baliabide eguneratu dituzte, gero berriro sartzen dira, dagoeneko kontrako baliabideetara. PostgreSQL-k kasu honetan transakzioa bera hartzen eta jaurtitzen du, bestea lanean jarrai dezan. Hildako egoera bat da eta ez du bere burua ulertzen. Horregatik, PostgreSQL muturreko neurriak hartzera behartuta dago.
Eta hona hemen blokeoak jarraitzeko aukera ematen duten bi kontsulta. Ikuspegia erabiltzen dugu pg_locks, blokeo astunak jarraitzeko aukera ematen duena.
Eta lehenengo esteka eskaera testua bera da. Nahiko luzea da.
Eta bigarren esteka sarrailei buruzko artikulu bat da. Irakurtzeko erabilgarria da, oso interesgarria da.
Beraz, zer ikusten dugu? Bi eskaera ikusten ditugu. Transakzioa ALTER TABLE blokeo-transakzio bat da. Hasi zen, baina ez zen amaitu, eta transakzio hau argitaratu zuen aplikazioa beste gauza batzuk egiten ari da nonbait. Eta bigarren eskaera eguneratzea da. Alter mahaia amaitu arte itxaroten du bere lanean jarraitu aurretik.
Horrela jakin dezakegu nork giltzapetu zuen nori, nork atxikitzen duen nori, eta horri aurre egin ahal izango diogu.
Hurrengo modulua da pg_stat_statements. Esan bezala, modulu bat da. Erabiltzeko, bere liburutegia kargatu behar duzu konfigurazioan, PostgreSQL berrabiarazi, modulua instalatu (komando batekin) eta gero ikuspegi berri bat izango dugu.
CΡΠ΅Π΄Π½Π΅Π΅ Π²ΡΠ΅ΠΌΡ Π·Π°ΠΏΡΠΎΡΠ° Π² ΠΌΠΈΠ»ΠΈΡΠ΅ΠΊΡΠ½Π΄Π°Ρ
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Π‘Π°ΠΌΡΠ΅ Π°ΠΊΡΠΈΠ²Π½ΠΎ ΠΏΠΈΡΡΡΠΈΠ΅ (Π² shared_buffers) Π·Π°ΠΏΡΠΎΡΡ
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;Zer hartu dezakegu hortik? Gauza sinpleei buruz hitz egiten badugu, batez besteko kontsultaren exekuzio denbora har dezakegu. Denbora hazten ari da, hau da, PostgreSQL poliki-poliki erantzuten ari da eta zerbait egin behar da.
Buffer partekatuetan datuak aldatzen dituzten datu-basean idazteko transakzio aktiboenak ikus ditzakegu. Ikusi nork eguneratzen edo ezabatzen dituen datuak bertan.
Eta eskaera hauen estatistika desberdinak begiratu besterik ez dugu egin.
Dugu pg_stat_statements txostenak egiteko erabiltzen da. Estatistikak egunean behin berrezartzen ditugu. Metatu dezagun. Hurrengoan estatistikak berrezarri aurretik, txosten bat eraikitzen dugu. Hona hemen txostenaren esteka. Ikus dezakezu.
Zertan ari gara? Kontsulta guztien estatistika orokorra kalkulatzen dugu. Ondoren, kontsulta bakoitzerako, estatistika orokor honi egindako ekarpen indibiduala zenbatuko dugu.
Eta zer ikus dezakegu? Mota jakin bateko eskaera guztien exekuzio denbora osoa ikus dezakegu beste eskaera guztien atzeko planoan. PUZaren eta I/O-ren erabilera ikus dezakegu irudi orokorrarekin lotuta. Eta dagoeneko eskaera hauek optimizatzeko. Txosten honetan oinarritutako kontsulta nagusiak eraikitzen ari gara eta dagoeneko zer optimizatu behar den hausnartzeko aukera ematen ari gara.
Zer dugu eszenaren atzean? Oraindik kontuan hartu ez ditudan bidalketa batzuk daude, denbora mugatua delako.
Ez dago pgstattuple contribuciones pakete estandarreko modulu gehigarri bat ere bada. Ebaluatzeko aukera ematen du bloat mahaiak, deiturikoak. taula zatikatzea. Eta zatiketa handia bada, kendu behar duzu, tresna desberdinak erabili. Eta funtzioa pgstattuple denbora luzez funtzionatzen du. Eta zenbat eta mahai gehiago, orduan eta luzeago funtzionatuko du.
Hurrengo ekarpena da pg_buffercache. Partekatutako buffer-ak ikuskatzeko aukera ematen du: zenbateraino eta zein tauletarako erabiltzen diren buffer-orriak. Eta partekatutako buffer-ak aztertzeko eta bertan gertatzen dena ebaluatzeko aukera ematen du.
Hurrengo modulua da pgfincore. Sistema-dei baten bidez maila baxuko taula-eragiketak egiteko aukera ematen du mincore(), hau da, taula partekatutako bufferetan kargatzeko edo deskargatzeko aukera ematen du. Eta aukera ematen du, besteak beste, sistema eragilearen orrialde-cachea ikuskatzeko, hau da, taulak zenbat okupatzen duen orrialde-cachean, partekatutako bufferetan, eta, besterik gabe, mahaiaren karga ebaluatzeko aukera ematen du.
Hurrengo modulua da pg_stat_kcache. Sistema-deia ere erabiltzen du getrusage(). Eta eskaera egin aurretik eta ondoren exekutatzen du. Eta lortutako estatistiketan, gure eskaerak zenbat gastatu duen kalkulatzeko aukera ematen digu I/O diskoan, hau da, fitxategi-sistemarekin egindako eragiketak eta prozesadorearen erabilera aztertzen du. Hala ere, modulua gaztea da (khe-khe) eta bere lanerako PostgreSQL 9.4 eta pg_stat_statements behar ditu, lehen aipatu ditudanak.
-
Estatistikak erabiltzeko gaitasuna erabilgarria da. Ez duzu hirugarrenen softwarerik behar. Begiratu, ikusi, zerbait egin, egin dezakezu.
-
Estatistikak erabiltzea erraza da, SQL arrunta da. Eskaera bat bildu, bildu, bidali, begiratu.
-
Estatistikak galderak erantzuten laguntzen du. Galderarik baduzu, estatistiketara jotzen duzu - begiratu, ondorioak atera, emaitzak aztertu.
-
Eta esperimentatu. Eskaera asko, datu asko. Lehendik dagoen kontsultaren bat optimizatu dezakezu beti. Jatorrizkoa baino hobeto egokitzen zaizun eskaeraren bertsio propioa egin dezakezu eta erabili.
Erreferentziak
Artikuluan aurkitutako estekak baliozkoak, eta horietan oinarrituta, txostenean zeuden.
Egileak gehiago idatzi
(eus)
Estatistika-biltzailea
Sistema Administratzeko Funtzioak
Contrib moduluak
SQL utilitateak eta sql kodearen adibideak
Eskerrik asko guztioi zuen arretagatik!
Iturria: www.habr.com