Ninapendekeza usome nakala ya ripoti ya Nikolai Samokhvalov "Mbinu ya Viwanda ya kurekebisha PostgreSQL: majaribio kwenye hifadhidata"
Shared_buffers = 25% - ni nyingi au kidogo? Au sawa tu? Unajuaje ikiwa pendekezo hili - lililopitwa na wakati - linafaa katika kesi yako maalum?
Ni wakati wa kukabiliana na suala la kuchagua vigezo vya postgresql.conf "kama mtu mzima." Sio kwa usaidizi wa "viboreshaji otomatiki" vipofu au ushauri wa zamani kutoka kwa nakala na blogi, lakini kulingana na:
- majaribio yaliyothibitishwa madhubuti kwenye hifadhidata, yaliyofanywa kiotomatiki, kwa idadi kubwa na chini ya hali karibu iwezekanavyo ili "kupambana" na zile,
- uelewa wa kina wa vipengele vya DBMS na OS.
Kutumia Nancy CLI (), tutaangalia mfano maalum - sifa mbaya shared_buffers - katika hali tofauti, katika miradi tofauti na kujaribu kujua jinsi ya kuchagua mpangilio bora wa miundombinu yetu, hifadhidata na mzigo.
Tutazungumza juu ya majaribio na hifadhidata. Hii ni hadithi ambayo huchukua zaidi ya miezi sita.
Kidogo kuhusu mimi. Uzoefu na Postgres kwa zaidi ya miaka 14. Kampuni kadhaa za mitandao ya kijamii zimeanzisha. Postgres ilitumika na inatumika kila mahali.
Pia kikundi cha RuPostgres kwenye Meetup, nafasi ya 2 duniani. Tunakaribia watu 2 polepole. RuPostgres.org.
Na kwenye Kompyuta za mikutano mbali mbali, pamoja na Highload, ninawajibika kwa hifadhidata, haswa Postgres tangu mwanzo.
Na katika miaka michache iliyopita, nimeanzisha tena mazoezi yangu ya ushauri ya Postgres maeneo ya saa 11 kutoka hapa.
Na nilipofanya hivi miaka michache iliyopita, nilikuwa na mapumziko katika kazi ya mikono na Postgres, labda tangu 2010. Nilishangaa jinsi utaratibu wa kazi wa DBA umebadilika kidogo, na ni kazi ngapi ya mikono ambayo bado inahitaji kutumika. Na mara moja nilifikiria kuwa kuna kitu kibaya hapa, ninahitaji kubinafsisha zaidi ya kila kitu.
Na kwa kuwa yote yalikuwa ya mbali, wateja wengi walikuwa kwenye mawingu. Na mengi tayari yamejiendesha, ni wazi. Zaidi juu ya hili baadaye. Hiyo ni, yote haya yalisababisha wazo kwamba kunapaswa kuwa na idadi ya zana, yaani, aina fulani ya jukwaa ambayo itaendesha karibu vitendo vyote vya DBA ili idadi kubwa ya hifadhidata iweze kusimamiwa.
Ripoti hii haitajumuisha:
- “Vitone vya fedha” na taarifa kama vile - weka GB 8 au 25% zibufa_zaidizi na utakuwa sawa. Hakutakuwa na mengi kuhusu shared_buffers.
- Hardcore "ndani".
Nini kitatokea?
- Kutakuwa na kanuni za uboreshaji ambazo tutatumia na kukuza. Kutakuwa na kila aina ya mawazo ambayo yatatokea njiani na zana mbalimbali ambazo tunaunda kwa sehemu kubwa katika Chanzo Huria, i.e. tunatengeneza msingi katika Open Source. Kwa kuongezea, tunayo tikiti, mawasiliano yote ni Chanzo Huzi. Unaweza kuona tunachofanya sasa, nini kitakuwa katika toleo lijalo, nk.
- Pia kutakuwa na uzoefu katika kutumia kanuni hizi, zana hizi katika idadi ya makampuni: kutoka startups ndogo hadi makampuni makubwa.
Je, haya yote yanaendeleaje?
Kwanza, kazi kuu ya DBA, pamoja na kuhakikisha uundaji wa matukio, uwekaji wa chelezo, n.k., ni kupata vikwazo na kuboresha utendaji.
Sasa imewekwa hivi. Tunaangalia ufuatiliaji, tunaona kitu, lakini tunakosa maelezo fulani. Tunaanza kuchimba kwa uangalifu zaidi, kwa kawaida kwa mikono yetu, na kuelewa nini cha kufanya nayo kwa njia moja au nyingine.
Na kuna njia mbili. Pg_stat_statements ndio suluhisho chaguo-msingi la kubainisha hoja za polepole. Na uchambuzi wa magogo ya Postgres kwa kutumia pgBadger.
Kila mbinu ina mapungufu makubwa. Katika mbinu ya kwanza, tumetupa nje vigezo vyote. Na tukiona vikundi CHAGUA *KUTOKA jedwali ambapo safu wima ni sawa na "?" au "$" tangu Postgres 10. Hatujui ikiwa huu ni uchanganuzi wa faharasa au uchanganuzi wa seq. Inategemea sana parameter. Ukibadilisha thamani ambayo haipatikani sana hapo, itakuwa ni uchanganuzi wa faharasa. Ukibadilisha thamani ambayo inachukua 90% ya jedwali hapo, uchunguzi wa seq utakuwa dhahiri, kwa sababu Postgres anajua takwimu. Na hii ni shida kubwa ya pg_stat_statements, ingawa kazi fulani inaendelea.
Ubaya mkubwa wa uchanganuzi wa kumbukumbu ni kwamba huwezi kumudu "log_min_duration_statement = 0" kama sheria. Na tutazungumza juu ya hili pia. Ipasavyo, huoni picha nzima. Na swali fulani, ambalo ni la haraka sana, linaweza kutumia kiasi kikubwa cha rasilimali, lakini huwezi kuiona kwa sababu iko chini ya kizingiti chako.
Je, DBA hutatua vipi matatizo wanayopata?
Kwa mfano, tulipata shida fulani. Ni nini kawaida hufanyika? Ikiwa wewe ni msanidi programu, basi utakuwa ukifanya kitu kwa mfano fulani ambacho sio saizi sawa. Ikiwa wewe ni DBA, basi una maonyesho. Na kunaweza kuwa na moja tu. Na alikuwa nyuma kwa miezi sita. Na unafikiri kwamba utaenda kwenye uzalishaji. Na hata DBA zenye uzoefu basi angalia uzalishaji, kwenye nakala. Na hutokea kwamba huunda index ya muda, hakikisha kwamba inasaidia, kuacha na kuwapa watengenezaji ili waweze kuiweka kwenye faili za uhamiaji. Huu ndio aina ya upuuzi unaofanyika sasa. Na hili ni tatizo.
- Tune usanidi.
- Boresha seti ya faharasa.
- Badilisha swala la SQL yenyewe (hii ndiyo njia ngumu zaidi).
- Ongeza uwezo (njia rahisi katika hali nyingi).
Kuna mengi yanaendelea na mambo haya. Kuna vipini vingi katika Postgres. Kuna mengi ya kujua. Kuna faharasa nyingi katika Postgres, shukrani pia kwa waandaaji wa mkutano huu. Na haya yote yanahitaji kujulikana, na hii ndiyo inawafanya wasio DBA kuhisi kama DBA wanafanya uchawi. Hiyo ni, unahitaji kusoma kwa miaka 10 ili kuanza kuelewa haya yote kwa kawaida.
Na mimi ni mpiganaji dhidi ya uchawi huu mweusi. Ninataka kufanya kila kitu ili kuna teknolojia, na hakuna intuition katika haya yote.
Mifano halisi ya maisha
Niliona hii katika angalau miradi miwili, pamoja na yangu mwenyewe. Chapisho lingine la blogi linatuambia kuwa thamani ya 1 kwa default_statistict_target ni nzuri. Sawa, wacha tuijaribu katika uzalishaji.
Na hapa tuko, kwa kutumia zana yetu miaka miwili baadaye, kwa msaada wa majaribio kwenye hifadhidata ambayo tunazungumza juu ya leo, tunaweza kulinganisha kile kilichokuwa na kilichokuwa.
Na kwa hili tunahitaji kuunda jaribio. Inajumuisha sehemu nne.
- Ya kwanza ni mazingira. Tunahitaji kipande cha vifaa. Na nikifika kwa kampuni fulani na kusaini mkataba, nawaambia wanipe vifaa sawa na vya uzalishaji. Kwa kila Masters yako, ninahitaji angalau kipande kimoja cha maunzi kama hiki. Labda hii ni mfano wa mashine ya kawaida huko Amazon au Google, au ninahitaji kipande sawa cha vifaa. Hiyo ni, nataka kuunda upya mazingira. Na katika dhana ya mazingira tunajumuisha toleo kuu la Postgres.
- Sehemu ya pili ni mada ya utafiti wetu. Hii ni hifadhidata. Inaweza kuundwa kwa njia kadhaa. Nitakuonyesha jinsi gani.
- Sehemu ya tatu ni mzigo. Huu ndio wakati mgumu zaidi.
- Na sehemu ya nne ni kile tunachoangalia, yaani, tutalinganisha nini na nini. Wacha tuseme tunaweza kubadilisha kigezo kimoja au zaidi kwenye usanidi, au tunaweza kuunda faharisi, nk.
Tunazindua jaribio. Hapa kuna pg_stat_statements. Upande wa kushoto ndicho kilichotokea. Kwa upande wa kulia - nini kilitokea.
Upande wa kushoto default_statistics_target = 100, upande wa kulia =1 Tunaona kwamba hii ilitusaidia. Kwa ujumla, kila kitu kilikua bora kwa 000%.
Lakini tukisogeza chini, kutakuwa na vikundi vya maombi kutoka pgBadger au kutoka pg_stat_statements. Kuna chaguzi mbili. Tutaona kwamba ombi fulani limepungua kwa 88%. Na hapa inakuja mbinu ya uhandisi. Tunaweza kuchimba zaidi ndani kwa sababu tunashangaa kwa nini ilizama. Unahitaji kuelewa kilichotokea na takwimu. Kwa nini ndoo zaidi katika takwimu husababisha matokeo mabaya zaidi.
Au hatuwezi kuchimba, lakini fanya "ALTER TABLE ... ALTER COLUMN" na urudishe ndoo 100 kwenye takwimu za safu wima hii. Na kisha kwa jaribio lingine tunaweza kuhakikisha kuwa kiraka hiki kilisaidia. Wote. Hii ni mbinu ya uhandisi ambayo hutusaidia kuona picha kuu na kufanya maamuzi kulingana na data badala ya uvumbuzi.
Mifano michache kutoka maeneo mengine. Kumekuwa na vipimo vya CI katika majaribio kwa miaka mingi. Na hakuna mradi katika akili yake sawa ungeishi bila majaribio ya kiotomatiki.
Katika viwanda vingine: katika anga, katika sekta ya magari, tunapojaribu aerodynamics, pia tuna fursa ya kufanya majaribio. Hatutazindua kitu kutoka kwa mchoro moja kwa moja hadi angani, au hatutachukua gari kwenye wimbo mara moja. Kwa mfano, kuna handaki ya upepo.
Tunaweza kupata hitimisho kutoka kwa uchunguzi wa tasnia zingine.
Kwanza, tuna mazingira maalum. Iko karibu na uzalishaji, lakini sio karibu. Kipengele chake kuu ni kwamba inapaswa kuwa nafuu, kurudia na automatiska iwezekanavyo. Na lazima pia kuwe na zana maalum za kufanya uchambuzi wa kina.
Uwezekano mkubwa zaidi, tunapozindua ndege na kuruka, tuna nafasi ndogo ya kujifunza kila milimita ya uso wa mrengo kuliko tunavyo kwenye handaki ya upepo. Tuna zana zaidi za uchunguzi. Tunaweza kumudu kubeba vitu vizito zaidi ambavyo hatuwezi kumudu kuweka kwenye ndege angani. Sawa na Postgres. Tunaweza, wakati fulani, kuwezesha uwekaji kumbukumbu kamili wa hoja wakati wa majaribio. Na hatutaki kufanya hivi katika uzalishaji. Tunaweza hata kupanga kuwezesha hii kwa kutumia auto_explain.
Na kama nilivyosema, kiwango cha juu cha otomatiki inamaanisha tunabonyeza kitufe na kurudia. Hivi ndivyo inavyopaswa kuwa, ili kuwe na majaribio mengi, ili iwe kwenye mkondo.
Nancy CLI - msingi wa "maabara ya hifadhidata"
Na kwa hivyo tulifanya jambo hili. Hiyo ni, nilizungumza juu ya mawazo haya mnamo Juni, karibu mwaka mmoja uliopita. Na tayari tunayo kinachojulikana kama Nancy CLI kwenye Chanzo Huria. Huu ndio msingi wa kujenga maabara ya hifadhidata.
- Iko kwenye Chanzo Huria, kwenye Gitlab. Unaweza kusema, unaweza kujaribu. Nilitoa kiungo kwenye slaidi. Unaweza kubofya juu yake na itakuwa hapo katika mambo yote.
Bila shaka, kuna mengi bado chini ya maendeleo. Kuna mawazo mengi huko. Lakini hii ni kitu tunachotumia karibu kila siku. Na tunapokuwa na wazo - kwa nini tunapofuta mistari 40, yote inakuja kwa IO, basi tunaweza kufanya jaribio na kuangalia kwa undani zaidi kuelewa kinachotokea na kisha kujaribu kurekebisha kwa kuruka. Hiyo ni, tunafanya majaribio. Kwa mfano, tunabadilisha kitu na kuona kile kinachotokea mwishoni. Na hatufanyi hivi katika uzalishaji. Hiki ndicho kiini cha wazo.
Hii inaweza kufanya kazi wapi? Hii inaweza kufanya kazi ndani ya nchi, i.e. unaweza kuifanya mahali popote, unaweza kuiendesha kwenye MacBook. Tunahitaji docker, twende. Ni hayo tu. Unaweza kuiendesha kwa mfano kwenye kipande cha maunzi, au kwenye mashine pepe, popote.
Na pia kuna fursa ya kukimbia kwa mbali katika Amazon katika EC2 Instance, katika matangazo. Na hii ni fursa nzuri sana. Kwa mfano, jana tulifanya majaribio zaidi ya 500 kwenye mfano wa i3, tukianza na mdogo na kumalizia na i3-16-xlarge. Na majaribio 500 yaligharimu $64. Kila moja ilichukua dakika 15. Hiyo ni, kutokana na ukweli kwamba matangazo hutumiwa huko, ni nafuu sana - punguzo la 70%, malipo ya kila sekunde ya Amazon. Unaweza kufanya mengi. Unaweza kufanya utafiti wa kweli.
Na matoleo matatu makuu ya Postgres yanaungwa mkono. Sio ngumu sana kumaliza zingine za zamani na toleo jipya la 12 pia.
Tunaweza kufafanua kitu kwa njia tatu. Hii:
- Tupa/sql faili.
- Njia kuu ni kuiga saraka ya PGDATA. Kama sheria, inachukuliwa kutoka kwa seva ya chelezo. Ikiwa una chelezo za kawaida za binary, unaweza kutengeneza clones kutoka hapo. Ikiwa una mawingu, basi ofisi ya wingu kama Amazon na Google itakufanyia hili. Hii ndiyo njia muhimu zaidi ya kuunganisha uzalishaji halisi. Hivi ndivyo tunavyoeneza.
- Na njia ya mwisho inafaa kwa utafiti unapotaka kuelewa jinsi kitu kinavyofanya kazi katika Postgres. Hii ni pgbench. Unaweza kutengeneza kwa kutumia pgbench. Ni chaguo moja tu la "db-pgbench". Unamwambia ni kiwango gani. Na kila kitu kitatolewa katika wingu, kama ilivyoelezwa.
Na mzigo:
- Tunaweza kutekeleza mzigo kwenye uzi mmoja wa SQL. Hii ndiyo njia ya primitive zaidi.
- Na tunaweza kuiga mzigo. Na tunaweza kuiga kwanza kabisa kwa njia ifuatayo. Tunahitaji kukusanya magogo yote. Na ni chungu. Nitakuonyesha kwa nini. Na kwa kutumia pgreplay tunacheza, ambayo imejengwa ndani ya Nancy.
- Au chaguo jingine. Kinachojulikana mzigo wa hila, ambayo tunafanya kwa kiasi fulani cha jitihada. Kuchambua mzigo wetu wa sasa kwenye mfumo wa mapigano, tunatoa vikundi vya juu vya maombi. Na kwa kutumia pgbench tunaweza kuiga mzigo huu kwenye maabara.
- Labda lazima tutekeleze aina fulani ya SQL, yaani, tunaangalia aina fulani ya uhamiaji, kuunda faharisi hapo, kutekeleza ANALAZE hapo. Na tunaangalia kile kilichotokea kabla ya utupu na baada ya utupu. Kwa ujumla, SQL yoyote.
- Labda tunabadilisha kigezo kimoja au zaidi kwenye usanidi. Tunaweza kutuambia tuangalie, kwa mfano, thamani 100 katika Amazon kwa hifadhidata yetu ya terabyte. Na katika masaa machache utapata matokeo. Kama sheria, itakuchukua saa kadhaa kupeleka hifadhidata ya terabyte. Lakini kuna kiraka katika ukuzaji, tuna safu inayowezekana, i.e. unaweza kutumia pgdata sawa kwenye seva moja na uangalie. Postgres zitaanza upya na akiba zitawekwa upya. Na unaweza kuendesha mzigo.
- Saraka hufika na rundo la faili tofauti, kuanzia pg snapshotsstat***. Na jambo la kufurahisha zaidi ni pg_stat_statements, pg_stat_kcacke. Hivi ni viendelezi viwili vinavyochanganua maombi. Na pg_stat_bgwriter haina takwimu za mwandishi wa maandishi pekee, lakini pia kwenye sehemu ya ukaguzi na jinsi sehemu za nyuma zenyewe huondoa bafa chafu. Na yote yanavutia kuona. Kwa mfano, tunapoweka shared_buffers, inavutia sana kuona ni kiasi gani kila mtu alibadilisha.
- Kumbukumbu za postgres pia zinawasili. Kumbukumbu mbili - logi ya maandalizi na logi ya uchezaji wa mzigo.
- Kipengele kipya ni FlameGraphs.
- Pia, ikiwa ulitumia chaguzi za pgreplay au pgbench kwa kucheza mzigo, basi matokeo yao yatakuwa ya asili. Na utaona latency na TPS. Itawezekana kuelewa jinsi walivyoiona.
- Taarifa za mfumo.
- Hundi za msingi za CPU na IO. Hii ni zaidi kwa mfano wa EC2 huko Amazon, unapotaka kuzindua matukio 100 sawa katika thread na kuendesha mikimbio 100 tofauti hapo, basi utakuwa na majaribio 10. Na unahitaji kuhakikisha kuwa haupati mfano mbaya ambao tayari unakandamizwa na mtu. Wengine wanatumika kwenye kipande hiki cha maunzi na una rasilimali kidogo iliyosalia. Ni bora kukataa matokeo kama haya. Na kwa msaada wa sysbench kutoka Alexey Kopytov, tunafanya hundi fupi kadhaa ambazo zitakuja na zinaweza kulinganishwa na wengine, yaani, utaelewa jinsi CPU inavyofanya na jinsi IO inavyofanya.
Je, ni matatizo gani ya kiufundi kulingana na mfano wa makampuni mbalimbali?
Wacha tuseme tunataka kurudia mzigo halisi kwa kutumia magogo. Ni wazo nzuri ikiwa imeandikwa kwenye Open Source pgreplay. Tunaitumia. Lakini ili ifanye kazi vizuri, lazima uwezeshe ukataji kamili wa hoja na vigezo na wakati.
Kuna baadhi ya matatizo na muda na muhuri wa muda. Tutaondoa jikoni hii nzima. Swali kuu ni kama unaweza kumudu au la?
Tatizo ni kwamba inaweza kuwa haipatikani. Kwanza kabisa, lazima uelewe ni mkondo gani utaandikwa kwa logi. Ikiwa una pg_stat_statements, unaweza kutumia swali hili (kiungo kitapatikana kwenye slaidi) kuelewa takriban ni baiti ngapi zitaandikwa kwa sekunde.
Tunaangalia urefu wa ombi. Tunapuuza ukweli kwamba hakuna vigezo, lakini tunajua urefu wa ombi na tunajua ni mara ngapi kwa sekunde moja lilitekelezwa. Kwa njia hii tunaweza kukadiria takriban baiti ngapi kwa sekunde. Tunaweza kufanya makosa mara mbili zaidi, lakini hakika tutaelewa utaratibu kwa njia hii.
Tunaweza kuona kwamba mara 802 kwa sekunde ombi hili linatekelezwa. Na tunaona kwamba bytes_per sec - 300 kB/s itaandikwa plus au minus. Na, kama sheria, tunaweza kumudu mtiririko kama huo.
Lakini! Ukweli ni kwamba kuna mifumo tofauti ya ukataji miti. Na chaguo-msingi la watu kawaida ni "syslog".
Na ikiwa una syslog, basi unaweza kuwa na picha kama hii. Tutachukua pgbench, wezesha ukataji wa hoja na tuone kinachotokea.
Bila kuingia, hii ni safu wima upande wa kushoto. Tulipata TPS 161,000. Kwa syslog, hii iko ndani Ubuntu Mnamo Aprili 16, tunapata TPS 37,000 kwenye Amazon. Na tukibadilisha na kutumia mbinu zingine mbili za ukataji, hali itakuwa bora zaidi. Kwa hivyo, tulitarajia kushuka, lakini si sana.
Na kuendelea CentOS 7, ambayo pia hutumia daftari, kubadilisha kumbukumbu kuwa umbizo la binary kwa urahisi wa kutafuta, n.k., ni ndoto mbaya kabisa, ikiwa na kupungua kwa TPS mara 44.
Na hii ndio watu wanaishi nayo. Na mara nyingi katika makampuni, hasa makubwa, hii ni vigumu sana kubadili. Ikiwa unaweza kupata mbali na syslog, basi tafadhali ondoka kutoka kwayo.
- Tathmini IOPS na uandike mtiririko.
- Angalia mfumo wako wa ukataji miti.
- Ikiwa mzigo uliokadiriwa ni mkubwa kupita kiasi, fikiria kuchukua sampuli.
Tuna pg_stat_statements. Kama nilivyosema, lazima iwepo. Na tunaweza kuchukua na kuelezea kila kikundi cha maombi kwa njia maalum katika faili. Na kisha tunaweza kutumia kipengele rahisi sana katika pgbench - hii ni uwezo wa kuingiza faili kadhaa kwa kutumia chaguo "-f".
Inaelewa mengi ya "-f". Na unaweza kujua kwa usaidizi wa "@" mwishoni ni mgawo gani kila faili inapaswa kuwa nayo. Hiyo ni, tunaweza kusema kwamba kufanya hivyo katika 10% ya kesi, na hii katika 20%. Na hii itatuleta karibu na kile tunachokiona katika uzalishaji.
Je, tutaelewaje tulichonacho katika uzalishaji? Kushiriki nini na jinsi gani? Hii ni kando kidogo. Tuna bidhaa moja zaidi . Pia msingi katika Open Source. Na sasa tunaiendeleza kikamilifu.
Alizaliwa kwa sababu tofauti kidogo. Kwa sababu ambazo ufuatiliaji hautoshi. Yaani wewe njoo angalia msingi angalia matatizo yaliyopo. Na, kama sheria, unafanya ukaguzi wa afya. Ikiwa wewe ni DBA mwenye uzoefu, basi unafanya health_check. Tuliangalia matumizi ya indexes, nk Ikiwa una OKmeter, basi ni nzuri. Huu ni ufuatiliaji mzuri kwa Postgres. OKmeter.io - tafadhali isakinishe, kila kitu kinafanyika vizuri sana hapo. Imelipwa.
Ikiwa huna moja, basi kwa kawaida huna mengi. Katika ufuatiliaji, kuna kawaida CPU, IO, na kisha kwa kutoridhishwa, na hiyo ndiyo yote. Na tunahitaji zaidi. Tunahitaji kuona jinsi autovacuum inavyofanya kazi, jinsi kituo cha ukaguzi kinavyofanya kazi, katika io tunahitaji kutenganisha kituo cha ukaguzi kutoka kwa bgwriter na kutoka kwa nyuma, nk.
Shida ni kwamba unaposaidia kampuni kubwa, hawawezi kutekeleza kitu haraka. Hawawezi kununua OKmeter haraka. Labda watainunua baada ya miezi sita. Hawawezi kutoa vifurushi kwa haraka.
Na tulikuja na wazo kwamba tunahitaji zana maalum ambayo hauitaji chochote kusanikishwa, i.e. sio lazima usakinishe chochote kwenye uzalishaji. Isakinishe kwenye kompyuta yako ndogo, au kwenye seva ya kutazama kutoka mahali utakapoiendesha. Na itachambua mambo mengi: mfumo wa uendeshaji, mfumo wa faili, na Postgres yenyewe, ikifanya maswali mepesi ambayo yanaweza kuendeshwa moja kwa moja kwa uzalishaji na hakuna kitakachoshindwa.
Tuliiita Postgres-checkup. Kwa maneno ya matibabu, hii ni ukaguzi wa kawaida wa afya. Ikiwa ni mandhari ya magari, basi ni kama matengenezo. Unafanya matengenezo kwenye gari lako kila baada ya miezi sita au mwaka, kulingana na chapa. Je, unafanya matengenezo kwa msingi wako? Yaani unafanya utafiti wa kina mara kwa mara? Ni lazima ifanyike. Ikiwa unafanya chelezo, basi fanya ukaguzi, hii sio muhimu sana.
Na tunayo zana kama hiyo. Ilianza kujitokeza kikamilifu miezi mitatu iliyopita. Bado ni mchanga, lakini kuna mengi huko.
Kukusanya vikundi "vyenye ushawishi" zaidi vya maswali - ripoti K003 katika ukaguzi wa Postgres
Na kuna kundi la ripoti K. Tatu ripoti hadi sasa. Na kuna ripoti kama hiyo K003. Kuna sehemu ya juu kutoka pg_stat_statements, iliyopangwa kwa total_time.
Tunapopanga vikundi vya ombi kwa total_time, juu tunaona kikundi kinachopakia mfumo wetu zaidi, yaani, hutumia rasilimali zaidi. Kwa nini ninataja vikundi vya maswali? Kwa sababu tulitupa vigezo. Haya si maombi tena, bali makundi ya maombi, yaani yametolewa.
Na ikiwa tutaboresha kutoka juu hadi chini, tutapunguza rasilimali zetu na kuchelewesha wakati tunapohitaji kuboresha. Hii ni njia nzuri sana ya kuokoa pesa.
Labda hii sio njia nzuri sana ya kutunza watumiaji, kwa sababu hatuwezi kuona nadra, lakini kesi za kukasirisha sana ambapo mtu alisubiri sekunde 15. Kwa jumla, ni nadra sana kwamba hatuwaoni, lakini tunashughulika na rasilimali.
Ni nini kilitokea kwenye meza hii? Tulichukua snapshots mbili. Postgres_checkup itakupa delta kwa kila kipimo: jumla ya muda, simu, safu mlalo, pamoja_blks_kusoma, n.k. Hiyo ni, delta imehesabiwa. Shida kubwa na pg_stat_statements ni kwamba haikumbuki wakati iliwekwa upya. Ikiwa pg_stat_database inakumbuka, basi pg_stat_statements haikumbuki. Unaona kwamba kuna idadi ya 1, lakini hatujui tulihesabu kutoka wapi.
Na hapa tunajua, hapa tuna snapshots mbili. Tunajua kuwa delta katika kesi hii ilikuwa sekunde 56. Pengo fupi sana. Imepangwa kwa total_time. Na kisha tunaweza kutofautisha, yaani, tunagawanya vipimo vyote kwa muda. Ikiwa tutagawanya kila kipimo kwa muda, tutakuwa na nambari ya simu kwa sekunde.
Inayofuata, total_time kwa sekunde ndio kipimo ninachopenda. Inapimwa kwa sekunde, kwa sekunde, yaani ni sekunde ngapi ilichukua mfumo wetu kutekeleza kundi hili la maombi kwa sekunde. Ikiwa unaona zaidi ya sekunde kwa sekunde hapo, inamaanisha ulipaswa kutoa zaidi ya msingi mmoja. Hiki ni kipimo kizuri sana. Unaweza kuelewa kwamba rafiki huyu, kwa mfano, anahitaji angalau cores tatu.
Huu ni ujuzi wetu, sijawahi kuona kitu kama hicho popote. Tafadhali kumbuka - hii ni jambo rahisi sana - pili kwa pili. Wakati mwingine, wakati CPU yako ni 100%, kisha nusu saa kwa sekunde, yaani, ulitumia nusu saa kufanya maombi haya tu.
Ifuatayo tunaona safu kwa sekunde. Tunajua ni safu mlalo ngapi kwa sekunde ilirudi.
Na kisha kuna jambo la kuvutia pia. Ni vihifadhi_vingapi vilivyoshirikiwa tunasoma kwa sekunde kutoka kwa shared_buffers yenyewe. Vipigo vilikuwa tayari, na tulichukua safu kutoka kwa cache ya mfumo wa uendeshaji au kutoka kwa diski. Chaguo la kwanza ni la haraka, na la pili linaweza au la haraka, kulingana na hali hiyo.
Na njia ya pili ya utofautishaji ni kugawanya idadi ya maombi katika kundi hili. Katika safu wima ya pili kila wakati utakuwa na swali moja lililogawanywa kwa kila swali. Na kisha inafurahisha - ni milliseconds ngapi kwenye ombi hili. Tunajua jinsi swali hili linavyofanya kwa wastani. Milisekunde 101 zilihitajika kwa kila ombi. Hiki ndicho kipimo cha jadi tunachohitaji kuelewa.
Je, kila swali lilirejesha safu mlalo ngapi kwa wastani? Tunaona 8 kundi hili linarudi. Kwa wastani, ni kiasi gani kilichukuliwa kutoka kwa kache na kusoma. Tunaona kwamba kila kitu kimehifadhiwa vizuri. Vibao thabiti vya kundi la kwanza.
Na kifungu kidogo cha nne katika kila mstari ni asilimia ngapi ya jumla. Tuna simu. Wacha tuseme 1 Na tunaweza kuelewa ni mchango gani kikundi hiki kinatoa. Tunaona kwamba katika kesi hii kundi la kwanza linachangia chini ya 000%. Hiyo ni, ni polepole sana kwamba hatuioni katika picha ya jumla. Na kundi la pili ni 000% kwenye simu. Hiyo ni, 0,01% ya simu zote ni kundi la pili.
Total_time pia inavutia. Tulitumia 14% ya jumla ya muda wetu wa kazi kwenye kundi la kwanza la maombi. Na kwa pili - 11%, nk.
Sitaingia kwa undani, lakini kuna hila hapo. Tunaonyesha hitilafu hapo juu, kwa sababu tunapolinganisha, snapshots zinaweza kuelea, yaani, baadhi ya maombi yanaweza kuanguka na hayawezi kuwepo katika pili, wakati baadhi mapya yanaweza kuonekana. Na hapo tunahesabu kosa. Ikiwa unaona 0, basi hiyo ni nzuri. Hakuna makosa. Ikiwa kiwango cha makosa ni hadi 20%, ni sawa.
Kisha tunarudi kwenye mada yetu. Tunahitaji kutengeneza mzigo wa kazi. Tunachukua kutoka juu hadi chini na kwenda mpaka kufikia 80% au 90%. Kawaida hii ni vikundi 10-20. Na tunatengeneza faili za pgbench. Tunatumia nasibu hapo. Wakati mwingine hii, kwa bahati mbaya, haifanyi kazi. Na katika Postgres 12 kutakuwa na fursa zaidi za kutumia mbinu hii.
Na kisha tunapata 80-90% kwa jumla_muda kwa njia hii. Je, niweke nini baada ya "@"? Tunaangalia simu, angalia ni riba ngapi na tunaelewa kuwa tunadaiwa riba nyingi hapa. Kutoka kwa asilimia hizi tunaweza kuelewa jinsi ya kusawazisha kila faili. Baada ya hapo tunatumia pgbench na kwenda kufanya kazi.
Pia tuna K001 na K002.
K001 ni uzi mmoja mkubwa wenye nyuzi ndogo nne. Hii ni tabia ya mzigo wetu wote. Tazama safu wima ya pili na safu ndogo ya pili. Tunaona kwamba karibu sekunde moja na nusu kwa pili, yaani ikiwa kuna cores mbili, basi itakuwa nzuri. Kutakuwa na uwezo wa takriban 75%. Na itafanya kazi kama hii. Ikiwa tuna cores 10, basi kwa ujumla tutakuwa na utulivu. Kwa njia hii tunaweza kutathmini rasilimali.
K002 ndio ninaita query classes, yaani CHAGUA, INGIZA, SASISHA, FUTA. Na kando CHAGUA KWA USASISHAJI, kwa sababu ni kufuli.
Na hapa tunaweza kuhitimisha kuwa SELECT ni wasomaji wa kawaida - 82% ya simu zote, lakini wakati huo huo - 74% kwa jumla_time. Hiyo ni, wanaitwa mengi, lakini hutumia rasilimali kidogo.
Na tunarudi kwa swali: "Tunawezaje kuchagua vibafa_sahihi vilivyoshirikiwa?" Ninaona kuwa alama nyingi zinatokana na wazo - wacha tuone matokeo yatakuwaje, i.e. matokeo yatakuwaje. Kawaida hupimwa katika TPS au QPS.
Na tunajaribu kufinya shughuli nyingi kwa sekunde iwezekanavyo kutoka kwa gari kwa kutumia vigezo vya kurekebisha. Hapa kuna 311 haswa kwa sekunde kwa chaguo.
Lakini hakuna mtu anayeendesha gari kwenda kazini na kurudi nyumbani kwa kasi kamili. Huu ni ujinga. Sawa na hifadhidata. Hatuhitaji kuendesha gari kwa mwendo wa kasi, na hakuna anayefanya hivyo. Hakuna mtu anayeishi katika uzalishaji, ambao una 100% CPU. Ingawa, labda mtu anaishi, lakini hii sio nzuri.
Wazo ni kwamba kwa kawaida tunaendesha kwa asilimia 20 ya uwezo, ikiwezekana si zaidi ya 50%. Na tunajaribu kuboresha muda wa kujibu kwa watumiaji wetu zaidi ya yote. Hiyo ni, lazima tugeuze visu vyetu ili kuwe na latency ya chini kwa kasi ya 20%, kwa masharti. Hili ni wazo ambalo tunajaribu pia kutumia katika majaribio yetu.
Na hatimaye, mapendekezo:
- Hakikisha kufanya Database Lab.
- Ikiwezekana, fanya kwa mahitaji ili iweze kufunua kwa muda - cheza na uitupe mbali. Ikiwa una mawingu, basi hii huenda bila kusema, yaani kuwa na mengi ya kusimama.
- Kuwa na hamu ya kutaka kujua. Na ikiwa kuna kitu kibaya, basi angalia na majaribio jinsi inavyofanya. Nancy anaweza kutumika kujizoeza kuangalia jinsi msingi unavyofanya kazi.
- Na lenga muda wa chini zaidi wa kujibu.
- Na usiogope vyanzo vya Postgres. Unapofanya kazi na vyanzo, lazima ujue Kiingereza. Kuna maoni mengi huko, kila kitu kinaelezewa hapo.
- Na angalia afya ya hifadhidata mara kwa mara, angalau mara moja kila baada ya miezi mitatu, kwa mikono, au ukaguzi wa Postgres.
maswali
Asante sana! Jambo la kuvutia sana.
Vipande viwili.
Ndio, vipande viwili. Ni mimi tu sikuelewa kabisa. Wakati mimi na Nancy tunafanya kazi, tunaweza kubadilisha kigezo kimoja tu au kikundi kizima?
Tunayo parameta ya usanidi wa delta. Unaweza kugeukia huko kadri unavyotaka mara moja. Lakini unahitaji kuelewa kwamba unapobadilisha mambo mengi, unaweza kupata hitimisho sahihi.
Ndiyo. Kwa nini niliuliza? Kwa sababu ni vigumu kufanya majaribio ukiwa na kigezo kimoja tu. Wewe kaza, angalia jinsi inavyofanya kazi. Nikamtoa nje. Kisha unaanza ijayo.
Unaweza kuimarisha wakati huo huo, lakini inategemea hali, bila shaka. Lakini ni bora kujaribu wazo moja. Tulikuwa na wazo jana. Tulikuwa na hali ya karibu sana. Kulikuwa na mipangilio miwili. Na hatukuweza kuelewa kwa nini kulikuwa na tofauti kubwa. Na wazo likaibuka kwamba unahitaji kutumia dichotomy ili kuelewa kila wakati na kupata tofauti ni nini. Unaweza mara moja kufanya nusu ya vigezo sawa, kisha robo, nk Kila kitu ni rahisi.
Na kuna swali moja zaidi. Mradi huo ni mchanga na unaendelea. Nyaraka ziko tayari, kuna maelezo ya kina?
Nilitengeneza kiunga hapo kwa maelezo ya vigezo. Iko pale. Lakini mambo mengi bado hayajafika. Natafuta watu wenye nia moja. Na mimi huwapata ninapoigiza. Hii ni poa sana. Mtu tayari anafanya kazi na mimi, mtu alisaidia na kufanya kitu huko. Na ikiwa una nia ya mada hii, toa maoni juu ya kile kinachokosekana.
Mara tu tunapojenga maabara, labda kutakuwa na maoni. Hebu tuone. Asante!
Habari! Asante kwa ripoti! Niliona kwamba kuna msaada wa Amazon. Je, kuna mipango yoyote ya kusaidia GSP?
Swali zuri. Tulianza kuifanya. Na tuliizuia kwa sasa kwa sababu tunataka kuokoa pesa. Hiyo ni, kuna msaada wa kutumia run kwenye localhost. Unaweza kuunda mfano mwenyewe na kufanya kazi ndani ya nchi. Kwa njia, ndivyo tunavyofanya. Ninafanya hivi huko Getlab, huko GSP. Lakini bado hatuoni umuhimu wa kufanya okestra kama hiyo, kwa sababu Google haina maeneo ya bei nafuu. Kuna ??? matukio, lakini yana mapungufu. Kwanza, huwa na punguzo la 70% tu na huwezi kucheza na bei hapo. Kwenye matangazo, tunaongeza bei kwa 5-10% ili kupunguza uwezekano kwamba utapigwa teke. Hiyo ni, unahifadhi matangazo, lakini yanaweza kuchukuliwa kutoka kwako wakati wowote. Ukitoa zabuni ya juu kidogo kuliko wengine, utauawa baadaye. Google ina sifa tofauti kabisa. Na kuna kizuizi kingine kibaya sana - wanaishi kwa masaa 24 tu. Na wakati mwingine tunataka kufanya jaribio kwa siku 5. Lakini unaweza kufanya hivyo katika matangazo wakati mwingine hudumu kwa miezi.
Habari! Asante kwa ripoti! Umetaja ukaguzi. Je, unahesabu vipi hitilafu za taarifa_takwimu?
Swali zuri sana. Ninaweza kukuonyesha na kukuambia kwa undani sana. Kwa kifupi, tunaangalia jinsi seti ya vikundi vya ombi imeelea: ni ngapi zimeanguka na ni ngapi mpya zimeonekana. Na kisha tunaangalia vipimo viwili: jumla_saa na simu, kwa hivyo kuna makosa mawili. Na tunaangalia mchango wa vikundi vinavyoelea. Kuna vikundi viwili: walioondoka na waliofika. Wacha tuone mchango wao ni nini kwa picha ya jumla.
Huogopi kwamba itageuka huko mara mbili au tatu wakati kati ya snapshots?
Yaani walijiandikisha tena au vipi?
Kwa mfano, ombi hili tayari limetanguliwa mara moja, kisha likaja na lilitanguliwa tena, kisha likaja tena na lilitanguliwa tena. Na umehesabu kitu hapa, na yote iko wapi?
Swali zuri, itabidi tuangalie.
Nilifanya jambo kama hilo. Ilikuwa rahisi zaidi, bila shaka, nilifanya peke yangu. Lakini ilinibidi kuweka upya, kuweka upya stat_statements na kubaini wakati wa kupiga picha kwamba kulikuwa na chini ya sehemu fulani, ambayo bado haikufikia upeo wa ni kiasi gani cha taarifa_takwimu kingeweza kukusanyika hapo. Na ufahamu wangu ni kwamba, uwezekano mkubwa, hakuna kitu kilichohamishwa.
Ndiyo ndiyo.
Lakini sielewi jinsi nyingine ya kuifanya kwa uaminifu.
Kwa bahati mbaya, sikumbuki haswa ikiwa tunatumia maandishi ya hoja hapo au queryid na pg_stat_statements na kuangazia. Ikiwa tunazingatia queryid, basi kwa nadharia tunalinganisha vitu vinavyolinganishwa.
Hapana, anaweza kulazimishwa kutoka mara kadhaa kati ya snapshots na kuja tena.
Na kitambulisho sawa?
Ndiyo.
Tutajifunza hili. Swali zuri. Tunahitaji kuisoma. Lakini kwa sasa, tunachokiona ama kimeandikwa 0...
Kwa kweli, hii ni kesi adimu, lakini nilishtuka nilipogundua kuwa stat_statemetns inaweza kuhama hapo.
Kunaweza kuwa na mambo mengi katika Pg_stat_statements. Tuligundua ukweli kwamba ikiwa una track_utility = on, basi seti zako pia zinafuatiliwa.
Ndio kweli.
Na ikiwa una hibernate ya java, ambayo ni ya nasibu, basi meza ya hashi huanza kupatikana hapo. Na mara tu unapozima programu iliyopakiwa sana, unaishia na vikundi 50-100. Na kila kitu ni zaidi au chini ya utulivu huko. Njia moja ya kukabiliana na hali hii ni kuongeza pg_stat_statements.max.
Ndio, lakini unahitaji kujua ni kiasi gani. Na kwa namna fulani tunahitaji kuendelea kumtazama. Ndivyo ninavyofanya. Hiyo ni, nina pg_stat_statements.max. Na ninaona kwamba wakati wa snapshot nilikuwa sijafikia 70%. Sawa, kwa hivyo hatujapoteza chochote. Hebu tuweke upya. Na tunaokoa tena. Ikiwa snapshot inayofuata ni chini ya 70, basi uwezekano mkubwa haujapoteza chochote tena.
Ndiyo. Chaguo-msingi sasa ni 5 na hii inatosha kwa watu wengi.
Kwa kawaida ndiyo.
Video:
PS Kwa niaba yangu mwenyewe, nitaongeza kwamba ikiwa Postgres ina data ya siri na haiwezi kujumuishwa katika mazingira ya majaribio, basi unaweza kutumia . Mpango huo ni takriban kama ifuatavyo:
Chanzo: mapenzi.com
