Transskribaĵo de la 2015 raporto de Alexey Lesovsky "Profunda plonĝo en PostgreSQL-interna statistiko"
Malgarantio de la aŭtoro de la raporto: Mi rimarkas, ke tiu ĉi raporto estas datita de novembro 2015 - pasis pli ol 4 jaroj kaj pasis multe da tempo. La versio 9.4 priparolata en la raporto ne plu estas subtenata. Dum la pasintaj 4 jaroj, 5 novaj eldonoj estis publikigitaj en kiuj estas multaj novigoj, plibonigoj kaj ŝanĝoj koncerne statistikojn, kaj kelkaj el la materialo estas malmoderna kaj ne grava. Dum mi recenzas, mi provis marki ĉi tiujn lokojn por ne trompi la leganton. Mi ne reverkis ĉi tiujn fragmentojn, estas multaj kaj la rezulto estos tute alia raporto.
La PostgreSQL DBMS estas grandega mekanismo, kaj ĉi tiu mekanismo konsistas el multaj subsistemoj, kies kunordigita operacio rekte influas la agadon de la DBMS. Dum operacio, statistikoj kaj informoj pri la funkciado de komponantoj estas kolektitaj, kio ebligas al vi taksi la efikecon de PostgreSQL kaj preni mezurojn por plibonigi rendimenton. Tamen, ekzistas multe da ĉi tiu informo kaj ĝi estas prezentita en sufiĉe simpligita formo. Pretigi ĉi tiujn informojn kaj interpreti ĝin foje estas tute ne-triviala tasko, kaj la "zoo" de iloj kaj utilecoj povas facile konfuzi eĉ altnivelan DBA.
Bonan posttagmezon Mia nomo estas Aleksey. Kiel Ilya diris, mi parolos pri PostgreSQL-statistiko.
PostgreSQL-agado-statistiko. PostgreSQL havas du statistikojn. Agadstatistikoj kiuj estos diskutitaj. Kaj statistiko pri horaro pri distribuo de datumoj. Mi parolos specife pri agadstatistikoj de PostgreSQL, kiuj ebligas al ni juĝi rendimenton kaj iel plibonigi ĝin.
Mi diros al vi kiel efike uzi statistikojn por solvi diversajn problemojn, kiujn vi havas aŭ eble havas.
Kio ne estos en la raporto? En la raporto mi ne tuŝos statistikojn pri horaro, ĉar... Ĉi tio estas aparta temo por aparta raporto pri kiel datumoj estas konservitaj en la datumbazo kaj kiel la demandplanisto ricevas ideon pri la kvalitaj kaj kvantaj trajtoj de ĉi tiu datumo.
Kaj ne estos recenzoj pri iloj, mi ne komparos unu produkton kun alia. Ne estos reklamado. Ni lasu tion flanken.
Mi volas montri al vi, ke uzado de statistiko estas utila. Estas necesa. Ĝi estas sekura uzi. Ĉio, kion ni bezonas, estas regula SQL kaj baza scio pri SQL.
Kaj ni parolu pri kiaj statistikoj elekti por solvi problemojn.
Se ni rigardas PostgreSQL kaj rulas la komandon en la operaciumo por vidi procezojn, ni vidos "nigran skatolon". Ni vidos iujn procezojn, kiuj faras ion, kaj laŭ la nomo ni povas proksimume imagi, kion ili faras tie, kion ili faras. Sed, en esenco, ĝi estas nigra skatolo; ni ne povas rigardi enen.
Ni povas vidi la CPU-ŝarĝon top, ni povas rigardi memoruzadon de iuj sistemaj utilecoj, sed ni ne povos rigardi ene de PostgreSQL. Por tio ni bezonas aliajn ilojn.
Kaj daŭrigante plu, mi diros al vi kie la tempo estas pasigita. Se ni imagas PostgreSQL en la formo de tia diagramo, tiam ni povas respondi kie la tempo estas pasigita. Ĉi tiuj estas du aferoj: ĝi prilaboras klientajn petojn de aplikaĵoj kaj la fonajn taskojn, kiujn PostgreSQL plenumas por sin funkcii.
Se ni komencas rigardi la supran maldekstran angulon, ni povas vidi kiel klientpetoj estas procesitaj. La peto venas de la aplikaĵo kaj klienta sesio estas malfermita por plua laboro. La peto estas sendita al la planisto. La planisto konstruas demandplanon. Sendas ĝin plu por ekzekuto. Estas ia enigo/eligo de blokaj datumoj asociitaj kun tabeloj kaj indeksoj. La necesaj datumoj estas legitaj de la diskoj en memoron en specialan areon "komunigitajn bufrojn". La rezultoj de la peto, se ili estas ĝisdatigoj, forigo, estas registritaj en la transakcia protokolo en WAL. Iuj statistikaj informoj finiĝas en la protokolo aŭ statistika kolektanto. Kaj la rezulto de la peto estas resendita al la kliento. Post tio la kliento povas ripeti ĉion denove kun nova peto.
Kio pri fonaj taskoj kaj fonaj procezoj? Ni havas plurajn procezojn, kiuj konservas la datumbazon funkciantan en normala operacia reĝimo. Ĉi tiuj procezoj ankaŭ estos tuŝitaj en la raporto: aŭtomata vakuo, kontrolpunkto, reprodukti-rilataj procezoj, fonverkisto. Mi tuŝos ĉiun el ili dum mi raportos.
Kiuj problemoj estas kun statistiko?
- Estas multe da informoj. PostgreSQL 9.4 provizas 109 metrikojn por vidi statistikajn datumojn. Tamen, se la datumbazo konservas multajn tabelojn, skemojn, datumbazojn, tiam ĉiuj ĉi tiuj metrikoj devos esti multobligitaj per la responda nombro da tabeloj, datumbazoj. Tio estas, estas eĉ pli da informoj. Kaj estas tre facile droni en ĝi.
- La sekva problemo estas, ke statistikoj estas reprezentitaj per nombriloj. Se ni rigardas ĉi tiujn statistikojn, ni vidos konstante kreskantajn nombrilojn. Kaj se pasis multe da tempo de kiam la statistikoj estis rekomencigitaj, ni vidos valorojn en miliardoj. Kaj ili nenion diras al ni.
- Neniu rakonto. Se vi havis ian malsukceson, io falis antaŭ 15-30 minutoj, vi ne povos uzi statistikon kaj vidi kio okazis antaŭ 15-30 minutoj. Ĉi tio estas problemo.
- La manko de ilo enkonstruita en PostgreSQL estas problemo. La kernaj programistoj ne provizas ajnan ilon. Ili ne havas ion tian. Ili simple provizas statistikojn en la datumbazo. Uzu ĝin, petu ĝin, faru kion ajn vi volas.
- Ĉar ne ekzistas ilo enkonstruita en PostgreSQL, tio kaŭzas alian problemon. Multaj triaj iloj. Ĉiu kompanio, kiu havas pli-malpli rektajn manojn, provas verki sian propran programon. Kaj kiel rezulto, la komunumo havas multajn ilojn, kiuj povas esti uzataj por labori kun statistikoj. Kaj iuj iloj havas iujn kapablojn, aliaj iloj ne havas aliajn kapablojn, aŭ ekzistas iuj novaj kapabloj. Kaj okazas situacio, ke vi bezonas uzi du, tri aŭ kvar ilojn, kiuj interkovras unu la alian kaj havas malsamajn funkciojn. Ĉi tio estas tre malagrabla.
Kio sekvas el tio? Gravas povi rekte preni statistikojn, por ne dependi de programoj, aŭ iel mem plibonigi ĉi tiujn programojn: aldonu kelkajn funkciojn por akiri propran profiton.
Kaj vi bezonas bazan scion pri SQL. Por akiri iujn datumojn de statistiko, vi devas krei SQL-demandojn, t.e. vi devas scii kiel elekta kaj aliĝi estas kompilitaj.
Statistikoj rakontas al ni plurajn aferojn. Ili povas esti dividitaj en kategoriojn.
- La unua kategorio estas eventoj okazantaj en la datumbazo. Jen kiam iu evento okazas en la datumbazo: peto, aliro al tablo, aŭtomalplenigo, transdonoj, tiam ĉi tiuj estas ĉiuj eventoj. La nombriloj respondaj al ĉi tiuj eventoj estas pliigitaj. Kaj ni povas spuri ĉi tiujn eventojn.
- La dua kategorio estas la propraĵoj de objektoj kiel tabeloj kaj datumbazoj. Ili havas proprietojn. Ĉi tiu estas la grandeco de la tabloj. Ni povas spuri la kreskon de tabeloj kaj la kreskon de indeksoj. Ni povas vidi ŝanĝojn en dinamiko.
- Kaj la tria kategorio estas la tempo pasigita en la evento. Peto estas evento. Ĝi havas sian propran specifan mezurilon de daŭro. Komencis ĉi tie, finiĝis ĉi tie. Ni povas spuri ĝin. Aŭ la tempo necesas por legi blokon de disko aŭ skribi ĝin. Tiaj aferoj ankaŭ estas spuritaj.
Fontoj de statistiko estas prezentitaj jene:
- En komuna memoro (komunigitaj bufroj) ekzistas segmento por stoki senmovajn datumojn, ekzistas ankaŭ tiuj nombriloj, kiuj estas konstante pliigitaj kiam certaj eventoj okazas, aŭ iuj momentoj ekestas en la funkciado de la datumbazo.
- Ĉiuj ĉi tiuj nombriloj ne estas alireblaj por la uzanto kaj eĉ ne alireblaj por la administranto. Ĉi tiuj estas malaltnivelaj aferoj. Por aliri ilin, PostgreSQL disponigas interfacon en la formo de SQL-funkcioj. Ni povas fari elektajn ĵetojn uzante ĉi tiujn funkciojn kaj akiri ian metrikon (aŭ aron da metrikoj).
- Tamen, uzi ĉi tiujn funkciojn ne ĉiam estas oportuna, do funkcioj estas la bazo por vidoj (Vidoj). Ĉi tiuj estas virtualaj tabeloj, kiuj provizas statistikojn pri specifa subsistemo, aŭ pri certa aro de eventoj en la datumbazo.
- Ĉi tiuj enigitaj vidoj (Vidoj) estas la ĉefa uzantinterfaco por labori kun statistikoj. Ili disponeblas defaŭlte sen aldonaj agordoj, vi povas tuj uzi ilin, rigardi ilin kaj preni informojn de ili. Kaj poste estas kontribuoj. Kontribuoj estas oficialaj. Vi povas instali la postgresql-contrib-pakaĵon (ekzemple postgresql94-contrib), ŝargi la bezonatan modulon en la agordo, specifi parametrojn por ĝi, rekomenci PostgreSQL kaj vi povas uzi ĝin. (Noto. Depende de la distribuo, en lastatempaj versioj la kontrib-pakaĵo estas parto de la ĉefa pako).
- Kaj estas neoficiala kontribuo. Ili ne estas inkluzivitaj en la norma distribuo PostgreSQL. Ili devas aŭ esti kompilitaj aŭ instalitaj kiel biblioteko. La opcioj povas esti tre malsamaj, depende de tio, kion elpensis la programisto de ĉi tiu neoficiala kontribuo.
Ĉi tiu lumbildo prezentas ĉiujn tiujn VIEW kaj kelkajn el la funkcioj disponeblaj en PostgreSQL 9.4. Kiel ni vidas, estas multaj el ili. Kaj estas sufiĉe facile konfuziĝi se vi renkontas ĝin unuafoje.
Tamen, se ni prenas la antaŭan bildon Как тратится время на PostgreSQL kaj kongrua kun ĉi tiu listo, ni ricevas ĉi tiun bildon. Ni povas uzi ĉiun vidon (Vidoj) aŭ ĉiun funkcion por unu celo aŭ alia por akiri la respondajn statistikojn kiam PostgreSQL funkcias. Kaj ni jam povas ricevi iom da informoj pri la funkciado de la subsistemo.
La unua afero, kiun ni rigardos, estas pg_stat_database. Kiel ni povas vidi, ĉi tio estas agado. Estas multe da informoj en ĝi. La plej diversaj informoj. Kaj ĝi donas tre utilan scion pri tio, kio okazas en nia datumbazo.
Kiajn utilajn aferojn ni povas preni de tie? Ni komencu per la plej simplaj aferoj.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;La unua afero, kiun ni povas rigardi, estas la kaŝmemoro trafa procento. La trafo de kaŝmemoro estas utila metriko. Ĝi ebligas al vi taksi kiom da datumoj estas prenitaj de la komunaj bufroj-kaŝmemoro kaj kiom multe estas legita de disko.
Estas klare ke ju pli da kaŝmemortrafoj ni havas, des pli bone. Ni mezuras ĉi tiun metrikon kiel procento. Kaj, ekzemple, se nia procento de ĉi tiuj kaŝmemortrafoj estas pli ol 90%, tiam ĉi tio estas bona. Se ĝi falas sub 90%, tio signifas, ke ni ne havas sufiĉan memoron por teni la varman kapon de datumoj en memoro. Kaj por uzi ĉi tiujn datumojn, PostgreSQL estas devigita aliri la diskon kaj ĉi tio estas pli malrapida ol se la datumoj estus legitaj el memoro. Kaj vi devas pensi pri pliigo de la memoro: aŭ pliigi komunajn bufrojn, aŭ pliigi aparatan memoron (RAM).
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;Kion alian vi povas preni de ĉi tiu agado? Vi povas vidi anomaliojn okazantajn en la datumbazo. Kio estas montrita ĉi tie? Estas kommits, rollbacks, kreado de provizoraj dosieroj, ilia grandeco, blokadoj kaj konfliktoj.
Ni povas uzi ĉi tiun peton. Ĉi tiu SQL estas sufiĉe simpla. Kaj ni povas rigardi ĉi tiujn datumojn ĉi tie.
Kaj jen la sojlaj valoroj. Ni rigardas la proporcion de kommits kaj rollbacks. Commits estas la sukcesa konfirmo de transakcio. Rollbacks estas rollback, t.e. transakcio faris iom da laboro, streĉis la datumbazon, kalkulis ion, kaj tiam malsukceso okazis kaj la rezultoj de la transakcio estas forĵetitaj. Tio estas la nombro de retrovoj senĉese pliiĝanta estas malbona. Kaj vi devus iel eviti ilin, kaj redakti la kodon por ke tio ne okazu.
Konfliktoj rilatas al reproduktado. Kaj ili ankaŭ devus esti evititaj. Se vi havas kelkajn demandojn, kiuj estas ekzekutitaj sur kopio kaj konfliktoj aperas, tiam vi devas ordigi ĉi tiujn konfliktojn kaj vidi kio okazas. Detaloj troveblas en la protokoloj. Kaj forigu konfliktajn situaciojn por ke aplikaj petoj funkciu sen eraroj.
Interblokoj ankaŭ estas malbona situacio. Kiam petoj batalas por rimedoj, unu peto aliris unu rimedon kaj prenis la seruron, dua peto aliris la duan rimedon kaj ankaŭ prenis la seruron, kaj tiam ambaŭ petoj aliris la rimedojn de unu la alian kaj blokis atendante ke la najbaro liberigu la seruron. Ĉi tio ankaŭ estas problema situacio. Ili devas esti traktitaj je la nivelo de reverkado de aplikoj kaj seriigado de aliro al resursoj. Kaj se vi vidas, ke viaj blokadoj konstante pliiĝas, vi devas rigardi la detalojn en la protokoloj, analizi la situaciojn kiuj aperas kaj vidi kia estas la problemo.
Provizoraj dosieroj (temp_files) ankaŭ estas malbonaj. Kiam uzantpeto ne havas sufiĉe da memoro por alĝustigi funkciajn, provizorajn datumojn, ĝi kreas dosieron sur disko. Kaj ĉiuj operacioj, kiujn ĝi povus plenumi en provizora bufro en memoro, komencas esti faritaj sur la disko. Ĝi estas malrapida. Ĉi tio pliigas la demandan ekzekuttempon. Kaj la kliento, kiu sendis peton al PostgreSQL, ricevos respondon iom poste. Se ĉiuj ĉi tiuj operacioj estas faritaj en memoro, Postgres respondos multe pli rapide kaj la kliento atendos malpli.
Pg_stat_bgwriter - Ĉi tiu vidpunkto priskribas la funkciadon de du postgreSQL-fonaj subsistemoj: ĉi tio checkpointer и background writer.
Unue, ni rigardu la kontrolpunktojn, la tn. checkpoints. Kio estas kontrolpunktoj? Kontrolpunkto estas pozicio en la transakcia protokolo indikante, ke ĉiuj datenŝanĝoj registritaj en la protokolo estis sukcese sinkronigitaj kun la datumoj sur disko. La procezo, depende de la laborkvanto kaj agordoj, povas esti longa kaj plejparte konsistas el sinkronigado de malpuraj paĝoj en komunaj bufroj kun datumdosieroj sur disko. Por kio ĝi estas? Se PostgreSQL konstante alirus la diskon kaj alportus datumojn de tie, kaj skribus datumojn pri ĉiu aliro, ĝi estus malrapida. Tial PostgreSQL havas memoran segmenton, kies grandeco dependas de la agordoj en la agordo. Postgres konservas vivajn datumojn en ĉi tiu memoro por posta prilaborado aŭ pridemandado. En kazo de petoj por ŝanĝi la datumojn, ĝi estas ŝanĝita. Kaj ni ricevas du versiojn de la datumoj. Unu estas en nia memoro, la alia estas sur disko. Kaj periode vi devas sinkronigi ĉi tiujn datumojn. Ni devas sinkronigi tion, kio estas ŝanĝita en memoro al disko. Por tio vi bezonas kontrolpunktojn.
Kontrolpunkto ekzamenas komunajn bufrojn, markas malpurajn paĝojn, kiujn ili bezonas por kontrolpunkto. Tiam ĝi lanĉas duan enirpermesilon tra la komunaj bufroj. Kaj la paĝojn, kiuj estas markitaj por kontrolpunkto, ĝi jam sinkronigas ilin. Tiel la datumoj estas sinkronigitaj kun la disko.
Estas du specoj de transirejoj. Unu kontrolpunkto estas ekzekutita kun tempo-tempo. Ĉi tiu transirejo estas utila kaj bona - checkpoint_timed. Kaj estas transirejoj laŭ postulo - checkpoint required. Ĉi tiu kontrolpunkto okazas kiam ni havas tre grandan datuman rekordon. Ni registris multajn transakciajn protokolojn. Kaj PostgreSQL kredas, ke ĝi devas sinkronigi ĉion ĉi kiel eble plej rapide, fari kontrolpunkton kaj pluiri.
Kaj se vi rigardis la statistikojn pg_stat_bgwriter kaj vidis, kion vi havas checkpoint_req estas multe pli granda ol checkpoint_timed, tiam ĉi tio estas malbona. Kial malbona? Ĉi tio signifas, ke PostgreSQL estas sub konstanta streĉo kiam ĝi bezonas skribi datumojn al disko. Timeout checkpoint estas malpli streĉa kaj estas farita laŭ la interna horaro kaj estas ia disvastigita laŭlonge de la tempo. PostgreSQL havas la kapablon paŭzi laboron kaj ne streĉi la disksubsistemon. Ĉi tio estas utila por PostgreSQL. Kaj demandoj kiuj estas efektivigitaj dum kontrolpunkto ne spertos streson pro la fakto, ke la disksubsistemo estas okupata.
Kaj por ĝustigi la kontrolpunkton estas tri parametroj:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
Ili permesas vin reguligi la funkciadon de kontrolpunktoj. Sed mi ne traktos ilin. Ilia influo estas aparta temo.
Averto: La versio 9.4 priparolata en la raporto ne plu rilatas. En modernaj versioj de PostgreSQL la parametro checkpoint_segments anstataŭigita per parametroj min_wal_size и max_wal_size.
La sekva subsistemo estas la fonverkisto − background writer. Kion li faras? Ĝi funkcias konstante en senfina buklo. Skanas paĝojn en komunaj bufroj kaj forĵetas malpurajn paĝojn kiujn ĝi trovas al disko. Tiel, ĝi helpas la transirejon fari malpli da laboro dum transirejo ekzekuto.
Por kio alia ĝi necesas? Ĝi provizas la bezonon de malplenaj paĝoj en komunaj bufroj, se ili estas subite postulataj (en grandaj kvantoj kaj tuj) por alĝustigi datumojn. Supozu, ke okazos situacio kiam malplenaj paĝoj estis postulataj por plenumi peton kaj ili jam estis en la komunaj bufroj. Postgresa backend li nur prenas ilin kaj uzas ilin, li ne devas mem purigi ion. Sed se subite ne ekzistas tiaj paĝoj, la backend paŭzas la laboron kaj komencas serĉi paĝojn por forĵeti ilin sur diskon kaj preni ilin por siaj propraj bezonoj - kio negative influas la tempon de la nune plenumanta peto. Se vi vidas, ke vi havas parametron maxwritten_clean granda, tio signifas, ke la fonverkisto ne faras sian laboron kaj vi devas pliigi la parametrojn bgwriter_lru_maxpages, por ke li povu fari pli da laboro en unu ciklo, malbari pli da paĝoj.
Kaj alia tre utila indikilo estas buffers_backend_fsync. Backends ne fsync ĉar ĝi estas malrapida. Ili pasas fsync supren laŭ la IO-staka kontrolpunkto. La kontrolpunkto havas sian propran voston, ĝi periode prilaboras fsync kaj sinkronigas paĝojn en memoro kun dosieroj sur disko. Se la atendovico ĉe la kontrolpunkto estas granda kaj plena, tiam la backend estas devigita fari fsync mem kaj ĉi tio malrapidigas la laboron de la backend, t.e. la kliento ricevos respondon poste ol ĝi povus. Se vi vidas, ke via valoro estas pli granda ol nulo, tiam ĉi tio jam estas problemo kaj vi devas atenti la agordojn de la fonverkisto kaj ankaŭ taksi la agadon de la disksubsistemo.
Averto: _La sekva teksto priskribas la statistikajn vidojn asociitajn kun reproduktado. La plej multaj el la vido- kaj funkcionomoj estis renomitaj en Postgres 10. La esenco de la renomado estis anstataŭigi xlog sur wal и location sur lsn en funkcioj/vidnomoj, ktp. Aparta ekzemplo, funkcio pg_xlog_location_diff() estis renomita al pg_wal_lsn_diff()._
Ni ankaŭ havas multajn aferojn ĉi tie. Sed ni bezonas nur erojn rilatajn al loko.
Se ni vidas, ke ĉiuj valoroj estas egalaj, tiam ĉi tio estas ideala opcio kaj la kopio ne restas malantaŭ la majstro.
Ĉi tiu deksesuma pozicio ĉi tie estas la pozicio en la transakcia protokolo. Ĝi konstante pliiĝas se estas ia aktiveco en la datumbazo: enmetoj, forigo ktp.
сколько записано 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());Se ĉi tiuj aferoj estas malsamaj, tiam estas ia malfruo. Malfruo estas la malfruo inter la kopio kaj la majstro, t.e. la datumoj malsamas inter serviloj.
Estas tri kialoj por la malfruo:
- Ĉi tiu disksubsistemo ne povas elteni registradosiersinkronigadon.
- Ĉi tiuj estas eblaj retaj eraroj, aŭ retaj troŝarĝoj, kiam la datumoj ne havas tempon por atingi la kopion kaj ĝi ne povas reprodukti ĝin.
- Kaj la procesoro. La procesoro estas tre malofta kazo. Kaj mi vidis ĉi tion du aŭ tri fojojn, sed tio ankaŭ povas okazi.
Kaj jen tri demandoj, kiuj ebligas al ni uzi statistikojn. Ni povas taksi kiom ni registris en la transakcia protokolo. Estas tia funkcio pg_xlog_location_diff kaj ni povas taksi la reproduktan malfruon en bajtoj kaj sekundoj. Ni ankaŭ uzas la valoron de ĉi tiu vidpunkto (Vidoj) por ĉi tio.
Notu: _Anstataŭ pg_xlog_locationLa funkcio diff() povas uzi la operatoron de subtraho kaj subtrahi unu lokon de alia. Komforta.
Estas unu punkto kun la malfruo, kiu estas en sekundoj. Se ne estas agado sur la majstro, la transakcio estis tie antaŭ ĉirkaŭ 15 minutoj kaj ne ekzistas aktiveco, kaj se ni rigardas ĉi tiun malfruon sur la kopio, ni vidos malfruon de 15 minutoj. Ĉi tio estas memorinda. Kaj ĉi tio povas esti konfuza kiam vi rigardas ĉi tiun malfruon.
Pg_stat_all_tables estas alia utila vido. Ĝi montras statistikojn sur tabeloj. Kiam ni havas tabelojn en la datumbazo, estas iom da aktiveco kun ĝi, kelkaj agoj, ni povas akiri ĉi tiun informon de ĉi tiu vido.
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;La unua afero, kiun ni povas rigardi, estas la sinsekvaj skanadoj trans la tablo. La nombro mem post ĉi tiuj paŝoj ne estas nepre malbona kaj ne estas indikilo, ke ni devas fari ion.
Tamen, ekzistas dua metriko - seq_tup_read. Ĉi tio estas la nombro da vicoj resenditaj de la sinsekva skanado. Se la averaĝa nombro superas 1, 000, 10, 000, tiam ĉi tio jam estas indikilo, ke eble vi bezonas konstrui indekson ie, por ke konsultoj baziĝu sur la indekso, aŭ eblas optimumigi demandojn, kiuj uzas tiajn sinsekvajn skanaĵojn tiel. ke tio ne okazas estis.
Simpla ekzemplo - ni diru peton kun granda OFFSET kaj LIMIT kostoj. Ekzemple, 100 vicoj en tabelo estas skanitaj kaj post tio 000 postulataj vicoj estas prenitaj, kaj la antaŭaj skanitaj vicoj estas forĵetitaj. Ĉi tio ankaŭ estas malbona kazo. Kaj tiaj demandoj devas esti optimumigitaj. Kaj jen simpla SQL-demando, kie vi povas rigardi ĉi tion kaj taksi la rezultajn nombrojn.
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;Tabelgrandecoj ankaŭ povas esti akiritaj uzante ĉi tiun tabelon kaj uzante pliajn funkciojn pg_total_relation_size(), pg_relation_size().
Ĝenerale, ekzistas metakomandoj dt и di, kiu povas esti uzata en PSQL kaj ankaŭ vidi la grandecojn de tabeloj kaj indeksoj.
Tamen, uzi funkciojn helpas nin rigardi la grandecojn de tabeloj, eĉ konsiderante indeksojn, aŭ sen konsideri indeksojn, kaj jam fari iujn taksojn bazitajn sur la kresko de la datumbazo, t.e. kiel ĝi kreskas, kun kia intenseco, kaj eltiri kelkajn konkludojn pri grandeco-optimumigo.
Registrado de aktiveco. Kio estas registrado? Ni rigardu la operacion UPDATE – la operacio de ĝisdatigo de vicoj en tabelo. Fakte, ĝisdatigo estas du operacioj (aŭ eĉ pli). Ĉi tio enigas novan version de la vico kaj markas la malnovan version de la vico kiel malnoviĝinta. Poste, la aŭtomata vakuo venos kaj purigos ĉi tiujn malmodernajn versiojn de la linioj, markante ĉi tiun lokon kiel disponebla por reuzo.
Krome, ĝisdatigo ne temas nur pri ĝisdatigo de tabelo. Ĉi tio ankaŭ estas indeksa ĝisdatigo. Se vi havas multajn indeksojn sur la tablo, tiam dum ĝisdatigo ĉiuj indeksoj kiuj inkluzivas kampojn ĝisdatigitajn en la konsulto ankaŭ devos esti ĝisdatigitaj. Ĉi tiuj indeksoj ankaŭ havos malnoviĝintajn versiojn de vicoj, kiuj devos esti purigitaj.
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;Kaj pro ĝia nova dezajno, UPDATE estas peza operacio. Sed ili povas esti pli facilaj. Manĝu hot updates. Ili aperis en PostgreSQL-versio 8.3. Kaj kio estas ĉi tio? Ĉi tio estas malpeza ĝisdatigo, kiu ne kaŭzas indeksojn esti rekonstruitaj. Tio estas, ni ĝisdatigis la registron, sed nur la registro en la paĝo (kiu apartenas al la tabelo) estis ĝisdatigita, kaj la indeksoj ankoraŭ montras al la sama registro en la paĝo. Estas iom interesa mastruma logiko: kiam venas vakuo, ĝi kreas ĉi tiujn ĉenojn hot rekonstruas kaj ĉio daŭre funkcias sen ĝisdatigi la indeksojn, kaj ĉio okazas kun malpli malŝparo de rimedoj.
Kaj kiam vi n_tup_hot_upd granda, tiam ĝi estas tre bona. Ĉi tio signifas, ke malpezaj ĝisdatigoj superregas kaj ĉi tio estas pli malmultekosta por ni laŭ rimedoj kaj ĉio estas en ordo.
ALTER TABLE table_name SET (fillfactor = 70);Kiel pliigi volumon hot updateov? Ni povas uzi fillfactor. Ĝi determinas la grandecon de la rezervita libera spaco kiam plenigas paĝon en tabelo uzante INSERT-ojn. Kiam enmetoj estas aldonitaj al tabelo, ili tute plenigas la paĝon kaj ne lasas malplenan spacon. Tiam nova paĝo estas reliefigita. La datumoj denove estas plenigitaj. Kaj ĉi tio estas la defaŭlta konduto, fillfactor = 100%.
Ni povas fari la plenigfaktoron 70%. Tio estas, dum enmetoj, nova paĝo estis reliefigita, sed nur 70% de la paĝo estis plenigita. Kaj ni restas 30% kiel rezervo. Kiam vi bezonos fari ĝisdatigon, ĝi plej verŝajne okazos sur la sama paĝo, kaj la nova versio de la linio taŭgos sur la sama paĝo. Kaj varma_ĝisdatigo estos farita. Ĉi tio faciligas skribi sur tabeloj.
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));Aŭtovakua atendovico. Aŭtovakuo estas subsistemo por kiu estas tre malmultaj statistikoj en PostgreSQL. Ni nur povas vidi en la tabeloj en pg_stat_activity kiom da vakuoj ni havas nuntempe. Tamen, estas tre malfacile kompreni kiom da tabloj estas en la vico tuj.
Notu: _De Postgres 10, la situacio kun Vatovac-spurado multe pliboniĝis - aperis la pg_stat_progress-vido.vakuo, kiu signife simpligas la temon de monitorado de la aŭto vakuo.
Ni povas uzi ĉi tiun simpligitan demandon. Kaj ni povas vidi kiam la vakuo devos esti farita. Sed kiel kaj kiam komenciĝu la vakuo? Ĉi tiuj estas la heredaj versioj de la linioj, pri kiuj mi antaŭe parolis. Ĝisdatigo okazis, nova versio de la linio estis enmetita. Malmoderna versio de la ŝnuro aperis. En la tablo pg_stat_user_tables ekzistas tia parametro n_dead_tup. Ĝi montras la nombron da "mortintaj" linioj. Kaj tuj kiam la nombro da mortaj vicoj fariĝos pli granda ol certa sojlo, aŭtomata vakuo venos al la tablo.
Kaj kiel oni kalkulas ĉi tiun sojlon? Ĉi tio estas tre specifa procento de la totala nombro da vicoj en la tabelo. Estas parametro autovacuum_vacuum_scale_factor. Ĝi determinas la procenton. Ni diru 10% + estas plia baza sojlo de 50 linioj. Kaj kio okazas? Kiam ni havas pli da senvivaj vicoj ol "10% + 50" de ĉiuj vicoj en la tabelo, tiam ni metas la tablon sur aŭtomatan vakuon.
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));Tamen, estas unu punkto. Bazaj sojloj por parametroj av_base_thresh и av_scale_factor povas esti asignita individue. Kaj, sekve, la sojlo ne estos tutmonda, sed individua por la tablo. Tial, por kalkuli, vi devas uzi lertaĵojn kaj lertaĵojn. Kaj se vi interesiĝas, tiam vi povas rigardi la sperton de niaj kolegoj el Avito (la ligilo sur la glito estas nevalida kaj ĝisdatigita en la teksto).
Ili skribis por , kiu konsideras ĉi tiujn aferojn. Tie estas dufolia piedtuko. Sed ĝi kalkulas ĝuste kaj sufiĉe efike permesas al ni taksi, kie ni bezonas multe da vakuo por tabloj kie estas malmulte.
Kion ni povas fari pri ĝi? Se ni havas grandan vicon kaj la aŭtovakuo ne povas elteni, tiam ni povas pliigi la nombron da vakuaj laboristoj aŭ simple fari la vakuon pli agresema., por ke ĝi ekfunkciigas pli frue, prilaboras la tablon en malgrandaj pecoj. Kaj tiel la vico malpliiĝos. — La ĉefa afero ĉi tie estas kontroli la ŝarĝon sur la diskoj, ĉar... vakuo ne estas senpaga afero, kvankam kun la apero de SSD/NVMe-aparatoj la problemo fariĝis malpli rimarkebla.
Pg_stat_all_indexes estas statistiko pri indeksoj. Ŝi ne estas granda. Kaj ni povas uzi ĝin por akiri informojn pri la uzo de indeksoj. Kaj ekzemple, ni povas determini kiujn indeksojn ni havas kromajn.
Kiel mi jam diris, ĝisdatigo ne estas nur ĝisdatigo de tabeloj, ĝi ankaŭ estas ĝisdatigo de indeksoj. Sekve, se ni havas multajn indeksojn sur la tabelo, tiam ĝisdatigante la vicojn en la tabelo, la indeksoj de la indeksitaj kampoj ankaŭ devas esti ĝisdatigitaj, kaj se ni havas neuzatajn indeksojn, por kiuj ne estas indeksaj skanadoj, tiam ili pendas kiel balasto. Kaj ni devas forigi ilin. Por tio ni bezonas kampon idx_scan. Ni simple rigardas la nombron da indekskanadoj. Se indeksoj havas nul-skanadon dum relative longa periodo de statistika stokado (almenaŭ 2-3 semajnoj), tiam plej verŝajne ĉi tiuj estas malbonaj indeksoj, ni devas forigi ilin.
Notu: Serĉante neuzatajn indeksojn en la kazo de fluantaj reproduktaj aretoj, vi devas kontroli ĉiujn grapolnodojn, ĉar statistikoj ne estas tutmondaj, kaj se la indekso ne estas uzata sur la majstro, tiam ĝi povas esti uzata sur kopioj (se estas ŝarĝo tie).
Du ligiloj:
Ĉi tiuj estas pli altnivelaj demandekzemploj pri kiel serĉi neuzatajn indeksojn.
La dua ligilo estas sufiĉe interesa peto. Estas tre ne-triviala logiko tie. Mi rekomendas ĝin por referenco.
Kion alian indas resumi uzante indeksojn?
-
Neuzataj indeksoj estas malbonaj.
-
Ili okupas spacon.
-
Malrapidigi ĝisdatigajn operaciojn.
-
Kroma laboro por la vakuo.
Se ni forigas neuzatajn indeksojn, ni nur plibonigos la datumbazon.
La sekva prezento estas pg_stat_activity. Ĉi tio estas analogo de la utileco ps, nur en PostgreSQL. Se ps'om vi do rigardas la procezojn en la operaciumo pg_stat_activity Ĝi montros al vi la agadon ene de PostgreSQL.
Kiajn utilajn aferojn ni povas preni de tie?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;Ni povas vidi la ĝeneralan agadon, kio okazas en la datumbazo. Ni povas fari novan deplojon. Ĉio ĉi tie eksplodis, novaj konektoj ne estas akceptitaj, eraroj verŝas en la aplikaĵon.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;Ni povas ruli demandon kiel ĉi tion kaj vidi la totalan procenton de konektoj rilate al la maksimuma ligolimo kaj vidi kiu havas la plej multajn konektoj. Kaj en ĉi tiu donita kazo ni vidas tiun uzanton cron_role malfermis 508 ligojn. Kaj io okazis al li tie. Ni devas trakti ĝin kaj rigardi ĝin. Kaj estas tute eble, ke ĉi tio estas ia anomalia nombro da konektoj.
Se ni havas laborŝarĝon de OLTP, la demandoj devus esti rapidaj, tre rapidaj kaj ne estu longaj demandoj. Tamen, se longaj demandoj aperas, tiam baldaŭ estas nenio por zorgi, sed Longtempe, longaj demandoj damaĝas la datumbazon; ili pliigas la ŝvelan efikon de tabeloj kiam tabelfragmentiĝo okazas. Vi devas forigi ambaŭ ŝvelaĵojn kaj longajn demandojn.
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;Bonvolu noti: kun ĉi tiu peto ni povas identigi longajn demandojn kaj transakciojn. Ni uzas la funkcion clock_timestamp() por determini operacian tempon. Longaj demandoj, kiujn ni trovis, ni povas memori ilin, plenumi ilin explain, rigardu la planojn kaj iel optimumigu. Ni malkonstruas la nunajn longajn petojn kaj pluiras kun niaj vivoj.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Malbonaj transakcioj estas transakcioj en la neaktiva en transakcio kaj neaktiva en transakciaj (abortitaj) ŝtatoj.
Kion ĝi signifas? Transakcioj havas plurajn statojn. Kaj unu el ĉi tiuj statoj povas esti supozita iam ajn. Estas kampo por difini ŝtatojn state en ĉi tiu prezento. Kaj ni uzas ĝin por determini la staton.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Kaj, kiel mi diris supre, ĉi tiuj du ŝtatoj idle in transaction kaj idle in transaction (abortita) estas malbonaj. Kio ĝi estas? Jen kiam la aplikaĵo malfermis transakcion, faris kelkajn agojn kaj okupiĝis pri sia komerco. La transakcio restas malfermita. Ĝi pendas, nenio okazas en ĝi, ĝi prenas la konekton, ŝlosas sur ŝanĝitaj vicoj kaj eble pliigas la ŝvelaĵon de aliaj tabloj, pro la arkitekturo de la transakcia motoro Postrges. Kaj tiaj transakcioj ankaŭ devus esti pafitaj, ĉar ili estas ĝenerale malutilaj, ĉiukaze.
Se vi vidas, ke vi havas pli ol 5-10-20 el ili en via datumbazo, tiam vi devas zorgi kaj komenci fari ion kun ili.
Ĉi tie ni ankaŭ uzas por la kalkultempo clock_timestamp(). Ni pafas transakciojn kaj optimumigas la aplikaĵon.
Kiel mi diris supre, blokado estas kiam du aŭ pli da transakcioj batalas por unu aŭ grupo de rimedoj. Por tio ni havas kampon waiting kun bulea valoro true aŭ false.
Vere - tio signifas, ke la procezo estas pritraktata, io devas esti farita. Kiam procezo atendas, tio signifas, ke la kliento, kiu iniciatis ĉi tiun procezon, ankaŭ atendas. La kliento sidas en la retumilo kaj ankaŭ atendas.
Averto: _De postgresa versio 9.6 kampo waiting forigita kaj du pliaj informaj kampoj aldonitaj anstataŭe wait_event_type и wait_event._
Kion mi faru? Se vi vidas veron dum longa tempo, tio signifas, ke vi devas forigi tiajn petojn. Ni simple pafas tiajn transakciojn. Ni skribas al la programistoj, ke ili devas iel optimumigi por ke ne estu kuro por rimedoj. Kaj tiam la programistoj optimumigas la aplikaĵon por ke tio ne okazu.
Kaj la ekstrema, sed eble ne-mortiga kazo estas okazo de blokiĝo. Du transakcioj ĝisdatigis du rimedojn, poste aliris ilin denove, ĉi-foje al kontraŭaj rimedoj. En ĉi tiu kazo, PostgreSQL mortigas la transakcion mem por ke alia povu daŭrigi labori. Ĉi tio estas senelirejo kaj ŝi ne povas eltrovi ĝin memstare. Tial PostgreSQL estas devigita preni ekstremajn mezurojn.
Kaj jen du demandoj, kiuj permesas vin spuri blokadon. Ni uzas vidon pg_locks, kiu permesas vin spuri pezajn serurojn.
Kaj la unua ligilo estas la peta teksto mem. Ĝi estas sufiĉe longa.
Kaj la dua ligilo estas artikolo pri seruroj. Estas utile legi, ĝi estas tre interesa.
Kion do ni vidas? Ni vidas du petojn. Transakcio kun ALTER TABLE estas bloka transakcio. Ĝi komenciĝis, sed ne finiĝis, kaj la aplikaĵo, kiu registris ĉi tiun transakcion, faras aliajn aferojn ie. Kaj la dua peto estas ĝisdatigo. Li atendas ke la ŝanĝtablo finiĝos antaŭ ol li povas daŭrigi sian laboron.
Jen kiel ni povas ekscii, kiu ŝlosis kiun, tenas kiun, kaj ni povas trakti ĝin plu.
La sekva modulo estas pg_stat_statements. Kiel mi diris, ĉi tio estas modulo. Por uzi ĝin, vi devas ŝargi ĝian bibliotekon en la agordo, rekomenci PostgreSQL, instali la modulon (kun unu komando) kaj tiam ni havos novan vidon.
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;Kion ni povas preni de tie? Se ni parolas pri simplaj aferoj, ni povas preni la mezan demandan ekzekuttempon. Tempo kreskas, kio signifas, ke PostgreSQL malrapide respondas kaj ni devas fari ion.
Ni povas rigardi la plej aktivajn skribajn transakciojn en la datumbazo, kiuj ŝanĝas datumojn en komunaj bufroj. Vidu kiu ĝisdatigas aŭ forigas datumojn tie.
Kaj ni povas simple rigardi malsamajn statistikojn por ĉi tiuj petoj.
Ni pg_stat_statements Ni uzas ĝin por konstrui raportojn. Ni restarigas la statistikon unufoje tage. Ni amasigu ĝin. Antaŭ restarigi la statistikon venontfoje, ni konstruu raporton. Jen ligo al la raporto. Vi povas rigardi ĝin.
Kion ni faras? Ni kalkulas ĝeneralajn statistikojn por ĉiuj petoj. Tiam, por ĉiu peto, ni kalkulas ĝian individuan kontribuon al ĉi tiuj ĝeneralaj statistikoj.
Kaj kion ni povas rigardi? Ni povas rigardi la tutan ekzekuttempon de ĉiuj petoj de aparta tipo kontraŭ la fono de ĉiuj aliaj petoj. Ni povas rigardi la uzadon de CPU kaj I/O-rimedo rilate al la ĝenerala bildo. Kaj jam optimumigu ĉi tiujn demandojn. Ni konstruas la plej bonajn demandojn surbaze de ĉi tiu raporto kaj jam pripensas kion optimumigi.
Kion ni lasis malantaŭ la scenoj? Restas ankoraŭ kelkaj aliĝoj, kiujn mi ne konsideris, ĉar la tempo estas limigita.
Ekzistas pgstattuple estas ankaŭ aldona modulo de la norma kontribuo-pakaĵo. Ĝi permesas al vi taksi bloat tabloj, tiel nomataj tabelfragmentiĝo. Kaj se estas multe da fragmentiĝo, vi devas forigi ĝin kaj uzi malsamajn ilojn. Kaj funkcio pgstattuple funkcias dum longa tempo. Kaj ju pli da tabloj estas, des pli longe ĝi funkcios.
La sekva kontribuo estas pg_buffercache. Ĝi permesas vin inspekti komunajn bufrojn: kiom intense kaj por kiuj tabeloj bufropaĝoj estas utiligitaj. Kaj ĝi simple permesas vin rigardi en komunajn bufrojn kaj taksi kio okazas tie.
La sekva modulo estas pgfincore. Ĝi permesas malaltnivelajn tabeloperaciojn per sistemvoko mincore(), t.e. ĝi permesas al vi ŝargi tabelon en komunajn bufrojn, aŭ malŝarĝi ĝin. Kaj, interalie, ĝi permesas inspekti la paĝan kaŝmemoron de la operaciumo, t.e. kiom da spaco okupas la tabelo en la paĝa kaŝmemoro, en komunaj bufroj, kaj simple permesas taksi la laborŝarĝon de la tabelo.
Sekva modulo - pg_stat_kcache. Ĝi ankaŭ uzas sisteman vokon getrusage(). Kaj ĝi efektivigas ĝin antaŭ kaj post kiam la peto estas plenumita. Kaj en la rezulta statistiko, ĝi permesas al ni taksi kiom nia peto elspezis en disko I/O, t.e., operacioj kun la dosiersistemo kaj rigardas la procesoron uzadon. Tamen la modulo estas juna (tuso) kaj por sia funkciado ĝi postulas PostgreSQL 9.4 kaj pg_stat_statements, kiujn mi antaŭe menciis.
-
Scii kiel uzi statistikon estas utila. Vi ne bezonas triajn programojn. Vi povas eniri, vidi, fari ion, plenumi ion.
-
Uzi statistikon ne estas malfacila, ĝi estas nur regula SQL. Vi kolektis la peton, kompilis ĝin, sendis ĝin, rigardis ĝin.
-
Statistikoj helpas respondi demandojn. Se vi havas demandojn, vi turnas vin al statistiko - rigardu, faru konkludojn, analizu la rezultojn.
-
Kaj eksperimentu. Estas multaj petoj, multaj datumoj. Vi ĉiam povas optimumigi ekzistantan demandon. Vi povas fari vian propran version de la peto kiu konvenas al vi pli ol la originalo kaj uzi ĝin.
referencoj
Taŭgaj ligiloj, kiuj troviĝis en la artikolo, bazitaj sur materialoj, estis en la raporto.
Aŭtoro skribu pli
(epo)
La Statistika Kolektanto
Sistemo-Administraj Funkcioj
Contrib-moduloj
SQL-utiloj kaj sql-kodaj ekzemploj
Dankon al ĉiuj pro via atento!
fonto: www.habr.com