Mga sukaranan sa pag-monitor sa PostgreSQL. Alexey Lesovsky

Gisugyot ko nga basahon nimo ang transcript sa taho ni Alexey Lesovsky gikan sa Data Egret "Basics of PostgreSQL Monitoring"

Niini nga taho, si Alexey Lesovsky maghisgot mahitungod sa mga mahinungdanong punto sa mga estadistika sa postgres, unsa ang gipasabut niini, ug nganong kinahanglan kini nga ilakip sa pagmonitor; mahitungod sa unsa nga mga tsart ang kinahanglan sa pagmonitor, kung giunsa kini idugang ug kung giunsa ang paghubad. Mapuslan ang taho alang sa mga tagdumala sa database, mga tagdumala sa sistema ug mga developer nga interesado sa pag-troubleshoot sa Postgres.

Ang akong ngalan mao si Alexey Lesovsky, nagrepresentar ako sa Data Egret.

Pipila ka mga pulong mahitungod sa akong kaugalingon. Nagsugod ako sa dugay na nga panahon isip usa ka tigdumala sa sistema.

Gidumala nako ang tanang matang sa lain-laing Linux, naghimo ug lain-laing mga butang nga may kalabutan sa Linux, ie virtualization, monitoring, nagtrabaho uban sa mga proxy, ug uban pa. Ganahan kaayo ko niya. Ug sa usa ka punto, nagsugod ako sa pag-atubang sa PostgreSQL sa kadaghanan sa akong oras sa pagtrabaho. Ug busa anam-anam nga nahimo akong PostgreSQL DBA.

Ug sa tibuok nakong karera, kanunay kong interesado sa mga hilisgutan sa estadistika, pag-monitor, telemetry. Ug sa dihang ako usa ka tigdumala sa sistema, nagtrabaho ako pag-ayo sa Zabbix. Ug nagsulat usa ka gamay nga hugpong sa mga script sama sa zabbix-extension. Sikat kaayo siya sa iyang panahon. Ug didto posible nga ma-monitor ang lahi kaayo nga hinungdanon nga mga butang, dili lamang ang Linux, apan usab ang lainlaing mga sangkap.

Karon nagbuhat na ko sa PostgreSQL. Nagsulat na ako og laing butang nga nagtugot kanimo sa pagtrabaho sa mga estadistika sa PostgreSQL. Gitawag kini pgCenter (artikulo sa Habré - Postgres stat nga walay nerbiyos ug tensiyon).

Usa ka gamay nga pasiuna. Unsa ang mga sitwasyon sa atong mga kustomer, sa atong mga kliyente? Adunay usa ka matang sa aksidente nga nalangkit sa database. Ug kung nabalik na ang database, ang pinuno sa departamento o ang pinuno sa pag-uswag moabut ug moingon: "Mga higala, kinahanglan naton bantayan ang database, tungod kay adunay daotan nga nahitabo ug kinahanglan nga dili kini mahitabo sa umaabot." Ug dinhi nagsugod ang makapaikag nga proseso sa pagpili sa usa ka sistema sa pagmonitor o pagpahiangay sa usa ka kasamtangan nga sistema sa pagmonitor aron imong mabantayan ang imong database - PostgreSQL, MySQL o uban pa. Ug ang mga kauban nagsugod sa pagtanyag: "Nakadungog ko nga adunay ingon ug ingon niana nga database. Gamiton nato.” Ang mga kauban nagsugod sa panaglalis sa usag usa. Ug sa katapusan kini nahimo nga gipili namon ang usa ka klase nga database, apan ang pag-monitor sa PostgreSQL medyo huyang nga girepresentahan niini ug kinahanglan namon nga tapuson ang usa ka butang. Pagkuha pipila ka mga repositoryo gikan sa GitHub, i-clone kini, ipahiangay ang mga script, bisan unsang paagiha i-tune kini. Ug sa katapusan kini nahulog sa usa ka matang sa manwal nga trabaho.

Busa, sa niini nga report, ako mosulay sa paghatag kaninyo sa pipila ka kahibalo kon sa unsang paagi sa pagpili sa monitoring dili lamang alang sa PostgreSQL, apan alang usab sa database. Ug aron mahatagan ang kahibalo nga magtugot kanimo nga tapuson ang imong pag-monitor aron makakuha usa ka kaayohan gikan niini, aron ma-monitor nimo ang imong database nga adunay kaayohan aron mapugngan ang bisan unsang umaabot nga mga kahimtang sa emerhensya nga mahimong motungha sa oras.

Ug kadtong mga ideya nga maanaa sa kini nga taho, mahimo silang direkta nga ipahiangay sa bisan unsang database, kini usa ka DBMS o noSQL. Busa, dili lamang ang PostgreSQL dinhi, apan adunay daghang mga resipe kung giunsa kini buhaton sa PostgreSQL. Adunay mga pananglitan sa mga pangutana, mga pananglitan sa mga entidad nga adunay PostgreSQL alang sa pag-monitor. Ug kung ang imong DBMS adunay parehas nga mga butang nga nagtugot kanimo nga ibutang kini sa pag-monitor, mahimo usab nimo kini ipahiangay, idugang kini ug kini maayo.

Dili ko mosumbong
Hisguti kon unsaon paghatud ug pagtipig sa mga sukatan. Dili ako mosulti bisan unsa mahitungod sa post-processing data ug paghatag niini ngadto sa user. Ug dili ako mosulti bisan unsa bahin sa pag-alerto.
Apan sa dagan sa istorya, ipakita nako ang lainlaing mga screenshot sa mga naa na nga mga pag-monitor, bisan unsaon nako pagsaway kanila. Bisan pa niana, akong paningkamutan nga dili hinganlan ang mga tatak aron dili makamugna og advertising o anti-advertising alang niini nga mga produkto. Busa, ang tanan nga mga sulagma random ug magpabilin sa imong imahinasyon.

Una, atong sabton kung unsa ang pagmonitor. Ang pagmonitor usa ka hinungdanon nga butang nga mabatonan. Ang tanan nakasabot niini. Apan sa parehas nga oras, ang pag-monitor wala’y kalabotan sa usa ka produkto sa negosyo ug dili direktang makaapekto sa kita sa kompanya, mao nga ang pag-monitor kanunay nga gihatag nga oras sa nahabilin nga sukaranan. Kung naa tay time, then we are engaged in monitoring, kung walay time, then OK, ibutang nato sa backlog ug someday mubalik ta ani nga mga buluhaton.

Busa, gikan sa among praktis, sa diha nga kami moabut sa mga kliyente, ang pag-monitor kanunay nga wala’y pag-uswag ug wala’y bisan unsang makapaikag nga mga butang nga makatabang kanamo nga makahimo usa ka labi ka maayo nga trabaho sa database. Ug busa kinahanglan nga mahuman kanunay ang pagmonitor.

Ang mga database usa ka komplikado nga mga butang nga kinahanglan nimo usab nga bantayan, tungod kay ang mga database usa ka tipiganan sa kasayuran. Ug ang kasayuran hinungdanon kaayo alang sa kompanya, dili kini mawala sa bisan unsang paagi. Apan sa samang higayon, ang mga database komplikado kaayo nga mga piraso sa software. Sila gilangkuban sa daghang mga sangkap. Ug daghan niini nga mga sangkap kinahanglan nga bantayan.

Kung espesipiko nga naghisgot kami bahin sa PostgreSQL, nan kini mahimong irepresentar sa ingon nga laraw, nga naglangkob sa daghang mga sangkap. Kini nga mga sangkap nakig-uban sa usag usa. Ug sa samang higayon, ang PostgreSQL adunay gitawag nga Stats Collector subsystem, nga nagtugot kanimo sa pagkolekta sa mga estadistika mahitungod sa operasyon niini nga mga subsystem ug paghatag ug interface sa administrator o user aron iyang matan-aw kini nga mga estadistika.

Kini nga estadistika gipresentar sa porma sa pipila ka hugpong sa mga gimbuhaton ug mga panglantaw (pagtan-aw). Matawag usab sila nga mga lamesa. Kana mao, gamit ang usa ka regular nga kliyente sa psql, mahimo nimong makonektar sa database, pilia kini nga mga gimbuhaton ug panan-aw, ug makakuha pipila nga piho nga mga numero bahin sa operasyon sa mga subsystem sa PostgreSQL.

Mahimo nimong idugang kini nga mga numero sa imong paborito nga sistema sa pag-monitor, pagdrowing og mga graph, pagdugang mga bahin ug pagkuha mga analytics sa kadugayan.

Apan sa kini nga taho, dili nako tabonan ang tanan nga kini nga mga gimbuhaton nga wala’y eksepsiyon, tungod kay mahimo kini usa ka tibuuk nga adlaw. Literal nga akong hisgotan ang duha, tulo o upat ka butang ug isulti ko kanimo kung giunsa nila pagtabang nga mas maayo ang pagmonitor.

Ug kung maghisgot kita bahin sa pag-monitor sa database, unsa ang kinahanglan nga bantayan? Una sa tanan, kinahanglan natong bantayan ang pagkaanaa, tungod kay ang database usa ka serbisyo nga naghatag og access sa datos sa mga kliyente ug kinahanglan natong bantayan ang pagkaanaa, ug paghatag usab sa pipila sa mga qualitative ug quantitative nga mga kinaiya niini.

Kinahanglan usab namon nga bantayan ang mga kliyente nga nagkonektar sa among database, tungod kay mahimo silang parehas nga normal nga mga kliyente ug makadaot nga mga kliyente nga makadaot sa database. Kinahanglan usab sila nga bantayan ug bantayan.

Kung ang mga kliyente magkonektar sa database, klaro nga nagsugod sila sa pagtrabaho sa among data, busa kinahanglan namon nga bantayan kung giunsa ang pagtrabaho sa mga kliyente sa datos: kung unsang mga lamesa, sa gamay nga gidak-on kung diin ang mga indeks. Sa ato pa, kinahanglan naton nga susihon ang workload nga gihimo sa atong mga kliyente.

Apan ang workload naglangkob usab, siyempre, sa mga hangyo. Ang mga aplikasyon nagkonektar sa database, nag-access sa datos gamit ang mga pangutana, mao nga importante ang pagtimbang-timbang kon unsa nga mga pangutana ang anaa sa database, pag-monitor sa ilang pagkaigo, nga kini dili hiwi nga gisulat, nga ang pipila ka mga kapilian kinahanglan nga isulat pag-usab ug himoon aron sila molihok nga mas paspas ug uban sa mas maayo nga performance.

Ug tungod kay naghisgot kami bahin sa database, ang database kanunay nga mga proseso sa background. Ang mga proseso sa background nagtipig sa pasundayag sa database sa usa ka maayo nga lebel, mao nga nanginahanglan sila usa ka piho nga kantidad sa mga kapanguhaan alang sa ilang kaugalingon aron makadagan. Ug sa samang higayon, mahimo silang magsapaw sa mga kapanguhaan sa hangyo sa kliyente, mao nga ang hakog nga trabaho sa mga proseso sa background mahimong direktang makaapekto sa paghimo sa mga hangyo sa kliyente. Busa, kinahanglan usab sila nga bantayan ug bantayan aron wala’y mga pagtuis sa mga termino sa mga proseso sa background.

Ug kana ang tanan sa mga termino sa pag-monitor sa database nagpabilin sa sukatan sa sistema. Apan tungod kay sa kadaghanan nga bahin ang among tibuuk nga imprastraktura moadto sa mga panganod, ang mga sukatan sa sistema sa usa ka indibidwal nga host kanunay nga mawala sa background. Apan sa mga database, kini may kalabutan gihapon ug, siyempre, kinahanglan usab nga bantayan ang mga sukatan sa sistema.

Uban sa mga sukatan sa sistema, ang tanan labi pa o dili kaayo maayo, ang tanan nga mga modernong sistema sa pag-monitor nagsuporta na niini nga mga sukatan, apan sa kinatibuk-an, ang pipila nga mga sangkap dili pa igo ug pipila ka mga butang ang kinahanglan idugang. Tandogon ko usab sila, daghang mga slide ang bahin nila.

Ang unang punto sa plano mao ang accessibility. Unsa ang accessibility? Ang pagkaanaa sa akong pagsabot mao ang abilidad sa base sa pag-alagad sa mga koneksyon, nga mao, ang base gipataas, kini, isip usa ka serbisyo, nagdawat sa mga koneksyon gikan sa mga kliyente. Ug kini nga accessibility mahimong masusi pinaagi sa pipila ka mga kinaiya. Kini nga mga kinaiya sayon ​​​​kaayo nga ipakita sa mga dashboard.

Nahibal-an sa tanan kung unsa ang mga dashboard. Kini sa dihang imong gitan-aw ang screen, nga nagsumada sa gikinahanglang impormasyon. Ug mahimo na nimo nga mahibal-an dayon kung adunay problema sa database o wala.
Tungod niini, ang pagkaanaa sa database ug uban pang hinungdanon nga mga kinaiya kinahanglan kanunay nga ibutang sa mga dashboard aron kini nga kasayuran anaa sa kamot, kanunay kanimo. Ang pipila ka dugang nga mga detalye nga nakatabang na sa imbestigasyon sa mga insidente, sa imbestigasyon sa pipila ka emerhensya nga mga sitwasyon, sila na kinahanglan nga ibutang sa secondary dashboards, o gitagoan sa drilldown links nga mosangpot ngadto sa ikatulo nga-partido monitoring nga sistema.

Usa ka pananglitan sa usa ka nailhan nga sistema sa pagmonitor. Kini usa ka cool kaayo nga sistema sa pag-monitor. Nagkolekta kini og daghang mga datos, apan gikan sa akong panglantaw, kini adunay usa ka katingad-an nga konsepto sa mga dashboard. Adunay usa ka link nga "Paghimo Dashboard". Apan kung maghimo ka usa ka dashboard, maghimo ka usa ka lista sa duha ka kolum, usa ka lista sa mga tsart. Ug kung kinahanglan nimo nga tan-awon ang usa ka butang, magsugod ka sa pag-klik, pag-scroll, pagpangita sa gusto nga tsart gamit ang mouse. Ug kini nagkinahanglan og panahon, ie walay mga dashboard nga ingon niana. Adunay mga lista lamang sa mga tsart.

Unsa ang kinahanglan idugang niini nga mga dashboard? Mahimo ka magsugod sa usa ka kinaiya sama sa oras sa pagtubag. Ang PostgreSQL adunay pg_stat_statements view. Gi-disable kini pinaagi sa default, apan usa kini sa hinungdanon nga pagtan-aw sa sistema nga kinahanglan kanunay nga magamit ug magamit. Gitipigan niini ang kasayuran bahin sa tanan nga nagdagan nga mga pangutana nga gipatuman sa database.

Tungod niini, makasugod kita gikan sa kamatuoran nga mahimo natong makuha ang kinatibuk-ang oras sa pagpatuman sa tanan nga mga hangyo ug bahinon sa gidaghanon sa mga hangyo gamit ang mga natad sa ibabaw. Apan kini usa ka kasagaran nga temperatura sa ospital. Makatukod kami sa ubang mga natad - ang minimum nga oras sa pagpatuman sa pangutana, ang maximum ug ang median. Ug makahimo pa gani kita og mga porsyento, ang PostgreSQL adunay katugbang nga mga gimbuhaton alang niini. Ug makakuha kami pipila ka mga numero nga nagpaila sa oras sa pagtubag sa among database alang sa nahuman na nga mga hangyo, i.e. dili namon ipatuman ang peke nga 'pagpili sa 1' nga hangyo ug tan-awon ang oras sa pagtubag, apan among analisahon ang oras sa pagtubag alang sa nahuman na nga mga hangyo ug magdrowing usa ka bulag nga numero, o maghimo kami usa ka graph base niini.

Importante usab ang pagsubay sa gidaghanon sa mga sayop nga gihimo karon sa sistema. Ug alang niini mahimo nimong gamiton ang pg_stat_database view. Gitarget namo ang xact_rollback field. Kini nga natad dili lamang nagpakita sa gidaghanon sa mga rollback nga mahitabo sa database, apan giisip usab ang gidaghanon sa mga sayop. Sa relatibo nga pagsulti, mahimo natong ipakita kini nga numero sa atong dashboard ug tan-awon kung pila ang mga sayup nga naa sa karon. Kung adunay daghang mga kasaypanan, nan kini usa ka maayong rason sa pagtan-aw sa mga troso ug tan-awon kung unsa nga matang sa mga sayup kini ug ngano nga kini mahitabo, ug dayon mamuhunan ug masulbad kini.

Mahimo nimong idugang ang usa ka butang sama sa usa ka Tachometer. Kini ang gidaghanon sa mga transaksyon matag segundo ug ang gidaghanon sa mga hangyo matag segundo. Sa relatibong pagsulti, mahimo nimong gamiton kini nga mga numero isip kasamtangan nga performance sa imong database ug tan-awa kung adunay mga peak sa mga hangyo, mga peak sa mga transaksyon, o, sa kasukwahi, ang database kulang sa karga tungod kay ang usa ka matang sa backend nahulog. Mahinungdanon nga kanunay nga tan-awon kini nga numero ug hinumdomi nga alang sa among proyekto ang ingon nga pasundayag normal, ug ang mga kantidad sa ibabaw ug sa ubos usa na ka matang sa problema ug dili masabtan, nga nagpasabut nga kinahanglan naton tan-awon kung ngano ang ingon nga mga numero. .

Aron mabanabana ang gidaghanon sa mga transaksyon, mahimo na usab natong i-refer ang pg_stat_database view. Mahimo natong idugang ang gidaghanon sa mga pasalig ug ang gidaghanon sa mga rollback aron makuha ang gidaghanon sa mga transaksyon kada segundo.

Ang tanan nakasabut nga daghang mga hangyo ang mahimong mohaum sa usa ka transaksyon? Busa ang TPS ug QPS gamay nga lahi.

Ang gidaghanon sa mga hangyo matag segundo makuha gikan sa pg_stat_statements ug kalkulado lang ang sumada sa tanang gipatuman nga mga hangyo. Kini mao ang tin-aw nga atong itandi ang kasamtangan nga bili uban sa miaging usa, kuhaa, kuhaa ang delta, kuhaa ang kantidad.

Mahimo nimong idugang ang dugang nga mga sukatan kung gusto nimo, nga makatabang usab sa pagsusi sa pagkaanaa sa among database ug pagsubay kung adunay bisan unsang downtime.

Usa sa kini nga mga sukatan mao ang oras sa pag-up. Apan ang uptime sa PostgreSQL medyo lisud. Sultihan ko ikaw kung ngano. Kung magsugod ang PostgreSQL, magsugod kini sa pagreport sa oras sa pag-up. Apan kung sa usa ka punto, pananglitan, adunay usa ka buluhaton nga nagdagan sa gabii, usa ka OOM-killer ang miabot ug gipugos nga gitapos ang proseso sa bata nga PostgreSQL, nan sa kini nga kaso gitapos sa PostgreSQL ang koneksyon sa tanan nga mga kliyente, gi-reset ang lugar nga na-sharded nga memorya ug nagsugod sa pagkaayo gikan sa ang katapusan nga checkpoint. Ug samtang kini nga pagbawi gikan sa checkpoint molungtad, ang database dili modawat sa mga koneksyon, nga mao, kini nga sitwasyon mahimong masusi ingon nga downtime. Apan dili kini i-reset ang uptime counter, tungod kay gikonsiderar ang oras nga gisugdan ang postmaster gikan sa una nga higayon. Busa, ang ingon nga mga sitwasyon mahimong laktawan.

Kinahanglan usab nimo nga bantayan ang gidaghanon sa mga trabahante sa vacuum. Nahibal-an sa tanan kung unsa ang autovacuum sa PostgreSQL? Kini usa ka makapaikag nga subsystem sa PostgreSQL. Daghang mga artikulo ang gisulat bahin niini, daghang mga taho ang nahimo. Daghang diskusyon bahin sa vacuum, kung giunsa kini molihok. Daghan ang nag-isip niini nga gikinahanglang daotan. Apan kini mao. Kini usa ka matang sa tigkolekta sa basura nga naglimpyo sa karaan nga mga bersyon sa mga laray nga wala kinahanglana sa bisan unsang mga transaksyon ug nagpagawas sa luna sa mga lamesa ug mga indeks alang sa bag-ong mga laray.

Nganong kinahanglan man kining bantayan? Kay ang vacuum usahay sakit kaayo. Gikonsumo niini ang daghang mga kapanguhaan ug ang mga hangyo sa kliyente nagsugod sa pag-antos niini.

Ug kini kinahanglan nga bantayan pinaagi sa pg_stat_activity view, nga akong hisgutan sa sunod nga seksyon. Kini nga panglantaw nagpakita sa kasamtangan nga kalihokan sa database. Ug pinaagi niini nga kalihokan, masubay nato ang gidaghanon sa mga vacuum nga nagtrabaho karon. Mahimo natong bantayan ang mga vacuum ug tan-awon nga kung milapas na kita sa limitasyon, nan kini usa ka okasyon sa pagtan-aw sa mga setting sa PostgreSQL ug sa usa ka paagi ma-optimize ang operasyon sa vacuum.

Ang laing bahin sa PostgreSQL mao nga ang PostgreSQL sakit kaayo sa taas nga mga transaksyon. Ilabi na, gikan sa mga transaksyon nga nagbitay sa dugay nga panahon ug wala’y mahimo. Kini ang gitawag nga stat idle-in-transaction. Ang ingon nga transaksyon adunay mga kandado, kini nagpugong sa vacuum gikan sa pagtrabaho. Ug ingon nga resulta - ang mga lamesa nanghubag, sila nagdugang sa gidak-on. Ug ang mga pangutana nga nagtrabaho uban niini nga mga lamesa, nagsugod sila sa pagtrabaho nga mas hinay, tungod kay kinahanglan nimo nga pala ang tanan nga mga daan nga bersyon sa mga laray gikan sa memorya ngadto sa disk ug balik. Busa, ang oras, ang gidugayon sa pinakataas nga mga transaksyon, ang pinakataas nga mga hangyo sa vacuum kinahanglan usab nga bantayan. Ug kung atong makita ang pipila ka mga proseso nga nagdagan sa dugay nga panahon, labaw pa sa 10-20-30 ka minuto alang sa usa ka OLTP load, nan kinahanglan naton hatagan pagtagad kini ug pugson kini nga tapuson, o ma-optimize ang aplikasyon aron wala sila gitawag ug wala magbitay ug dugay. Alang sa usa ka analytical load, 10-20-30 ka minuto ang normal, adunay mas taas usab.

Sunod kita adunay kapilian sa konektado nga mga kliyente. Kung nakaporma na kami ug dashboard, nagbutang sa mga yawe nga sukatan sa pagka-access niini, mahimo usab namon nga idugang ang dugang nga kasayuran bahin sa mga konektado nga kliyente didto.

Ang impormasyon mahitungod sa konektado nga mga kliyente importante tungod kay, gikan sa punto sa panglantaw sa PostgreSQL, adunay lain-laing mga matang sa mga kliyente. Adunay maayo nga mga kliyente ug adunay dili maayo nga mga kliyente.

Usa ka yano nga pananglitan. Pinaagi sa kliyente, gipasabut nako ang aplikasyon. Ang aplikasyon konektado sa database ug diha-diha dayon nagsugod sa pagpadala sa iyang mga hangyo didto, ang database nagproseso ug nagpatuman niini, ug nagbalik sa mga resulta ngadto sa kliyente. Kini mga maayo ug husto nga mga kliyente.

Adunay mga sitwasyon nga ang kliyente konektado, kini nagpadayon sa koneksyon, apan wala'y mahimo. Anaa kini sa idle state.

Apan adunay dili maayo nga mga kliyente. Pananglitan, ang parehas nga kliyente nagkonektar, nagbukas sa usa ka transaksyon, naghimo usa ka butang sa database, ug dayon miadto sa code, pananglitan, aron ma-access ang usa ka eksternal nga gigikanan o iproseso ang nadawat nga datos didto. Apan sa samang higayon, wala niya sirad-i ang transaksyon. Ug ang transaksyon nagbitay sa database ug nagkupot sa kandado sa linya. Kini usa ka dili maayo nga kahimtang. Ug kung kalit nga ang aplikasyon sa usa ka lugar sa sulod nahulog sa usa ka eksepsiyon (Exception), nan ang transaksyon mahimong magpabilin nga bukas sa dugay nga panahon. Ug kini direktang nakaapekto sa pasundayag sa PostgreSQL. Ang PostgreSQL modagan nga mas hinay. Busa, hinungdanon nga masubay ang ingon nga mga kliyente sa oras ug pugson nga tapuson ang ilang trabaho. Ug kinahanglan nimo nga ma-optimize ang imong aplikasyon aron wala’y ingon nga mga sitwasyon.

Ang ubang dili maayo nga mga kliyente naghulat nga mga kliyente. Apan sila mahimong daotan tungod sa mga kahimtang. Pananglitan, ang usa ka yano nga walay pulos nga transaksyon: kini makaabli sa usa ka transaksyon, maka-lock sa pipila ka mga linya, unya kini mahulog sa usa ka dapit sa code, nga magbilin sa usa ka nagbitay nga transaksyon. Ang lain nga kliyente moabut, mangayo sa parehas nga datos, apan makasugat kini usa ka kandado, tungod kay kana nga nagbitay nga transaksyon adunay mga kandado sa pipila nga kinahanglan nga mga laray. Ug ang ikaduha nga transaksyon magbitay sa pagpaabut kung mahuman ang una nga transaksyon o ang tagdumala niini pugson nga pasirad-an. Sa ingon, ang mga pending nga mga transaksyon mahimong makaipon ug moawas sa limitasyon sa koneksyon sa database. Ug kung puno na ang limitasyon, ang aplikasyon dili na magamit sa database. Kini usa na ka emerhensya nga kahimtang alang sa proyekto. Busa, ang dili maayo nga mga kustomer kinahanglan nga masubay ug tubagon sa tukma sa panahon nga paagi.

Laing pananglitan sa pagmonitor. Ug ania ang usa ka desente nga dashboard. Adunay impormasyon sa mga koneksyon gikan sa ibabaw. Koneksyon sa DB - 8 ka piraso. Ug kini tanan. Wala kami kasayuran bahin sa kung unsang mga kliyente ang aktibo, kung kinsa ang mga kliyente nga wala’y nahimo, wala’y gibuhat. Wala’y kasayuran bahin sa pagbitay sa mga transaksyon ug mga pending nga koneksyon, i.e. kini usa ka numero nga nagpakita sa gidaghanon sa mga koneksyon ug mao kana. Ug unya pagtag-an sa imong kaugalingon.

Busa, aron madugang kini nga impormasyon sa pagmonitor, kinahanglan nimo nga i-refer ang pg_stat_activity system view. Kung mogugol ka ug daghang oras sa PostgreSQL, nan kini usa ka maayo kaayo nga pagtan-aw nga mahimo nimong higala, tungod kay kini nagpakita sa karon nga kalihokan sa PostgreSQL, ie kung unsa ang nahitabo niini. Adunay usa ka bulag nga linya alang sa matag proseso nga nagpakita sa kasayuran bahin niini nga proseso: gikan diin ang host gihimo ang koneksyon, sa ilawom sa unsang tiggamit, sa ilalum sa unsa nga ngalan, kanus-a nagsugod ang transaksyon, unsa nga hangyo ang karon gipatuman, unsa nga hangyo ang katapusan nga gipatuman. Ug, sumala niana, mahimo natong susihon ang kahimtang sa kliyente pinaagi sa stat field. Sa relatibong pagkasulti, mahimo kitang mag-grupo sa kini nga natad ug makuha ang mga estadistika nga naa karon sa database ug ang gidaghanon sa mga koneksyon nga kauban niini nga estadistika sa database. Ug mahimo namong ipadala ang nadawat na nga mga numero sa among pagmonitor ug pagdrowing og mga graph niini.
Importante usab ang pagtimbang-timbang sa gidugayon sa transaksyon. Gisulti na nako nga hinungdanon ang pagtimbang-timbang sa gidugayon sa mga vacuum, apan ang mga transaksyon gisusi usab sa parehas nga paagi. Adunay xact_start ug query_start fields. Sila, medyo nagsulti, nagpakita sa oras sa pagsugod sa transaksyon ug sa oras sa pagsugod sa hangyo. Gikuha namo ang now() function, nga nagpakita sa kasamtangan nga timestamp, ug kuhaan ang transaksyon ug hangyo og timestamp. Ug makuha namo ang gidugayon sa transaksyon, ang gidugayon sa hangyo.

Kung makakita kita ug taas nga mga transaksyon, kinahanglan na naton kini makompleto. Alang sa OLTP load, ang taas nga mga transaksyon labaw na sa 1-2-3 ka minuto. Para sa OLAP load, normal ra ang taas nga mga transaksyon, pero kung molapas sa duha ka oras, timailhan sab ni nga naa tay likoanan sa usa ka dapit.

Kung nakakonekta na ang mga kliyente sa database, magsugod sila sa pagtrabaho sa among datos. Gi-access nila ang mga lamesa, gi-access nila ang mga indeks aron makakuha mga datos gikan sa usa ka lamesa. Ug hinungdanon nga susihon kung giunsa ang pagtrabaho sa mga kostumer sa kini nga datos.

Kinahanglan kini aron masusi ang among workload ug masabtan kung unsang mga lamesa ang among "pinakainit". Pananglitan, kini gikinahanglan sa mga sitwasyon diin gusto natong ibutang ang "init" nga mga lamesa sa usa ka matang sa paspas nga pagtipig sa SSD. Pananglitan, ang pipila ka mga lamesa sa archive nga wala namo gigamit sa dugay nga panahon mahimong ibalhin sa usa ka matang sa "bugnaw" nga archive, ngadto sa SATA disks ug pabay-i sila nga magpuyo didto, sila ma-access kung gikinahanglan.

Mapuslanon usab kini sa pag-ila sa mga anomaliya pagkahuman sa bisan unsang pagpagawas ug pag-deploy. Ingnon ta nga ang proyekto naglunsad og pipila ka bag-ong feature. Pananglitan, gidugang namo ang bag-ong gamit para sa pagtrabaho kauban ang database. Ug kung magtukod kita og mga graph alang sa paggamit sa mga lamesa, dali natong mamatikdan kini nga mga anomaliya niini nga mga graph. Pananglitan, i-update ang mga burst o delete ang mga burst. Kini makita kaayo.

Posible usab nga makit-an ang mga anomaliya sa mga estadistika nga "nalutaw". Unsay buot ipasabot niini? Ang PostgreSQL adunay kusgan kaayo ug maayo kaayo nga tigplano sa pangutana. Ug ang mga nag-develop naggugol ug daghang oras sa pag-uswag niini. Giunsa niya pagtrabaho? Aron makahimo og maayo nga mga plano, ang PostgreSQL nagkolekta sa mga estadistika mahitungod sa pag-apod-apod sa datos sa mga lamesa nga adunay piho nga agwat sa panahon, nga adunay pipila ka periodicity. Kini ang labing kanunay nga mga kantidad: ang gidaghanon sa mga talagsaon nga mga kantidad, kasayuran bahin sa NULL sa lamesa, daghang kasayuran.

Pinasukad niini nga mga estadistika, ang tigplano nagtukod og daghang mga pangutana, nagpili sa usa nga labing maayo, ug gigamit kini nga plano sa pangutana aron ipatuman ang pangutana mismo ug ibalik ang datos.

Ug mahitabo nga ang mga estadistika "naglutaw". Ang kalidad ug gidaghanon nga datos sa usa ka paagi nausab sa lamesa, apan ang mga estadistika wala makolekta. Ug ang mga plano nga naporma mahimong dili maayo. Ug kung ang among mga plano mahimong suboptimal sa mga termino sa pag-monitor nga nakolekta, sumala sa mga lamesa, makita namon kini nga mga anomaliya. Pananglitan, sa usa ka dapit ang datos nausab sa qualitatively ug imbes sa index, usa ka sequential pass pinaagi sa lamesa nagsugod nga gigamit, i.e. kung ang pangutana kinahanglan nga ibalik lamang ang 100 ka laray (adunay limitasyon sa 100), nan usa ka tibuuk nga pag-ihap ang himuon alang niini nga pangutana. Ug kini kanunay adunay dili maayo nga epekto sa pasundayag.

Ug makita nato kini sa pagmonitor. Ug tan-awa na kini nga pangutana, ipahigayon ang pagpatin-aw alang niini, pagkolekta sa mga estadistika, paghimo og bag-ong dugang nga indeks. Ug pagtubag na niini nga problema. Busa kini importante.

Laing pananglitan sa pagmonitor. Nagtuo ko nga daghan ang nakaila niya kay sikat kaayo siya. Kinsa ang naggamit sa ilang mga proyekto Prometheus? Ug kinsa ang naggamit niini nga produkto inubanan sa Prometheus? Ang tinuod mao nga sa standard nga repository sa kini nga pag-monitor adunay usa ka dashboard alang sa pagtrabaho kauban ang PostgreSQL - postgres_exporter Prometheus. Apan adunay usa ka dili maayo nga detalye dinhi.

Adunay daghang mga tsart. Ug ang mga byte gipiho isip panaghiusa, i.e. adunay 5 ka mga graph. Kini mao ang Insert data, Update data, Delete data, Fetch data ug Return data. Ang mga byte gipiho isip dimensyon sa yunit. Apan ang tinuod mao nga ang mga estadistika sa PostgreSQL nagbalik sa datos sa tuple (mga linya). Ug, sumala niana, kini nga mga graph usa ka maayo kaayo nga paagi aron maminusan ang imong trabaho sa daghang beses, daghang beses, tungod kay ang usa ka tuple dili usa ka byte, usa ka tuple usa ka hilo, kini daghang mga byte ug kini kanunay nga variable nga gitas-on. Kana mao, ang pagkalkulo sa workload sa bytes gamit ang tuples usa ka dili realistiko nga buluhaton o lisud kaayo. Busa, kung mogamit ka usa ka dashboard o built-in nga pag-monitor, kanunay nga hinungdanon nga masabtan nga kini molihok sa husto ug ibalik ang husto nga gisusi nga datos kanimo.

Giunsa pagkuha ang mga istatistika sa kini nga mga lamesa? Aron mahimo kini, ang PostgreSQL adunay usa ka pamilya sa mga panan-aw. Ug ang nag-unang panglantaw mao pg_stat_user_tables. User_tables - kini nagpasabot nga ang mga lamesa gihimo alang sa user. Sa kasukwahi, adunay mga pagtan-aw sa sistema, nga gigamit mismo sa PostgreSQL. Ug adunay usa ka summary table Alltables, nga naglakip sa sistema ug user. Mahimo ka magsugod gikan sa bisan kinsa kanila nga labing gusto nimo.

Ang mga natad sa ibabaw mahimong magamit sa pagbanabana sa gidaghanon sa mga pagsal-ot, pag-update, ug pagtangtang. Ang panig-ingnan nga dashboard nga akong gigamit naggamit niini nga mga natad sa pagtimbang-timbang sa mga kinaiya sa workload. Busa, makatukod usab kita niini. Apan angay nga hinumdoman nga kini mga tuple, dili mga byte, mao nga dili naton kini makuha ug mahimo kini nga mga byte.

Pinasukad sa kini nga mga datos, mahimo naton tukuron ang gitawag nga TopN-tables. Pananglitan, Top-5, Top-10. Ug mahimo nimong masubay ang mga mainit nga lamesa nga gigamit labi pa sa uban. Pananglitan, 5 ka "init" nga mga lamesa alang sa pagsal-ot. Ug sumala sa kini nga mga TopN-table, among gisusi ang among workload ug mahimo nga magtimbang-timbang sa mga pagbuto sa workload pagkahuman sa bisan unsang pagpagawas ug pag-update, ug pag-deploy.

Importante usab ang pagtimbang-timbang sa gidak-on sa lamesa, tungod kay usahay ang mga developers mopagawas sa usa ka bag-ong feature, ug ang among mga lamesa magsugod sa pag-ulbo sa ilang dagkong mga gidak-on, tungod kay sila nakahukom sa pagdugang sa dugang nga kantidad sa datos, apan wala magtagna kon sa unsang paagi kini mahitabo. makaapekto sa gidak-on sa database. Ang ingon nga mga kaso moabut usab ingon mga sorpresa alang kanamo.

Ug karon usa ka gamay nga pangutana alang kanimo. Unsa ang pangutana kung imong namatikdan ang load sa database server? Unsa ang imong sunod nga pangutana?

Apan ang tinuod nga pangutana mao ang mosunod. Unsa nga mga hangyo ang hinungdan sa pagkarga? Sa ato pa, dili makapaikag nga tan-awon ang mga proseso nga gipahinabo sa pagkarga. Klaro nga kung ang host adunay database, nan ang database nagdagan didto ug klaro nga ang mga database ra ang ilabay didto. Kung among ablihan ang Top, among makita didto ang usa ka lista sa mga proseso sa PostgreSQL nga adunay gibuhat. Gikan sa Ibabaw dili klaro kung unsa ang ilang gibuhat.

Tungod niini, kinahanglan nimo nga pangitaon ang mga pangutana nga hinungdan sa labing kadaghan nga load, tungod kay ang pag-tune sa pangutana, ingon usa ka lagda, naghatag dugang nga ganansya kaysa sa pag-configure sa PostgreSQL o pag-tune sa operating system, o bisan ang pag-tune sa hardware. Sumala sa akong banabana, kini mga 80-85-90%. Ug kini nahimo nga mas paspas. Mas paspas ang pagtul-id sa hangyo kay sa pagkorihir sa configuration, pag-iskedyul og restart, ilabi na kung ang database dili ma-restart, o makadugang sa hardware. Mas sayon ​​ang pagsulat pag-usab sa pangutana sa usa ka dapit o pagdugang og indeks aron makakuha og mas maayong resulta gikan niini nga pangutana.

Tungod niini, gikinahanglan ang pagmonitor sa mga hangyo ug ang ilang pagkaigo. Atong kuhaon ang laing pananglitan sa pagmonitor. Ug dinhi, usab, ingon nga maayo kaayo nga pag-monitor. Adunay kasayuran sa replikasyon, adunay kasayuran sa throughput, blocking, paggamit sa kapanguhaan. Maayo ang tanan, apan wala’y kasayuran sa mga hangyo. Dili klaro kung unsa nga mga pangutana ang nagdagan sa among database, kung unsa kadugay sila modagan, pila niini nga mga pangutana. Kinahanglan nga kanunay natong naa kini nga kasayuran sa pagmonitor.

Ug aron makuha kini nga kasayuran, magamit namon ang module nga pg_stat_statements. Sa basehan niini, makahimo ka og lain-laing mga graphic. Pananglitan, mahimo nimong makuha ang kasayuran sa labing kanunay nga mga hangyo, nga mao, sa mga hangyo nga kanunay nga gihimo. Oo, pagkahuman sa pag-deploy mapuslanon usab nga tan-awon kini ug masabtan kung adunay bisan unsang pagdagsang sa mga hangyo.

Mahimo nimong bantayan ang pinakataas nga mga hangyo, i.e. kadtong mga hangyo nga labing dugay nga makompleto. Nagdagan sila sa processor, gikonsumo nila ang I/O. Mahimo usab nato kini tan-awon pinaagi sa mga field total_time, mean_time, blk_write_time ug blk_read_time.

Kita makahimo sa pagtimbang-timbang ug pagmonitor sa pinakabug-at nga mga hangyo sa mga termino sa paggamit sa kapanguhaan, kadtong nagbasa gikan sa disk, kadtong nagtrabaho uban ang memorya, o, sa sukwahi, naghimo og usa ka matang sa pagsulat nga load.

Atong masusi ang labing manggihatagon nga mga hangyo. Kini ang mga pangutana nga nagbalik sa daghang mga linya. Pananglitan, kini mahimong usa ka matang sa hangyo diin sila nakalimot sa pagtakda og limitasyon. Ug gibalik lang niini ang tibuuk nga sulud sa lamesa o pangutana sa gihangyo nga mga lamesa.

Ug mahimo usab nimo nga bantayan ang mga pangutana nga naggamit temporaryo nga mga file o temporaryo nga mga lamesa.

Ug naa pa miy background nga mga proseso. Ang mga proseso sa background mao ang panguna nga mga checkpoint o kini gitawag usab nga mga checkpoint, kini mao ang autovacuum ug replikasyon.

Laing pananglitan sa pagmonitor. Adunay usa ka tab sa Maintenance sa wala, adto niini ug paglaum nga makakita og butang nga mapuslanon. Apan dinhi, ang panahon lamang sa vacuum ug ang pagkolekta sa mga estadistika, wala nay lain. Dili kaayo kini nga kasayuran, mao nga kinahanglan nimo kanunay nga adunay kasayuran kung giunsa ang mga proseso sa background molihok sa among database ug kung adunay mga problema gikan sa ilang trabaho.

Kung magtan-aw kita sa mga checkpoint, kinahanglan nga hinumdoman nga ang atong mga checkpoints nag-flush sa "hugaw" nga mga panid gikan sa sharded memory area ngadto sa disk, dayon maghimo og checkpoint. Ug kini nga checkpoint mahimo nang magamit ingon usa ka lugar sa panahon sa pagkaayo, kung ang PostgreSQL kalit nga gitapos sa usa ka emerhensya.

Busa, aron ma-flush ang tanan nga "hugaw" nga mga panid sa disk, kinahanglan nimo nga buhaton ang usa ka piho nga kantidad sa pagsulat. Ug, ingon nga usa ka lagda, sa mga sistema nga adunay daghang panumduman, daghan kini. Ug kung maghimo kami og mga checkpoint kanunay sa pipila ka mubo nga agwat, nan ang performance sa disk mohinay pag-ayo. Ug ang mga hangyo sa kliyente mag-antus tungod sa kakulang sa mga kapanguhaan. Makigsangka sila alang sa mga kapanguhaan ug kulang sa produktibo.

Subay niini, pinaagi sa pg_stat_bgwriter sa gitakdang mga field, mamonitor namo ang gidaghanon sa mga checkpoint nga mahitabo. Ug kung kita adunay daghang mga checkpoint sa usa ka piho nga yugto sa panahon (sa 10-15-20 minuto, tunga sa oras), pananglitan, 3-4-5, nan mahimo na kini nga problema. Ug kinahanglan nimo nga tan-awon ang database, tan-awa ang pagsumpo, kung unsa ang hinungdan sa daghang mga checkpoints. Tingali adunay moabut nga dagkong rekord. Mahimo na namo nga susihon ang workload, tungod kay nadugangan na namo ang workload charts. Mahimo na namon nga i-tweak ang mga parameter sa breakpoint ug siguruha nga dili kini makaapekto sa pasundayag sa pangutana.

Mobalik ko sa autovacuum pag-usab tungod kay kini ang matang sa butang, sama sa akong giingon, nga dali nga makadugang sa disk ug pagpangutana sa performance, mao nga kanunay nga importante ang pagsukod sa gidaghanon sa autovacuum.

Limitado ang gidaghanon sa mga trabahante sa autovacuum sa database. Sa kasagaran, adunay tulo niini, mao nga kung kami adunay tulo nga mga trabahante nga nagtrabaho sa database sa tanan nga oras, nan kini nagpasabut nga ang among autovacuum kulang sa pag-configure, kinahanglan namon nga ipataas ang mga limitasyon, usbon ang mga setting sa autovacuum ug mosaka na sa configuration.
Importante ang pagtimbang-timbang kung kinsa nga mga vacuum worker ang nagtrabaho alang kanato. Bisan kung kini gilunsad gikan sa tiggamit, ang DBA misulod ug naglansad og usa ka matang sa vacuum gamit ang mga kamot niini, ug kini nakamugna og usa ka load. Naa miy problema. O kini ang gidaghanon sa mga vacuum nga nagtangtang sa counter sa transaksyon. Alang sa pipila nga mga bersyon sa PostgreSQL, kini bug-at kaayo nga mga vacuum. Ug dali ra silang makadugang sa pasundayag tungod kay ilang giminusan ang tibuuk nga lamesa, gi-scan ang tanan nga mga bloke sa kini nga lamesa.

Ug, siyempre, ang gidugayon sa mga vacuum. Kung kita adunay taas nga mga vacuum nga nagdagan sa dugay nga panahon, nan kini nagpasabut nga kinahanglan naton hatagan pag-usab ang pagtagad sa pag-configure sa vacuum ug tingali ikonsiderar ang mga setting niini. Tungod kay ang usa ka sitwasyon mahimong motumaw sa diha nga ang vacuum nagtrabaho sa lamesa sa dugay nga panahon (3-4 ka oras), apan sa panahon sa pagtrabaho sa vacuum, ang usa ka dako nga kantidad sa patay nga mga laray pag-usab nakahimo sa pagtigum sa lamesa. Ug sa diha nga ang vacuum mahuman na, kinahanglan niya nga i-vacuum kini nga lamesa pag-usab. Ug miabut kami sa usa ka sitwasyon - usa ka walay katapusan nga vacuum. Ug sa kini nga kaso, ang vacuum dili makasagubang sa iyang trabaho, ug ang mga lamesa nagsugod sa hinay-hinay nga pag-ulbo sa gidak-on, bisan kung ang gidaghanon sa mapuslanon nga datos niini nagpabilin nga pareho. Busa, sa taas nga mga vacuum, kanunay namong gitan-aw ang configuration ug gisulayan nga ma-optimize kini, apan sa samang higayon, aron ang paghimo sa mga hangyo sa kliyente dili mag-antus.

Karon halos wala'y pag-instalar sa PostgreSQL diin wala'y streaming nga replikasyon. Ang pagkopya mao ang proseso sa pagbalhin sa datos gikan sa usa ka agalon ngadto sa usa ka replika.

Ang pagkopya sa PostgreSQL gihan-ay pinaagi sa usa ka log sa transaksyon. Ang agalon naghimo og usa ka log sa transaksyon. Ang log sa transaksyon sa koneksyon sa network moadto sa replika, unya kini gikopya sa replika. Simple ra ang tanan.

Tungod niini, ang pg_stat_replication view gigamit sa pagmonitor sa replication lag. Apan dili kini sayon ​​alang kaniya. Sa bersyon 10, ang pagtan-aw nakaagi sa daghang mga pagbag-o. Una, ang pipila sa mga natad giilisan og ngalan. Ug ang pipila sa mga natad gidugang. Sa ika-10 nga bersyon, nagpakita ang mga uma nga nagtugot kanimo sa pagtimbang-timbang sa lag sa pagkopya sa mga segundo. Komportable kaayo kini. Sa wala pa ang bersyon 10, posible nga mabanabana ang lag sa pagkopya sa mga byte. Kini nga bahin nagpabilin sa ika-10 nga bersyon, i.e. makapili ka kung unsa ang labi ka kombenyente alang kanimo - pagtimbang-timbang sa lag sa mga byte o pagtimbang-timbang sa lag sa mga segundo. Daghan ang nagbuhat sa duha.

Bisan pa, aron masusi ang lag sa pagkopya, kinahanglan nimo mahibal-an ang posisyon sa log sa transaksyon. Ug kini nga mga posisyon sa log sa transaksyon naa ra sa pagtan-aw sa pg_stat_replication. Sa relatibong pagkasulti, mahimo natong gamiton ang pg_xlog_location_diff() function sa pagkuha sa duha ka punto sa transaction log. Kalkulahin ang delta sa taliwala nila ug kuhaa ang replication lag sa bytes. Kini sayon ​​​​kaayo ug yano.

Sa bersyon 10 kini nga function giilisan og ngalan sa pg_wal_lsn_diff(). Sa kinatibuk-an, sa tanan nga mga gimbuhaton, mga panglantaw, mga utilities, diin ang pulong "xlog" nasugatan, kini gipulihan sa bili "wal". Kini anaa sa mga panglantaw ug sa mga gimbuhaton. Kini usa ka kabag-ohan.

Dugang pa, sa ika-10 nga bersyon, ang mga linya gidugang nga espesipikong nagpakita sa lag. Kini mao ang write lag, flush lag, replay lag. Sa ato pa, importante nga bantayan kining mga butanga. Kung atong makita nga kita adunay usa ka replication lag, nan kinahanglan natong imbestigahan kung nganong kini nagpakita, diin kini gikan ug ayuhon ang problema.

Uban sa mga sukatan sa sistema, hapit tanan naa sa kahusay. Kung matawo ang bisan unsang pag-monitor, magsugod kini sa mga sukatan sa sistema. Kini ang paggamit sa mga processor, memorya, swap, network ug disk. Apan bisan pa, daghang mga parameter ang wala didto pinaagi sa default.

Kung ang tanan naa sa kahusay sa paglabay sa proseso, nan adunay mga problema sa paglabay sa disk. Ingon sa usa ka lagda, ang pagmonitor sa mga developers nagdugang sa impormasyon sa bandwidth. Mahimo kini sa iops o bytes. Apan nakalimtan nila ang bahin sa latency ug paggamit sa disk device. Kini ang labi ka hinungdanon nga mga parameter nga nagtugot kanamo sa pagtimbang-timbang kung giunsa ang pagkarga sa among mga disk ug kung unsa kini kahinay. Kung kita adunay taas nga latency, nan kini nagpasabut nga adunay pipila ka mga problema sa mga disk. Kung kita adunay taas nga paggamit, nan kini nagpasabut nga ang mga disk dili makasagubang. Kini mas mga kwalitatibo nga mga kinaiya kay sa bandwidth.

Bisan pa, kini nga mga estadistika mahimo usab nga makuha gikan sa /proc file system, sama sa gihimo alang sa pag-recycle sa processor. Ngano nga kini nga kasayuran wala idugang sa pag-monitor, wala ako kahibalo. Apan importante gihapon nga anaa kini sa imong pagmonitor.

Tinuod usab kini alang sa mga interface sa network. Adunay kasayuran bahin sa bandwidth sa network sa mga pakete, sa mga byte, apan bisan pa wala’y kasayuran bahin sa latency ug wala’y kasayuran bahin sa paggamit, bisan kung kini mapuslanon usab nga kasayuran.

Ang bisan unsang pag-monitor adunay mga kakulangan. Ug bisan unsa nga matang sa pag-monitor ang imong buhaton, kini kanunay mapakyas sa pagkab-ot sa pipila ka mga criteria. Apan bisan pa niana, nag-uswag sila, gidugang ang mga bag-ong bahin, bag-ong mga butang, busa pagpili usa ka butang ug tapusa kini.

Ug aron makahuman, kinahanglan ka kanunay adunay ideya kung unsa ang gipasabut sa gihatag nga estadistika ug kung giunsa nimo masulbad ang mga problema niini.

Ug pipila ka importanteng punto:

• Kinahanglan nimo kanunay nga bantayan ang pagkaanaa, adunay mga dashboard aron dali nimo masusi nga ang tanan naa sa sukaranan.
• Kinahanglan nimo kanunay nga adunay usa ka ideya kung unsang mga kliyente ang nagtrabaho sa imong database aron makuha ang dili maayo nga mga kliyente ug pusilon sila.
• Mahinungdanon ang pagtimbang-timbang kung giunsa kini nga mga kliyente nagtrabaho sa datos. Kinahanglan nga adunay ka ideya bahin sa imong workload.
• Mahinungdanon ang pagtimbang-timbang kung giunsa naporma kini nga workload, sa tabang sa kung unsang mga pangutana. Mahimo nimong susihon ang mga pangutana, mahimo nimo nga ma-optimize kini, i-refactor kini, maghimo mga indeks alang kanila. Importante kaayo kini.
• Ang mga proseso sa background mahimong negatibong makaapekto sa mga hangyo sa kliyente, busa importante nga siguroon nga dili sila mogamit og daghang mga kapanguhaan.
• Gitugotan ka sa mga sukatan sa sistema sa paghimo og mga plano alang sa pag-scale, alang sa pagdugang sa kapasidad sa imong mga server, busa hinungdanon nga masubay ug susihon usab sila.

Kung interesado ka sa kini nga hilisgutan, mahimo nimong sundon kini nga mga link.
http://bit.do/stats_collector mao ang opisyal nga dokumentasyon gikan sa kolektor sa estadistika. Adunay usa ka paghulagway sa tanan nga mga pagtan-aw sa istatistika ug usa ka paghulagway sa tanan nga mga natad. Mahimo nimong basahon, sabton ug analisahon kini. Ug sa basehan nila, paghimo og imong kaugalingon nga mga tsart, idugang sa imong pag-monitor.

Paghangyo og mga pananglitan:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Kini ang among corporate repository ug akong kaugalingon. Naa silay sample requests. Walay mga pangutana gikan sa pinili* gikan sa serye, usa ka butang didto. Anaa na ang mga andam nga gihimo nga mga hangyo nga adunay mga pag-apil, gamit ang makapaikag nga mga gimbuhaton nga nagtugot kanimo sa paghimo nga mabasa, kombenyente nga mga kantidad gikan sa hilaw nga mga numero, nga mao, kini mga byte, oras. Mahimo nimong pilion sila, tan-awa sila, analisahon kini, idugang kini sa imong mga pag-monitor, paghimo og imong kaugalingon nga mga pag-monitor base sa kanila.

Ang imong mga pangutana

Pangutana: Miingon ka nga dili ka mag-anunsyo sa mga tatak, apan naghunahuna gihapon ko - unsa nga klase nga mga dashboard ang imong gigamit sa imong mga proyekto?
Tubag: Sa lainlaing paagi. Nahitabo nga naa mi sa customer ug naa na siyay kaugalingong monitoring. Ug among gitambagan ang kustomer kung unsa ang kinahanglan idugang sa iyang pagmonitor. Ang pinakagrabe nga sitwasyon mao ang Zabbix. Tungod kay wala kini abilidad sa paghimo sa TopN-graphics. Kami mismo ang naggamit Okmetertungod kay among gikonsulta kining mga tawhana sa pagmonitor. Gihimo nila ang pagmonitor sa PostgreSQL base sa among TOR. Nagsulat ko sa akong kaugalingon nga pet-proyekto, nga nagkolekta sa datos pinaagi sa Prometheus ug nagkuha niini grafana. Ang akong tahas mao ang paghimo sa akong kaugalingon nga exporter sa Prometheus ug dayon idrowing ang tanan sa Grafana.

Pangutana: Aduna bay bisan unsang mga analogue sa mga taho sa AWR o ... mga panagsama? Nahibal-an ba nimo ang usa ka butang nga sama niini?
Tubag: Oo, nahibal-an ko kung unsa ang AWR, kini usa ka cool nga butang. Sa pagkakaron, adunay lainlaing mga bisikleta nga nagpatuman sa gibana-bana nga mosunod nga modelo. Sa pila ka oras nga agwat, pipila ka mga baseline gisulat sa parehas nga PostgreSQL o sa usa ka lahi nga pagtipig. Mahimo nimo sila i-google sa Internet, sila. Usa sa mga nag-develop sa ingon nga butang naglingkod sa sql.ru forum sa PostgreSQL thread. Madakop nimo siya didto. Oo, adunay ingon nga mga butang, mahimo silang magamit. plus sa iyang pgCenter Nagsulat usab ako usa ka butang nga nagtugot kanimo sa pagbuhat sa ingon.

PS1 Kung postgres_exporter ang imong gigamit, unsa nga dashboard ang imong gigamit? Adunay pipila niini. Karaan na sila. Makahimo ba ang komunidad og bag-ong template?

Gikuha sa PS2 ang pganalyze tungod kay kini usa ka proprietary nga halad nga SaaS nga nagtutok sa pag-monitor sa performance ug mga sugyot sa automated tuning.

Ang mga rehistradong tiggamit lamang ang makaapil sa survey. Sign in, walay sapayan.

Unsang self-host nga postgresql monitoring (uban ang dashboard) sa imong hunahuna ang labing kaayo?

• 30,0%Zabbix + mga pagdugang gikan sa Alexey Lesovsky o zabbix 4.4 o libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%Ang pganalyze usa ka proprietary SaaS - dili makatangtang1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 ka tiggamit ang nagboto. 26 ka tiggamit ang nag-abstain.

Source: www.habr.com