🥇Njia kwa kina katika takwimu za ndani za PostgreSQL. Alexey Lesovsky

Nakala ya ripoti ya Alexey Lesovsky ya 2015 "Kuzama kwa kina katika takwimu za ndani za PostgreSQL"

Kanusho kutoka kwa mwandishi wa ripoti: Ninaona kuwa ripoti hii ni ya Novemba 2015 - zaidi ya miaka 4 imepita na muda mwingi umepita. Toleo la 9.4 lililojadiliwa katika ripoti halitumiki tena. Katika kipindi cha miaka 4 iliyopita, matoleo 5 mapya yametolewa ambapo kuna ubunifu mwingi, maboresho na mabadiliko kuhusu takwimu, na baadhi ya nyenzo zimepitwa na wakati na hazifai. Nilipokuwa nikipitia, nilijaribu kuweka alama kwenye maeneo haya ili nisimpotoshe msomaji. Sikuandika tena vifungu hivi, kuna mengi yao na matokeo yatakuwa ripoti tofauti kabisa.

PostgreSQL DBMS ni utaratibu mkubwa, na utaratibu huu una mifumo ndogo nyingi, operesheni iliyoratibiwa ambayo huathiri moja kwa moja utendaji wa DBMS. Wakati wa operesheni, takwimu na taarifa kuhusu uendeshaji wa vipengele hukusanywa, ambayo inakuwezesha kutathmini ufanisi wa PostgreSQL na kuchukua hatua za kuboresha utendaji. Walakini, kuna habari nyingi hii na imewasilishwa kwa fomu iliyorahisishwa. Kusindika habari hii na kuifasiri wakati mwingine ni kazi isiyo ya kawaida kabisa, na "zoo" ya zana na huduma zinaweza kuchanganya kwa urahisi hata DBA ya juu.

Habari za mchana Jina langu ni Aleksey. Kama Ilya alisema, nitazungumza juu ya takwimu za PostgreSQL.

Takwimu za shughuli za PostgreSQL. PostgreSQL ina takwimu mbili. Takwimu za shughuli zitakazojadiliwa. Na takwimu za kiratibu kuhusu usambazaji wa data. Nitazungumza haswa kuhusu takwimu za shughuli za PostgreSQL, ambazo huturuhusu kuhukumu utendaji na kwa namna fulani kuuboresha.

Nitakuambia jinsi ya kutumia takwimu kwa ufanisi kutatua matatizo mbalimbali ambayo unayo au unaweza kuwa nayo.

Ni nini hakitakuwa kwenye ripoti? Katika ripoti sitagusa takwimu za wapangaji, kwa sababu... Hii ni mada tofauti kwa ripoti tofauti kuhusu jinsi data inavyohifadhiwa kwenye hifadhidata na jinsi mpangaji hoja anapata wazo la sifa za ubora na kiasi za data hii.

Na hakutakuwa na hakiki za zana, sitalinganisha bidhaa moja hadi nyingine. Hakutakuwa na matangazo. Tuweke hilo kando.

Ninataka kukuonyesha kuwa kutumia takwimu ni muhimu. Ni muhimu. Ni salama kutumia. Tunachohitaji ni SQL ya kawaida na maarifa ya kimsingi ya SQL.

Na hebu tuzungumze juu ya takwimu gani za kuchagua kutatua matatizo.

Ikiwa tutaangalia PostgreSQL na kuendesha amri kwenye mfumo wa uendeshaji ili kutazama michakato, tutaona "sanduku nyeusi". Tutaona baadhi ya michakato inayofanya kitu, na kutoka kwa jina tunaweza kufikiria wanachofanya huko, kile wanachofanya. Lakini, kwa asili, ni sanduku nyeusi; hatuwezi kuangalia ndani.

Tunaweza kuona mzigo wa CPU ndani top, tunaweza kuangalia utumiaji wa kumbukumbu na baadhi ya huduma za mfumo, lakini hatutaweza kuangalia ndani ya PostgreSQL. Kwa hili tunahitaji zana zingine.

Na kuendelea zaidi, nitakuambia ambapo wakati unatumika. Ikiwa tunafikiria PostgreSQL katika mfumo wa mchoro kama huo, basi tunaweza kujibu ambapo wakati unatumika. Haya ni mambo mawili: ni kushughulikia maombi ya mteja kutoka kwa programu na kazi za usuli ambazo PostgreSQL hufanya ili kujiendesha yenyewe.

Ikiwa tutaanza kutazama kona ya juu kushoto, tunaweza kuona jinsi maombi ya mteja yanavyochakatwa. Ombi linatokana na programu na kikao cha mteja kinafunguliwa kwa kazi zaidi. Ombi linatumwa kwa kipanga ratiba. Mratibu huunda mpango wa hoja. Inatuma zaidi kwa utekelezaji. Kuna aina fulani ya data ya kuzuia ingizo/pato inayohusishwa na majedwali na faharasa. Data muhimu inasomwa kutoka kwa diski kwenye kumbukumbu kwenye eneo maalum "buffers zilizoshirikiwa". Matokeo ya ombi, ikiwa ni masasisho, kufuta, yameandikwa katika logi ya shughuli katika WAL. Baadhi ya taarifa za takwimu huishia kwenye kumbukumbu au mkusanyaji wa takwimu. Na matokeo ya ombi yanatumwa kwa mteja. Baada ya hapo mteja anaweza kurudia kila kitu tena na ombi jipya.

Vipi kuhusu kazi za usuli na michakato ya usuli? Tuna michakato kadhaa ambayo huweka hifadhidata na kufanya kazi katika hali ya kawaida ya kufanya kazi. Michakato hii pia itaguswa katika ripoti: otomatiki, kiashiria cha ukaguzi, michakato inayohusiana na urudufishaji, mwandishi wa usuli. Nitagusa kila mmoja wao ninaporipoti.

Je, kuna matatizo gani na takwimu?

Kuna habari nyingi. PostgreSQL 9.4 hutoa vipimo 109 vya kutazama data ya takwimu. Walakini, ikiwa hifadhidata huhifadhi majedwali mengi, schemas, hifadhidata, basi metriki hizi zote zitalazimika kuzidishwa na idadi inayolingana ya jedwali, hifadhidata. Hiyo ni, kuna habari zaidi. Na ni rahisi sana kuzama ndani yake.
Shida inayofuata ni kwamba takwimu zinawakilishwa na vihesabio. Tukiangalia takwimu hizi, tutaona vihesabio vinavyoongezeka kila mara. Na ikiwa muda mwingi umepita tangu takwimu zimewekwa upya, tutaona maadili katika mabilioni. Na hawatuambii chochote.
Hakuna hadithi. Ikiwa ulikuwa na aina fulani ya kushindwa, kitu kilianguka dakika 15-30 zilizopita, huwezi kutumia takwimu na kuona kilichotokea dakika 15-30 zilizopita. Hili ni tatizo.
Ukosefu wa zana iliyojengwa ndani ya PostgreSQL ni shida. Watengenezaji wa kernel hawatoi matumizi yoyote. Hawana kitu kama hicho. Wanatoa tu takwimu kwenye hifadhidata. Itumie, fanya ombi kwake, fanya chochote unachotaka.
Kwa kuwa hakuna zana iliyojengwa ndani ya PostgreSQL, hii husababisha shida nyingine. Zana nyingi za wahusika wengine. Kila kampuni ambayo ina mikono zaidi au chini ya moja kwa moja inajaribu kuandika programu yake mwenyewe. Na kwa sababu hiyo, jumuiya ina zana nyingi zinazoweza kutumika kufanya kazi na takwimu. Na zana zingine zina uwezo fulani, zana zingine hazina uwezo mwingine, au kuna uwezo mpya. Na hali hutokea kwamba unahitaji kutumia zana mbili, tatu au nne zinazoingiliana na kuwa na kazi tofauti. Hii haipendezi sana.

Nini kinafuata kutoka kwa hii? Ni muhimu kuwa na uwezo wa kuchukua takwimu moja kwa moja, ili usitegemee programu, au kwa namna fulani kuboresha programu hizi mwenyewe: ongeza baadhi ya kazi ili kupata faida yako mwenyewe.

Na unahitaji maarifa ya msingi ya SQL. Ili kupata data kutoka kwa takwimu, unahitaji kuunda hoja za SQL, yaani, unahitaji kujua jinsi kuchagua na kujiunga kunakusanywa.

Takwimu zinatuambia mambo kadhaa. Wanaweza kugawanywa katika makundi.

Kundi la kwanza ni matukio yanayotokea kwenye hifadhidata. Huu ndio wakati tukio fulani linatokea kwenye hifadhidata: ombi, ufikiaji wa jedwali, otomatiki, ahadi, basi haya yote ni matukio. Kaunta zinazolingana na matukio haya zinaongezwa. Na tunaweza kufuatilia matukio haya.
Kundi la pili ni sifa za vitu kama vile meza na hifadhidata. Wana mali. Hii ndio saizi ya meza. Tunaweza kufuatilia ukuaji wa jedwali na ukuaji wa faharisi. Tunaweza kuona mabadiliko katika mienendo.
Na aina ya tatu ni muda uliotumika kwenye tukio. Ombi ni tukio. Ina kipimo chake maalum cha muda. Imeanzia hapa, ikaishia hapa. Tunaweza kuifuatilia. Wakati inachukua kusoma kizuizi kutoka kwa diski au kuiandika. Mambo kama hayo pia yanafuatiliwa.

Vyanzo vya takwimu vinawasilishwa kama ifuatavyo:

Katika kumbukumbu iliyoshirikiwa (bafa zilizoshirikiwa) kuna sehemu ya kuhifadhi data tuli, pia kuna vihesabio ambavyo vinaongezwa kila wakati matukio fulani yanapotokea, au wakati fulani hutokea katika uendeshaji wa hifadhidata.
Kaunta hizi zote hazipatikani kwa mtumiaji na hata hazipatikani na msimamizi. Haya ni mambo ya kiwango cha chini. Ili kuzifikia, PostgreSQL hutoa kiolesura katika mfumo wa vitendaji vya SQL. Tunaweza kuchagua kutupa kwa kutumia chaguo hizi za kukokotoa na kupata aina fulani ya vipimo (au seti ya vipimo).
Hata hivyo, kutumia vipengele hivi sio rahisi kila wakati, kwa hiyo kazi ni msingi wa maoni (VIEWs). Hizi ni jedwali pepe zinazotoa takwimu kwenye mfumo mdogo mahususi, au kwenye seti fulani ya matukio katika hifadhidata.
Maoni haya yaliyopachikwa (MTAZAMO) ndio kiolesura cha msingi cha mtumiaji cha kufanya kazi na takwimu. Zinapatikana kwa chaguo-msingi bila mipangilio yoyote ya ziada, unaweza kuzitumia mara moja, kuziangalia na kuchukua taarifa kutoka kwao. Na kisha kuna michango. Michango ni rasmi. Unaweza kusakinisha kifurushi cha postgresql-contrib (kwa mfano, postgresql94-contrib), pakia moduli inayohitajika katika usanidi, taja vigezo vyake, anzisha upya PostgreSQL na unaweza kuitumia. (Kumbuka. Kulingana na usambazaji, katika matoleo ya hivi karibuni kifurushi cha mchango ni sehemu ya kifurushi kikuu).
Na kuna michango isiyo rasmi. Hazijajumuishwa katika usambazaji wa kawaida wa PostgreSQL. Ni lazima ziwe zimekusanywa au kusakinishwa kama maktaba. Chaguzi zinaweza kuwa tofauti sana, kulingana na kile msanidi wa mchango huu usio rasmi alikuja nacho.

Slaidi hii inawasilisha TAZAMA hizo zote na baadhi ya vitendakazi ambavyo vinapatikana katika PostgreSQL 9.4. Kama tunavyoona, kuna mengi yao. Na ni rahisi sana kuchanganyikiwa ikiwa utakutana nayo kwa mara ya kwanza.

Walakini, ikiwa tunachukua picha iliyotangulia Как тратится время на PostgreSQL na sambamba na orodha hii, tunapata picha hii. Tunaweza kutumia kila mwonekano (Mwonekano) au kila chaguo za kukokotoa kwa madhumuni moja au nyingine kupata takwimu zinazolingana wakati PostgreSQL inapofanya kazi. Na tunaweza tayari kupata habari fulani juu ya uendeshaji wa mfumo mdogo.

Jambo la kwanza tutaangalia ni pg_stat_database. Kama tunavyoona, hii ni utendaji. Kuna habari nyingi ndani yake. Taarifa mbalimbali zaidi. Na inatoa maarifa muhimu sana ya kile kinachotokea katika hifadhidata yetu.

Ni vitu gani muhimu tunaweza kuchukua kutoka hapo? Hebu tuanze na mambo rahisi zaidi.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Jambo la kwanza tunaweza kuangalia ni asilimia ya kache iliyopigwa. Kasi ya akiba ni kipimo muhimu. Inakuruhusu kukadiria ni data ngapi inachukuliwa kutoka kwa kache iliyoshirikiwa ya bafa na ni kiasi gani kinachosomwa kutoka kwa diski.

Ni wazi kwamba kadiri tunavyopiga kache, ndivyo bora zaidi. Tunapima kipimo hiki kama asilimia. Na, kwa mfano, ikiwa asilimia yetu ya hits hizi za kache ni zaidi ya 90%, basi hii ni nzuri. Iwapo itashuka chini ya 90%, inamaanisha hatuna kumbukumbu ya kutosha kushikilia kichwa moto cha data kwenye kumbukumbu. Na ili kutumia data hii, PostgreSQL inalazimika kufikia diski na hii ni polepole kuliko ikiwa data ilisomwa kutoka kwa kumbukumbu. Na unahitaji kufikiria juu ya kuongeza kumbukumbu: ama kuongeza buffers zilizoshirikiwa, au kuongeza kumbukumbu ya vifaa (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;

Nini kingine unaweza kuchukua kutoka kwa utendaji huu? Unaweza kuona hitilafu zinazotokea kwenye hifadhidata. Ni nini kinachoonyeshwa hapa? Kuna ahadi, kurudi nyuma, kuunda faili za muda, ukubwa wao, vikwazo na migogoro.

Tunaweza kutumia ombi hili. SQL hii ni rahisi sana. Na tunaweza kuangalia data hii hapa.

Na hapa kuna maadili ya kizingiti. Tunaangalia uwiano wa ahadi na kurudi nyuma. Ahadi ni uthibitisho wa mafanikio wa shughuli. Urejeshaji nyuma ni urejeshaji, yaani, shughuli ilifanya kazi fulani, ikachuja hifadhidata, ikahesabu kitu, na kisha hitilafu ikatokea na matokeo ya muamala kutupwa. Hiyo ni idadi ya kurudi nyuma kuongezeka mara kwa mara ni mbaya. Na unapaswa kuwaepuka kwa njia fulani, na uhariri msimbo ili hii isifanyike.

Migogoro inahusiana na kurudia. Na pia ziepukwe. Ikiwa una maswali kadhaa ambayo yanatekelezwa kwenye nakala na migogoro inatokea, basi unahitaji kutatua migogoro hii na kuona kinachotokea. Maelezo yanaweza kupatikana kwenye kumbukumbu. Na uondoe hali za migogoro ili maombi ya maombi yafanye kazi bila makosa.

Deadlocks pia ni hali mbaya. Wakati maombi yanapigania rasilimali, ombi moja lilipata rasilimali moja na kuchukua lock, ombi la pili lilipata rasilimali ya pili na pia lilichukua lock, na kisha maombi yote mawili yalifikia rasilimali za kila mmoja na kuzuiwa wakati wa kusubiri jirani kutoa kufuli. Hii pia ni hali ya shida. Yanahitaji kushughulikiwa katika kiwango cha kuandika upya maombi na kuratibu upatikanaji wa rasilimali. Na ikiwa unaona kuwa vikwazo vyako vinaongezeka mara kwa mara, unahitaji kuangalia maelezo kwenye magogo, kuchambua hali zinazotokea na kuona shida ni nini.

Faili za muda (temp_files) pia ni mbaya. Wakati ombi la mtumiaji halina kumbukumbu ya kutosha ili kushughulikia data ya uendeshaji, ya muda, inaunda faili kwenye diski. Na shughuli zote ambazo inaweza kufanya katika buffer ya muda katika kumbukumbu huanza kufanywa kwenye diski. Ni polepole. Hii huongeza muda wa utekelezaji wa hoja. Na mteja aliyetuma ombi kwa PostgreSQL atapokea jibu baadaye kidogo. Ikiwa shughuli hizi zote zinafanywa kwa kumbukumbu, Postgres itajibu haraka sana na mteja atasubiri kidogo.

Pg_stat_bgwriter - Mtazamo huu unaelezea utendakazi wa mifumo midogo miwili ya usuli ya PostgreSQL: hii checkpointer и background writer.

Kwanza, hebu tuangalie pointi za udhibiti, kinachojulikana. checkpoints. Pointi za udhibiti ni nini? Sehemu ya ukaguzi ni nafasi katika logi ya muamala inayoonyesha kuwa mabadiliko yote ya data yaliyorekodiwa kwenye kumbukumbu yamesawazishwa kwa mafanikio na data kwenye diski. Mchakato, kulingana na mzigo wa kazi na mipangilio, unaweza kuwa mrefu na zaidi unajumuisha kusawazisha kurasa chafu katika vihifadhi vilivyoshirikiwa na faili za data kwenye diski. Ni ya nini? Ikiwa PostgreSQL ilikuwa ikipata diski kila mara na kuleta data kutoka hapo, na kuandika data kwenye kila ufikiaji, itakuwa polepole. Kwa hivyo, PostgreSQL ina sehemu ya kumbukumbu ambayo saizi yake inategemea mipangilio katika usanidi. Postgres huhifadhi data ya moja kwa moja katika kumbukumbu hii kwa ajili ya kuchakatwa au kuhojiwa baadaye. Katika kesi ya maombi ya kubadilisha data, inabadilishwa. Na tunapata matoleo mawili ya data. Moja iko kwenye kumbukumbu zetu, nyingine iko kwenye diski. Na mara kwa mara unahitaji kusawazisha data hii. Tunahitaji kusawazisha kile kinachobadilishwa kwenye kumbukumbu hadi diski. Kwa hili unahitaji vituo vya ukaguzi.

Sehemu ya ukaguzi hupitia vihifadhi vilivyoshirikiwa, huashiria kurasa chafu ambazo zinahitajika kwa ukaguzi. Kisha inazindua kupita kwa pili kupitia bafa zilizoshirikiwa. Na kurasa ambazo zimewekwa alama kwa sehemu ya ukaguzi, tayari inazilinganisha. Kwa njia hii data inasawazishwa na diski.

Kuna aina mbili za vituo vya ukaguzi. Sehemu moja ya ukaguzi inatekelezwa kwa kuisha kwa muda. Sehemu hii ya ukaguzi ni muhimu na nzuri - checkpoint_timed. Na kuna vituo vya ukaguzi juu ya mahitaji - checkpoint required. Sehemu hii ya ukaguzi hutokea tunapokuwa na rekodi kubwa sana ya data. Tulirekodi kumbukumbu nyingi za miamala. Na PostgreSQL inaamini kwamba inahitaji kusawazisha haya yote haraka iwezekanavyo, fanya ukaguzi na uendelee.

Na ukiangalia takwimu pg_stat_bgwriter na kuona ulicho nacho checkpoint_req ni kubwa zaidi kuliko checkpoint_timed, basi hii ni mbaya. Kwa nini mbaya? Hii inamaanisha kuwa PostgreSQL iko chini ya mkazo wa kila wakati inapohitaji kuandika data kwenye diski. Kitengo cha kukagua muda ulioisha hakina mfadhaiko mdogo na hufanywa kulingana na ratiba ya ndani na husambazwa kwa muda. PostgreSQL ina uwezo wa kusitisha kazi na sio kuchuja mfumo mdogo wa diski. Hii ni muhimu kwa PostgreSQL. Na maswali ambayo yanatekelezwa wakati wa ukaguzi hayatapata mkazo kutokana na ukweli kwamba mfumo mdogo wa diski una shughuli nyingi.

Na kurekebisha kituo cha ukaguzi kuna vigezo vitatu:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Wanakuwezesha kudhibiti uendeshaji wa pointi za udhibiti. Lakini sitakaa juu yao. Ushawishi wao ni mada tofauti.

Onyo: Toleo la 9.4 lililojadiliwa katika ripoti halifai tena. Katika matoleo ya kisasa ya PostgreSQL paramu checkpoint_segments kubadilishwa na vigezo min_wal_size и max_wal_size.

Mfumo mdogo unaofuata ni mwandishi wa usuli - background writer. Anafanya nini? Inaendesha mara kwa mara katika kitanzi kisicho na mwisho. Huchanganua kurasa katika vihifadhi vilivyoshirikiwa na kutupa kurasa chafu ambazo hupata kwenye diski. Kwa hivyo, husaidia kiashiria kufanya kazi kidogo wakati wa utekelezaji wa ukaguzi.

Ni nini kingine kinachohitajika? Inatoa hitaji la kurasa tupu katika vihifadhi vilivyoshirikiwa ikiwa zinahitajika ghafla (kwa wingi na mara moja) kushughulikia data. Tuseme hali ilitokea wakati kurasa tupu zilihitajika kukamilisha ombi na tayari zilikuwa kwenye vihifadhi vilivyoshirikiwa. Ya postgresive backend anazichukua tu na kuzitumia, sio lazima asafishe chochote yeye mwenyewe. Lakini ikiwa ghafla hakuna kurasa kama hizo, sehemu ya nyuma inasimamisha kazi na kuanza kutafuta kurasa ili kuzitupa kwenye diski na kuzichukua kwa mahitaji yake - ambayo inathiri vibaya wakati wa ombi linalotekelezwa kwa sasa. Ikiwa unaona kuwa una parameter maxwritten_clean kubwa, hii ina maana kwamba mwandishi wa mandharinyuma hafanyi kazi yake na unahitaji kuongeza vigezo bgwriter_lru_maxpages, ili aweze kufanya kazi zaidi katika mzunguko mmoja, futa kurasa zaidi.

Na kiashiria kingine muhimu sana ni buffers_backend_fsync. Backends si fsync kwa sababu ni polepole. Wanapitisha fsync juu ya ukaguzi wa stack ya IO. Kiashiria cha ukaguzi kina foleni yake, inachakata mara kwa mara fsync na kusawazisha kurasa kwenye kumbukumbu na faili kwenye diski. Ikiwa foleni kwenye kiashiria cha ukaguzi ni kubwa na imejaa, basi sehemu ya nyuma inalazimika kufanya fsync yenyewe na hii inapunguza kasi ya kazi ya nyuma., yaani mteja atapokea jibu baadaye kuliko ilivyoweza. Ikiwa unaona kwamba thamani yako ni kubwa kuliko sifuri, basi hii tayari ni tatizo na unahitaji kulipa kipaumbele kwa mipangilio ya mwandishi wa mandharinyuma na pia tathmini ya utendaji wa mfumo mdogo wa diski.

Onyo: _Nakala ifuatayo inaelezea maoni ya takwimu yanayohusishwa na urudufishaji. Majina mengi ya mwonekano na kazi yalibadilishwa jina katika Postgres 10. Kiini cha kubadilisha jina kilikuwa kuchukua nafasi. xlog juu ya wal и location juu ya lsn katika kazi/tazama majina, n.k. Mfano maalum, kazi pg_xlog_location_diff() ilibadilishwa jina kuwa pg_wal_lsn_diff()._

Tuna mambo mengi hapa pia. Lakini tunahitaji tu vitu vinavyohusiana na eneo.

Ikiwa tunaona kuwa maadili yote ni sawa, basi hii ni chaguo bora na replica haibaki nyuma ya bwana.

Nafasi hii ya heksadesimali hapa ndiyo nafasi katika logi ya muamala. Inaongezeka mara kwa mara ikiwa kuna shughuli yoyote katika hifadhidata: kuingiza, kufuta, nk.

сколько записано 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());

Ikiwa mambo haya ni tofauti, basi kuna aina fulani ya lag. Lag ni bakia kati ya nakala na bwana, i.e. data hutofautiana kati ya seva.

Kuna sababu tatu za kuchelewa:

Mfumo huu mdogo wa diski hauwezi kukabiliana na kusawazisha faili za kurekodi.
Haya ni makosa ya mtandao yanayowezekana, au upakiaji wa mtandao, wakati data haina muda wa kufikia nakala na haiwezi kuizalisha tena.
Na processor. Processor ni kesi ya nadra sana. Na nikaona hii mara mbili au tatu, lakini hii pia inaweza kutokea.

Na hapa kuna maswali matatu ambayo huturuhusu kutumia takwimu. Tunaweza kukadiria ni kiasi gani tumerekodi katika kumbukumbu ya muamala. Kuna kazi kama hiyo pg_xlog_location_diff na tunaweza kukadiria baiti za kurudiarudia kwa baiti na sekunde. Pia tunatumia thamani kutoka kwa mtazamo huu (MAONI) kwa hili.

Kumbuka: _Badala ya pg_xlog_locationDiff() chaguo la kukokotoa linaweza kutumia kiendeshaji cha kutoa na kutoa eneo moja kutoka kwa lingine. Starehe.

Kuna hatua moja na lag, ambayo ni kwa sekunde. Ikiwa hakuna shughuli kwa bwana, shughuli hiyo ilikuwepo kama dakika 15 iliyopita na hakuna shughuli, na ikiwa tutaangalia lagi hii kwenye replica, tutaona bakia ya dakika 15. Hii inafaa kukumbuka. Na hii inaweza kuwa ya kutatanisha unapotazama bakia hii.

Pg_stat_all_tables ni mtazamo mwingine muhimu. Inaonyesha takwimu kwenye meza. Tunapokuwa na jedwali kwenye hifadhidata, kuna shughuli fulani nayo, vitendo vingine, tunaweza kupata habari hii kutoka kwa mtazamo huu.

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;

Jambo la kwanza tunaloweza kuangalia ni michanganuo ya mfululizo kwenye jedwali. Nambari yenyewe baada ya kupita hizi sio mbaya na sio kiashiria kwamba tunahitaji kufanya kitu.

Walakini, kuna kipimo cha pili - seq_tup_read. Hii ni idadi ya safu mlalo zilizorejeshwa kutoka kwa uchanganuzi mfuatano. Ikiwa idadi ya wastani inazidi 1, 000, 10, 000, basi hii tayari ni kiashiria kwamba labda unahitaji kuunda faharisi mahali pengine ili maswali yawe ya msingi wa faharisi, au inawezekana kuongeza maswali ambayo hutumia skana za mlolongo hivyo. kwamba hii haifanyiki ilikuwa.

Mfano rahisi - hebu sema ombi na OFFSET kubwa na gharama LIMIT. Kwa mfano, safu 100 kwenye jedwali huchanganuliwa na baada ya hapo safu 000 zinazohitajika huchukuliwa, na safu zilizochanganuliwa za hapo awali hutupwa. Hii pia ni kesi mbaya. Na maswali kama haya yanahitaji kuboreshwa. Na hapa kuna swali rahisi la SQL ambapo unaweza kuangalia hii na kutathmini nambari zinazotokana.

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;

Ukubwa wa meza pia unaweza kupatikana kwa kutumia meza hii na kutumia kazi za ziada pg_total_relation_size(), pg_relation_size().

Kwa ujumla, kuna metacommands dt и di, ambayo inaweza kutumika katika PSQL na pia kutazama ukubwa wa majedwali na faharisi.

Walakini, kutumia vitendaji hutusaidia kuangalia saizi za jedwali, hata kuzingatia faharisi, au bila kuzingatia faharisi, na tayari kufanya makadirio kadhaa kulingana na ukuaji wa hifadhidata, i.e. jinsi inavyokua, kwa nguvu gani, na fanya hitimisho fulani kuhusu uboreshaji wa ukubwa.

Shughuli ya kurekodi. Kurekodi ni nini? Wacha tuangalie operesheni UPDATE - Uendeshaji wa safu za kusasisha kwenye jedwali. Kwa kweli, sasisho ni shughuli mbili (au hata zaidi). Hii ni kuingiza toleo jipya la safu mlalo na kuashiria toleo la zamani la safu mlalo kuwa halitumiki. Baadaye, otomatiki itakuja na kusafisha matoleo haya ya zamani ya mistari, ikiashiria mahali hapa kama panapatikana kwa matumizi tena.

Kwa kuongeza, sasisho sio tu kuhusu kusasisha meza. Hili pia ni sasisho la faharasa. Ikiwa una faharisi nyingi kwenye jedwali, basi wakati wa kusasisha faharisi zote zinazojumuisha sehemu zilizosasishwa kwenye hoja pia zitahitaji kusasishwa. Faharasa hizi pia zitakuwa na matoleo ya zamani ya safu mlalo ambayo yatahitaji kusafishwa.

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;

Na kwa sababu ya muundo wake mpya, UPDATE ni operesheni ya uzani mzito. Lakini zinaweza kufanywa rahisi. Kula hot updates. Walionekana katika toleo la PostgreSQL 8.3. Na hii ni nini? Hili ni sasisho jepesi ambalo halisababishi faharasa kujengwa upya. Hiyo ni, tulisasisha rekodi, lakini rekodi tu kwenye ukurasa (ambayo ni ya jedwali) ilisasishwa, na faharisi bado zinaonyesha rekodi sawa kwenye ukurasa. Kuna kidogo ya mantiki ya kuvutia ya uendeshaji: wakati utupu unakuja, huunda minyororo hii hot hujenga upya na kila kitu kinaendelea kufanya kazi bila kusasisha faharisi, na kila kitu hutokea kwa upotevu mdogo wa rasilimali.

Na wewe lini n_tup_hot_upd kubwa, basi ni nzuri sana. Hii inamaanisha kuwa masasisho mepesi yanatawala na hii ni nafuu kwetu kwa suala la rasilimali na kila kitu kiko sawa.

ALTER TABLE table_name SET (fillfactor = 70);

Jinsi ya kuongeza kiasi hot updateov? Tunaweza kutumia fillfactor. Huamua ukubwa wa nafasi ya bure iliyohifadhiwa wakati wa kujaza ukurasa kwenye jedwali kwa kutumia INSERTs. Wakati viingilio vinaongezwa kwenye meza, hujaza kabisa ukurasa na kuacha hakuna nafasi tupu. Kisha ukurasa mpya unasisitizwa. Data imejazwa tena. Na hii ndio tabia chaguo-msingi, fillfactor = 100%.

Tunaweza kufanya fillfactor 70%. Hiyo ni, wakati wa kuingiza, ukurasa mpya uliangaziwa, lakini ni 70% tu ya ukurasa uliojazwa. Na tumebakiza 30% kama hifadhi. Unapohitaji kufanya sasisho, itawezekana kutokea kwenye ukurasa huo huo, na toleo jipya la mstari litafaa kwenye ukurasa huo huo. Na usasisho_moto utafanywa. Hii inafanya iwe rahisi kuandika kwenye meza.

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));

Foleni ya otomatiki. Autovacuum ni mfumo mdogo ambao kuna takwimu chache sana katika PostgreSQL. Tunaweza tu kuona katika jedwali katika pg_stat_activity ni ombwe ngapi tunazo kwa sasa. Hata hivyo, ni vigumu sana kuelewa ni meza ngapi kwenye foleni mara moja.

Kumbuka: _Kuanzia na Postgres 10, hali ya ufuatiliaji wa Vatovac imeboreka sana - mwonekano wa pg_stat_progress umeonekana.utupu, ambayo kwa kiasi kikubwa hurahisisha suala la ufuatiliaji wa utupu wa gari.

Tunaweza kutumia swali hili lililorahisishwa. Na tunaweza kuona wakati ombwe itabidi kufanywa. Lakini utupu unapaswa kuanza vipi na lini? Haya ni matoleo ya urithi wa mistari niliyokuwa nikizungumzia hapo awali. Sasisho limetokea, toleo jipya la mstari liliingizwa. Toleo la kizamani la mfuatano limeonekana. Katika meza pg_stat_user_tables kuna parameter kama hiyo n_dead_tup. Inaonyesha idadi ya mistari "iliyokufa". Na mara tu idadi ya safu zilizokufa inakuwa kubwa kuliko kizingiti fulani, otomatiki itakuja kwenye meza.

Na kizingiti hiki kinahesabiwaje? Hii ni asilimia mahususi ya jumla ya idadi ya safu mlalo kwenye jedwali. Kuna parameter autovacuum_vacuum_scale_factor. Huamua asilimia. Wacha tuseme 10% + kuna kizingiti cha ziada cha mistari 50. Na nini kinatokea? Tunapokuwa na safu zilizokufa zaidi ya "10% + 50" ya safu zote kwenye jedwali, basi tunaweka meza kwenye otomatiki.

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));

Hata hivyo, kuna hatua moja. Vizingiti vya msingi kwa vigezo av_base_thresh и av_scale_factor inaweza kupewa kibinafsi. Na, ipasavyo, kizingiti hakitakuwa cha kimataifa, lakini cha mtu binafsi kwa meza. Kwa hiyo, ili kuhesabu, unahitaji kutumia tricks na tricks. Na ikiwa una nia, basi unaweza kuangalia uzoefu wa wenzetu kutoka Avito (kiungo kwenye slide ni batili na imesasishwa katika maandishi).

Waliandika kwa programu-jalizi ya munin, ambayo inazingatia mambo haya. Kuna kitambaa cha karatasi mbili hapo. Lakini inahesabu kwa usahihi na kwa ufanisi kabisa inaruhusu sisi kutathmini ambapo tunahitaji utupu mwingi kwa meza ambapo kuna kidogo.

Je, tunaweza kufanya nini kuhusu hilo? Ikiwa tuna foleni kubwa na otomatiki haiwezi kustahimili, basi tunaweza kuongeza idadi ya wafanyikazi wa utupu, au tu kufanya utupu kuwa mkali zaidi., ili kuchochea mapema, mchakato wa meza katika vipande vidogo. Na hivyo foleni itapungua. - Jambo kuu hapa ni kufuatilia mzigo kwenye diski, kwa sababu ... utupu sio kitu cha bure, ingawa kwa ujio wa vifaa vya SSD/NVMe shida imekuwa haionekani sana.

Pg_stat_all_indexes ni takwimu kwenye faharasa. Yeye si mkubwa. Na tunaweza kuitumia kupata habari juu ya matumizi ya faharisi. Na kwa mfano, tunaweza kuamua ni faharisi gani tuna za ziada.

Kama nilivyokwisha sema, sasisho sio tu sasisho la jedwali, pia ni sasisho la faharisi. Ipasavyo, ikiwa tunayo faharisi nyingi kwenye jedwali, basi wakati wa kusasisha safu kwenye jedwali, faharisi za sehemu zilizoonyeshwa pia zinahitaji kusasishwa, na. ikiwa tuna faharisi ambazo hazijatumika ambazo hakuna alama za faharasa, basi hutegemea kama ballast. Na tunahitaji kuwaondoa. Kwa hili tunahitaji shamba idx_scan. Tunaangalia tu idadi ya alama za alama. Ikiwa faharisi zina skanisho za sifuri kwa muda mrefu wa uhifadhi wa takwimu (angalau wiki 2-3), basi uwezekano mkubwa hizi ni faharisi mbaya, tunahitaji kuziondoa.

Kumbuka: Unapotafuta faharisi ambazo hazijatumika katika kesi ya nguzo za urudufishaji wa utiririshaji, unahitaji kuangalia nodi zote za nguzo, kwa sababu takwimu sio za kimataifa, na ikiwa index haitumiki kwa bwana, basi inaweza kutumika kwenye replicas (ikiwa kuna mzigo huko).

Viungo viwili:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Hii ni mifano ya juu zaidi ya maswali ya jinsi ya kutafuta faharasa ambazo hazijatumika.

Kiungo cha pili ni ombi la kuvutia. Kuna mantiki isiyo ya maana sana hapo. Ninapendekeza kwa kumbukumbu.

Nini kingine inafaa kujumlisha kwa kutumia fahirisi?

Faharasa zisizotumika ni mbaya.
Wanachukua nafasi.
Punguza kasi ya utendakazi wa sasisho.
Kazi ya ziada kwa utupu.

Ikiwa tutaondoa faharisi ambazo hazijatumiwa, tutafanya hifadhidata kuwa bora zaidi.

Uwasilishaji unaofuata ni pg_stat_activity. Hii ni analog ya matumizi ps, katika PostgreSQL pekee. Kama ps'om unaangalia michakato katika mfumo wa uendeshaji, basi pg_stat_activity Itakuonyesha shughuli ndani ya PostgreSQL.

Ni vitu gani muhimu tunaweza kuchukua kutoka hapo?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Tunaweza kuona shughuli za jumla, kile kinachotokea kwenye hifadhidata. Tunaweza kufanya upelekaji mpya. Kila kitu hapa kimelipuka, viunganisho vipya havikubaliki, makosa yanaingia kwenye programu.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Tunaweza kutekeleza swali kama hili na kuona jumla ya asilimia ya miunganisho inayohusiana na kikomo cha juu cha muunganisho na kuona ni nani aliye na miunganisho mingi. Na katika kesi hii tunaona mtumiaji huyo cron_role ilifungua miunganisho 508. Na jambo fulani lilimtokea pale. Tunahitaji kukabiliana nayo na kuiangalia. Na inawezekana kabisa kwamba hii ni aina fulani ya idadi isiyo ya kawaida ya viunganisho.

Ikiwa tuna mzigo wa kazi wa OLTP, hoja zinapaswa kuwa za haraka, haraka sana na kusiwe na maswali marefu. Hata hivyo, ikiwa maswali ya muda mrefu hutokea, basi kwa muda mfupi hakuna kitu cha wasiwasi kuhusu, lakini Kwa muda mrefu, maswali marefu hudhuru hifadhidata; huongeza athari ya jedwali wakati mgawanyiko wa meza unatokea. Unahitaji kujiondoa bloat na maswali marefu.

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;

Tafadhali kumbuka: kwa ombi hili tunaweza kutambua maswali marefu na miamala. Tunatumia kipengele clock_timestamp() kuamua wakati wa kufanya kazi. Maswali marefu ambayo tumepata, tunaweza kuyakumbuka, kuyatimiza explain, angalia mipango na uboresha kwa namna fulani. Tunapunguza maombi marefu ya sasa na kuendelea na maisha yetu.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Shughuli mbaya ni miamala katika hali ya uvivu katika muamala na bila kufanya kitu katika hali za muamala (zilizositishwa).

Ina maana gani? Malipo yana majimbo mengi. Na moja ya majimbo haya yanaweza kudhaniwa wakati wowote. Kuna uwanja wa kufafanua majimbo state katika uwasilishaji huu. Na tunaitumia kuamua hali.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Na, kama nilivyosema hapo juu, majimbo haya mawili wavivu katika shughuli na wavivu katika shughuli (iliyoachishwa) ni mbaya. Ni nini? Huu ndio wakati programu ilipofungua muamala, ikafanya baadhi ya hatua na kuendelea na shughuli zake. Muamala unabaki wazi. Inategemea, hakuna kinachotokea ndani yake, inachukua uunganisho, kufuli kwenye safu zilizobadilishwa na uwezekano wa kuongeza bloat ya meza nyingine, kutokana na usanifu wa injini ya shughuli ya Postrges. Na shughuli kama hizo zinapaswa pia kupigwa risasi, kwa sababu kwa ujumla zina madhara, kwa hali yoyote.

Ikiwa utaona kuwa una zaidi ya 5-10-20 kati yao kwenye hifadhidata yako, basi unahitaji kuwa na wasiwasi na kuanza kufanya kitu nao.

Hapa pia tunatumia kwa wakati wa kuhesabu clock_timestamp(). Tunapiga shughuli na kuboresha programu.

Kama nilivyosema hapo juu, kuzuia ni wakati shughuli mbili au zaidi zinapigania moja au kikundi cha rasilimali. Kwa hili tuna shamba waiting yenye thamani ya boolean true au false.

Kweli - hii ina maana kwamba mchakato unasubiri, kitu kinahitajika kufanywa. Wakati mchakato unasubiri, ina maana kwamba mteja aliyeanzisha mchakato huu pia anasubiri. Mteja anakaa kwenye kivinjari na pia anasubiri.

Onyo: _Kuanzia uga wa Postgres toleo la 9.6 waiting kuondolewa na sehemu mbili za taarifa zaidi zikaongezwa badala yake wait_event_type и wait_event._

Nini cha kufanya? Ikiwa unaona kweli kwa muda mrefu, inamaanisha unahitaji kuondokana na maombi hayo. Tunapunguza tu shughuli kama hizo. Tunawaandikia wasanidi programu kwamba wanahitaji kuboresha kwa namna fulani ili kusiwe na mbio za rasilimali. Na kisha watengenezaji huongeza programu ili hii isifanyike.

Na kesi iliyokithiri, lakini inayoweza kuwa mbaya ni kutokea kwa vikwazo. Shughuli mbili za malipo zilisasisha rasilimali mbili, kisha kuzifikia tena, wakati huu kwa nyenzo tofauti. Katika kesi hii, PostgreSQL inaua shughuli yenyewe ili nyingine iweze kuendelea kufanya kazi. Hii ni hali ya mwisho na hawezi kuijua peke yake. Kwa hivyo, PostgreSQL inalazimika kuchukua hatua kali.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Na hapa kuna maswali mawili ambayo hukuruhusu kufuatilia kuzuia. Tunatumia mtazamo pg_locks, ambayo inakuwezesha kufuatilia kufuli nzito.

Na kiungo cha kwanza ni maandishi ya ombi yenyewe. Ni ndefu sana.

Na kiungo cha pili ni makala juu ya kufuli. Ni muhimu kusoma, inavutia sana.

Kwa hiyo tunaona nini? Tunaona maombi mawili. Shughuli na ALTER TABLE ni shughuli ya kuzuia. Ilianza, lakini haikukamilika, na programu iliyorekodi muamala huu inafanya mambo mengine mahali fulani. Na ombi la pili ni sasisho. Anangoja meza ya kubadilisha fedha imalizike ndipo aendelee na kazi yake.

Hivi ndivyo tunavyoweza kujua ni nani aliyefunga nani, anashikilia nani, na tunaweza kukabiliana nayo zaidi.

Moduli inayofuata ni pg_stat_statements. Kama nilivyosema, hii ni moduli. Ili kuitumia, unahitaji kupakia maktaba yake katika usanidi, kuanzisha upya PostgreSQL, kufunga moduli (kwa amri moja) na kisha tutakuwa na mtazamo mpya.

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;

Tunaweza kuchukua nini kutoka hapo? Ikiwa tunazungumza juu ya mambo rahisi, tunaweza kuchukua muda wa wastani wa utekelezaji wa hoja. Muda unaongezeka, ambayo ina maana kwamba PostgreSQL inajibu polepole na tunahitaji kufanya kitu.

Tunaweza kuangalia miamala inayoendelea zaidi ya uandishi katika hifadhidata inayobadilisha data katika vihifadhi vilivyoshirikiwa. Angalia ni nani anayesasisha au kufuta data hapo.

Na tunaweza kuangalia kwa urahisi takwimu tofauti za maombi haya.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

Sisi pg_stat_statements Tunaitumia kuunda ripoti. Tunaweka upya takwimu mara moja kwa siku. Hebu tukusanye. Kabla ya kuweka upya takwimu wakati ujao, hebu tuunde ripoti. Hapa kuna kiunga cha ripoti. Unaweza kuitazama.

Tunafanya nini? Tunakokotoa takwimu za jumla za maombi yote. Kisha, kwa kila ombi, tunahesabu mchango wake binafsi kwa takwimu hizi za jumla.

Na tunaweza kutazama nini? Tunaweza kuangalia jumla ya muda wa utekelezaji wa maombi yote ya aina fulani dhidi ya usuli wa maombi mengine yote. Tunaweza kuangalia CPU na matumizi ya rasilimali ya I/O kuhusiana na picha ya jumla. Na tayari boresha maswali haya. Tunaunda hoja kuu kulingana na ripoti hii na tayari tunapata mawazo kuhusu nini cha kuboresha.

Tumeacha nini nyuma ya pazia? Bado kuna mawasilisho machache ambayo sikuyazingatia kwa sababu muda ni mdogo.

Kuna pgstattuple pia ni moduli ya ziada kutoka kwa kifurushi cha kawaida cha michango. Inakuruhusu kutathmini bloat meza, kinachojulikana kugawanyika kwa meza. Na ikiwa kuna mgawanyiko mwingi, unahitaji kuiondoa na kutumia zana tofauti. Na kazi pgstattuple inafanya kazi kwa muda mrefu. Na meza zaidi kuna, tena itafanya kazi.

Mchango unaofuata ni pg_buffercache. Inakuruhusu kukagua vihifadhi vilivyoshirikiwa: jinsi kurasa za bafa za jedwali zinatumika kwa umakini na kwa ajili ya majedwali gani. Na hukuruhusu kuangalia vihifadhi vilivyoshirikiwa na kutathmini kile kinachotokea hapo.

Moduli inayofuata ni pgfincore. Inaruhusu uendeshaji wa meza ya kiwango cha chini kupitia simu ya mfumo mincore(), yaani, hukuruhusu kupakia jedwali kwenye vihifadhi vilivyoshirikiwa, au uipakue. Na inaruhusu, kati ya mambo mengine, kukagua cache ya ukurasa wa mfumo wa uendeshaji, yaani, ni nafasi ngapi ambayo meza inachukua kwenye cache ya ukurasa, katika buffers zilizoshirikiwa, na inatuwezesha tu kutathmini mzigo wa kazi wa meza.

Moduli inayofuata - pg_stat_kcache. Pia hutumia simu ya mfumo getrusage(). Na huitekeleza kabla na baada ya ombi kutekelezwa. Na katika takwimu zinazosababisha, inatuwezesha kukadiria kiasi gani ombi letu lilitumia kwenye diski I/O, yaani, uendeshaji na mfumo wa faili na kuangalia matumizi ya processor. Hata hivyo, moduli ni mdogo (kikohozi cha kikohozi) na kwa uendeshaji wake inahitaji PostgreSQL 9.4 na pg_stat_statements, ambayo nilitaja hapo awali.

Kujua jinsi ya kutumia takwimu ni muhimu. Huhitaji programu za watu wengine. Unaweza kuingia, kuona, kufanya jambo fulani, kutimiza jambo fulani.
Kutumia takwimu sio ngumu, ni SQL ya kawaida tu. Ulikusanya ombi, ulikusanya, ulituma, uliangalia.
Takwimu husaidia kujibu maswali. Ikiwa una maswali, unageuka kwenye takwimu - angalia, fanya hitimisho, kuchambua matokeo.
Na majaribio. Kuna maombi mengi, data nyingi. Unaweza kuboresha hoja iliyopo kila wakati. Unaweza kutengeneza toleo lako mwenyewe la ombi linalokufaa zaidi ya asilia na ulitumie.