Kurekebisha Linux ili kuboresha utendaji wa PostgreSQL. Ilya Kosmodemyansky

Nakala ya ripoti ya 2015 na Ilya Kosmodemyansky "Linux tuning kuboresha utendaji wa PostgreSQL"

Kanusho: Ninatambua kuwa ripoti hii ni ya tarehe 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 ya PostgreSQL yametolewa, na matoleo 15 ya kernel ya Linux yametolewa. Ukiandika upya vifungu hivi, utaishia na ripoti tofauti. Lakini hapa tunazingatia urekebishaji wa msingi wa Linux kwa PostgreSQL, ambayo bado inafaa leo.

Jina langu ni Ilya Kosmodemyansky. Ninafanya kazi PostgreSQL-Consulting. Na sasa nitazungumza kidogo juu ya nini cha kufanya na Linux kuhusiana na hifadhidata kwa ujumla na PostgreSQL haswa, kwa sababu kanuni zinafanana kabisa.

Tutazungumza nini? Ikiwa unawasiliana na PostgreSQL, basi kwa kiasi fulani unahitaji kuwa msimamizi wa UNIX. Ina maana gani? Ikiwa tunalinganisha Oracle na PostgreSQL, basi katika Oracle unahitaji kuwa msimamizi wa hifadhidata wa DBA 80% na msimamizi wa Linux 20%.

Na PostgreSQL ni ngumu zaidi. Ukiwa na PostgreSQL unahitaji kuwa na ufahamu bora zaidi wa jinsi Linux inavyofanya kazi. Na wakati huo huo, kukimbia kidogo baada ya locomotive, kwa sababu hivi karibuni kila kitu kimesasishwa vizuri kabisa. Na kernels mpya hutolewa, na utendaji mpya unaonekana, utendaji unaboresha, nk.

Kwa nini tunazungumza juu ya Linux? Sio kwa sababu tuko kwenye mkutano wa Linux Peter, lakini kwa sababu katika hali ya kisasa moja ya mifumo ya uendeshaji iliyo na haki zaidi ya kutumia hifadhidata kwa ujumla na PostgreSQL haswa ni Linux. Kwa sababu FreeBSD, kwa bahati mbaya, inakua katika mwelekeo wa kushangaza sana. Na kutakuwa na shida na utendaji na vitu vingine vingi. Utendaji wa PostgreSQL kwenye Windows kwa ujumla ni suala kubwa tofauti, kwa kuzingatia ukweli kwamba Windows haina kumbukumbu sawa na UNIX, wakati PostgreSQL yote inahusishwa na hii, kwa sababu ni mfumo wa michakato mingi.

Na nadhani kila mtu havutiwi sana na wahamiaji kama Solaris, kwa hivyo twende.

Usambazaji wa kisasa wa Linux una zaidi ya chaguzi 1 za syctl, kulingana na jinsi unavyounda kernel. Wakati huo huo, ikiwa tunatazama karanga tofauti, tunaweza kurekebisha kitu kwa njia nyingi. Kuna vigezo vya mfumo wa faili juu ya jinsi ya kuziweka. Ikiwa una maswali kuhusu jinsi ya kuianza: nini cha kuwezesha katika BIOS, jinsi ya kusanidi vifaa, nk.

Hii ni kiasi kikubwa sana ambacho kinaweza kujadiliwa kwa siku kadhaa, na si katika ripoti moja fupi, lakini sasa nitazingatia mambo muhimu, jinsi ya kuepuka reki hizo ambazo zimehakikishiwa kukuzuia kutumia database yako vizuri kwenye Linux ikiwa usiwarekebishe. Na wakati huo huo, jambo muhimu ni kwamba vigezo vingi vya default havijumuishwa katika mipangilio ambayo ni sahihi kwa hifadhidata. Hiyo ni, kwa chaguo-msingi itafanya kazi vibaya au haifanyi kazi kabisa.

Ni malengo gani ya kitamaduni ya kurekebisha yaliyopo kwenye Linux? Nadhani kwa kuwa nyote mnashughulika na usimamizi wa Linux, hakuna haja maalum ya kuelezea malengo ni nini.

Unaweza kuimba:

• CPU.
• Kumbukumbu.
• Hifadhi.
• Nyingine. Tutazungumza juu ya hili mwishoni kwa vitafunio. Hata, kwa mfano, vigezo kama vile sera ya kuokoa nishati vinaweza kuathiri utendakazi kwa njia isiyotabirika sana na si ya kupendeza zaidi.

Ni nini maalum za PostgreSQL na hifadhidata kwa ujumla? Shida ni kwamba huwezi kubadilisha nati yoyote ya kibinafsi na kuona kuwa utendakazi wetu umeboreshwa sana.

Ndio, kuna vifaa kama hivyo, lakini hifadhidata ni jambo ngumu. Inaingiliana na rasilimali zote ambazo seva ina na inapendelea kuingiliana kwa ukamilifu. Ukiangalia mapendekezo ya sasa ya Oracle kuhusu jinsi ya kutumia OS mwenyeji, itakuwa kama utani kuhusu mwanaanga huyo wa Kimongolia - lisha mbwa na usiguse chochote. Wacha tupe hifadhidata rasilimali zote, hifadhidata yenyewe itatatua kila kitu.

Kimsingi, kwa kiasi fulani hali ni sawa na PostgreSQL. Tofauti ni kwamba hifadhidata bado haiwezi kuchukua rasilimali zote yenyewe, i.e. mahali fulani kwenye kiwango cha Linux unahitaji kuzitatua mwenyewe.

Wazo kuu sio kuchagua lengo moja na kuanza kuibadilisha, kwa mfano, kumbukumbu, CPU au kitu kama hicho, lakini kuchambua mzigo wa kazi na kujaribu kuboresha upitishaji iwezekanavyo ili mzigo ambao watengenezaji wa programu wazuri waliuunda. kwa ajili yetu, ikiwa ni pamoja na watumiaji wetu.

Hapa kuna picha kuelezea ni nini. Kuna bafa ya Mfumo wa Uendeshaji wa Linux na kuna kumbukumbu iliyoshirikiwa na kuna vibafa vya pamoja vya PostgreSQL. PostgreSQL, tofauti na Oracle, inafanya kazi moja kwa moja tu kupitia buffer ya kernel, yaani, ili ukurasa kutoka kwa diski uingie kwenye kumbukumbu yake iliyoshirikiwa, lazima ipite kupitia buffer ya kernel na nyuma, hali sawa.

Diski huishi chini ya mfumo huu. Nilichora hii kama diski. Kwa kweli, kunaweza kuwa na mtawala wa RAID, nk.

Na hii pembejeo-pato kwa njia moja au nyingine hutokea kwa suala hili.

PostgreSQL ni hifadhidata ya kawaida. Kuna ukurasa ndani. Na pembejeo zote na matokeo hutokea kwa kutumia kurasa. Tunaongeza vizuizi kwenye kumbukumbu na kurasa. Na ikiwa hakuna kilichotokea, tunawasoma tu, basi hatua kwa hatua hupotea kutoka kwenye kashe hii, kutoka kwa buffers zilizoshirikiwa na kuishia nyuma kwenye diski.

Ikiwa tutabadilisha kitu mahali fulani, basi ukurasa wote unawekwa alama kuwa chafu. Niliziweka alama hapa kwa samawati. Na hii ina maana kwamba ukurasa huu lazima kulandanishwa na hifadhi ya kuzuia. Hiyo ni, tulipoifanya kuwa chafu, tuliingiza WAL. Na kwa wakati fulani mzuri sana, jambo linaloitwa kituo cha ukaguzi lilikuja. Na habari ziliandikwa kwenye logi hii kwamba alikuwa amefika. Na hii inamaanisha kwamba kurasa zote chafu zilizokuwa hapa wakati huo katika vihifadhi hivi vilivyoshirikiwa zililandanishwa na diski ya uhifadhi kwa kutumia fsync kupitia bafa ya kernel.

Kwa nini hili linafanywa? Ikiwa tulipoteza voltage, basi hatukupata hali ambayo data zote zilipotea. Kumbukumbu inayoendelea, ambayo kila mtu alituambia, hadi sasa iko katika nadharia ya hifadhidata - hii ni mustakabali mzuri, ambao sisi, kwa kweli, tunajitahidi na tunapenda, lakini kwa sasa wanaishi kwa miaka 20. Na, bila shaka, yote haya yanahitaji kufuatiliwa.

Na kazi ya kuongeza upitishaji ni kusawazisha vizuri katika hatua hizi zote ili zote zirudi na kurudi haraka. Kumbukumbu iliyoshirikiwa kimsingi ni akiba ya ukurasa. Katika PostgreSQL tulituma hoja iliyochaguliwa au kitu, ilipata data hii kutoka kwa diski. Waliishia kwenye vihifadhi vilivyoshirikiwa. Ipasavyo, ili hii ifanye kazi vizuri, lazima kuwe na kumbukumbu nyingi.

Ili yote haya yafanye kazi vizuri na kwa haraka, unahitaji kusanidi kwa usahihi mfumo wa uendeshaji katika hatua zote. Na kuchagua vifaa vya usawa, kwa sababu ikiwa una usawa mahali fulani, basi unaweza kufanya kumbukumbu nyingi, lakini haitatumiwa kwa kasi ya kutosha.

Na wacha tupitie kila moja ya vidokezo hivi.

Ili kufanya kurasa hizi zisafiri kwenda na kurudi kwa haraka, unahitaji kufikia yafuatayo:

• Kwanza, unahitaji kufanya kazi kwa ufanisi zaidi na kumbukumbu.
• Pili, mpito huu wakati kurasa kutoka kwa kumbukumbu kwenda kwa diski inapaswa kuwa bora zaidi.
• Na tatu, kuna lazima iwe na disks nzuri.

Ikiwa una 512 GB ya RAM kwenye seva na yote huisha kwenye gari la ngumu la SATA bila cache yoyote, basi seva nzima ya database inageuka kuwa sio tu malenge, lakini malenge yenye interface ya SATA. Utaingia ndani yake moja kwa moja. Na hakuna kitakachokuokoa.

Kuhusu jambo la kwanza lenye kumbukumbu, kuna mambo matatu ambayo yanaweza kufanya maisha kuwa magumu sana.

Wa kwanza wao ni NUMA. NUMA ni jambo ambalo linafanywa ili kuboresha utendaji. Kulingana na mzigo wa kazi, vitu tofauti vinaweza kuboreshwa. Na katika umbo lake jipya la sasa, si nzuri sana kwa programu kama vile hifadhidata ambazo hutumia kwa bidii akiba za ukurasa zilizoshirikiwa.

Kwa kifupi. Unawezaje kujua kama kuna kitu kibaya na NUMA? Una aina fulani ya kubisha hodi, ghafla CPU fulani imejaa. Wakati huo huo, unachambua maswali katika PostgreSQL na kuona kuwa hakuna kitu sawa hapo. Maswali haya hayapaswi kuwa ya kina CPU. Unaweza kupata hii kwa muda mrefu. Ni rahisi kutumia pendekezo sahihi tangu mwanzo juu ya jinsi ya kusanidi NUMA kwa PostgreSQL.

Nini kinaendelea kweli? NUMA inawakilisha Ufikiaji wa Kumbukumbu Usio wa Uniform. Kuna maana gani? Una CPU, karibu nayo kuna kumbukumbu yake ya ndani. Na miunganisho hii ya kumbukumbu inaweza kuvuta kumbukumbu kutoka kwa CPU zingine.

Ukikimbia numactl --hardware, basi utapata karatasi kubwa kama hiyo. Miongoni mwa mambo mengine, kutakuwa na uwanja wa umbali. Kutakuwa na nambari - 10-20, kitu kama hicho. Nambari hizi sio zaidi ya idadi ya humle kuchukua kumbukumbu hii ya mbali na kuitumia ndani ya nchi. Kimsingi, wazo nzuri. Hii inaharakisha utendaji kazi vizuri chini ya anuwai ya mzigo wa kazi.

Sasa fikiria kuwa una CPU moja inajaribu kwanza kutumia kumbukumbu yake ya ndani, kisha kujaribu kuvuta kumbukumbu nyingine kupitia unganisho la kitu fulani. Na CPU hii inapata kashe yako yote ya ukurasa wa PostgreSQL - ndivyo hivyo, gigabytes kadhaa. Unapata hali mbaya zaidi kila wakati, kwa sababu kwenye CPU kawaida kuna kumbukumbu kidogo kwenye moduli yenyewe. Na kumbukumbu zote zinazohudumiwa hupitia viunganishi hivi. Inageuka polepole na huzuni. Na kichakataji chako kinachotoa huduma nodi hii imejaa kila mara. Na wakati wa kufikia kumbukumbu hii ni mbaya, polepole. Hii ndio hali ambayo hutaki ikiwa unatumia hii kwa hifadhidata.

Kwa hivyo, chaguo sahihi zaidi kwa hifadhidata ni kwa mfumo wa uendeshaji wa Linux kutojua kinachoendelea huko kabisa. Ili kufikia kumbukumbu kama inavyofanya.

Kwanini hivyo? Inaweza kuonekana kuwa inapaswa kuwa kwa njia nyingine kote. Hii hutokea kwa sababu moja rahisi: tunahitaji kumbukumbu nyingi kwa cache ya ukurasa - makumi, mamia ya gigabytes.

Na ikiwa tutatenga haya yote na kuweka data yetu hapo, basi faida kutoka kwa kache itakuwa kubwa zaidi kuliko faida kutoka kwa ufikiaji wa kumbukumbu kama huo. Na kwa hivyo tutafaidika bila kulinganishwa na ukweli kwamba tutapata kumbukumbu kwa ufanisi zaidi kwa kutumia NUMA.

Kwa hivyo, kuna njia mbili hapa kwa sasa, hadi wakati ujao mkali umefika, na hifadhidata yenyewe haiwezi kujua ni CPU zipi inaendesha na wapi inahitaji kuvuta kitu kutoka.

Kwa hivyo, mbinu sahihi ni kulemaza NUMA kabisa, kwa mfano, wakati wa kuanzisha upya. Katika hali nyingi, ushindi ni wa maagizo ya ukubwa kwamba swali la ambayo ni bora haitokei kabisa.

Kuna chaguo jingine. Tunaitumia mara nyingi zaidi kuliko ile ya kwanza, kwa sababu mteja anapokuja kwetu kwa usaidizi, kuanzisha upya seva ni jambo kubwa kwake. Ana biashara huko. Na wanapata matatizo kwa sababu ya NUMA. Kwa hivyo, tunajaribu kuizima kwa njia zisizo na uvamizi zaidi kuliko kuwasha upya, lakini kuwa mwangalifu kuangalia ikiwa imezimwa. Kwa sababu, kama uzoefu unavyoonyesha, ni vyema tukazima NUMA kwenye mchakato wa mzazi wa PostgreSQL, lakini si lazima hata kidogo kwamba itafanya kazi. Tunahitaji kuangalia na kuona kwamba yeye kweli switched off.

Kuna chapisho zuri la Robert Haas. Hii ni mojawapo ya watoa huduma za PostgreSQL. Mmoja wa watengenezaji muhimu wa giblets zote za kiwango cha chini. Na ukifuata viungo kutoka kwa chapisho hili, vinaelezea hadithi kadhaa za kupendeza kuhusu jinsi NUMA ilifanya maisha kuwa magumu kwa watu. Angalia, soma orodha ya ukaguzi ya msimamizi wa mfumo wa kile kinachohitaji kusanidiwa kwenye seva ili hifadhidata yetu ifanye kazi vizuri. Mipangilio hii inahitaji kuandikwa na kuangaliwa, kwa sababu vinginevyo haitakuwa nzuri sana.

Tafadhali kumbuka kuwa hii inatumika kwa mipangilio yote ambayo nitazungumzia. Lakini kwa kawaida hifadhidata hukusanywa katika hali ya bwana-mtumwa kwa uvumilivu wa makosa. Usisahau kuweka mipangilio hii kwa mtumwa maana siku moja utapata ajali na utabadilisha mtumwa na kuwa bwana.

Katika hali ya dharura, wakati kila kitu ni mbaya sana, simu yako inapiga mara kwa mara na bosi wako anakuja mbio na fimbo kubwa, hutakuwa na muda wa kufikiri juu ya kuangalia. Na matokeo yanaweza kuwa mbaya sana.

Hatua inayofuata ni kurasa kubwa. Kurasa kubwa ni ngumu kujaribu kando, na hakuna maana katika kufanya hivyo, ingawa kuna alama ambazo zinaweza kufanya hivi. Ni rahisi kwa Google.

Kuna maana gani? Una seva isiyo ya gharama kubwa sana na RAM nyingi, kwa mfano, zaidi ya 30 GB. Hutumii kurasa kubwa. Hii ina maana kwamba hakika una ziada katika suala la matumizi ya kumbukumbu. Na hii ya juu ni mbali na ya kupendeza zaidi.

Kwanini hivyo? Kwa hiyo nini kinaendelea? Mfumo wa uendeshaji hutenga kumbukumbu katika vipande vidogo. Ni rahisi sana, ndivyo ilivyotokea kihistoria. Na ikiwa tunaingia kwa undani, OS lazima itafsiri anwani za kawaida katika za kimwili. Na mchakato huu sio rahisi zaidi, kwa hivyo OS huhifadhi matokeo ya operesheni hii kwenye Kipengele cha Kuangalia Kando ya Tafsiri (TLB).

Na kwa kuwa TLB ni kache, shida zote zilizo katika kache huibuka katika hali hii. Kwanza, ikiwa una RAM nyingi na zote zimetengwa kwa vipande vidogo, basi bafa hii inakuwa kubwa sana. Na ikiwa kashe ni kubwa, basi kutafuta kupitia hiyo ni polepole. Rudia ni nzuri na yenyewe inachukua nafasi, yaani RAM inatumiwa na kitu kisicho sahihi. Wakati huu.

Mbili - zaidi cache inakua katika hali hiyo, kuna uwezekano mkubwa zaidi kwamba utakuwa na misses ya cache. Na ufanisi wa kache hii hupungua kwa kasi kadiri ukubwa wake unavyoongezeka. Kwa hiyo, mifumo ya uendeshaji ilikuja na mbinu rahisi. Imetumika katika Linux kwa muda mrefu. Ilionekana katika FreeBSD si muda mrefu uliopita. Lakini tunazungumza juu ya Linux. Hizi ni kurasa kubwa.

Na hapa ikumbukwe kwamba kurasa kubwa, kama wazo, zilisukumwa hapo awali na jumuiya zilizojumuisha Oracle na IBM, yaani, watengenezaji wa hifadhidata walifikiri sana kuwa hii inaweza kuwa muhimu kwa hifadhidata pia.

Na hii inawezaje kufanywa urafiki na PostgreSQL? Kwanza, kurasa kubwa lazima ziwashwe kwenye kinu cha Linux.

Pili, lazima zibainishwe wazi na parameta ya sysctl - ni ngapi. Nambari hapa ni kutoka kwa seva ya zamani. Unaweza kukokotoa ngapi za akiba zilizoshirikiwa ulizo nazo ili kurasa kubwa ziweze kutoshea hapo.

Na ikiwa seva yako yote imejitolea kwa PostgreSQL, basi mahali pazuri pa kuanzia ni kutenga ama 25% ya RAM kwa vihifadhi vilivyoshirikiwa, au 75% ikiwa una uhakika kuwa hifadhidata yako itatoshea katika hii 75%. Hatua ya kuanzia. Na fikiria, ikiwa una 256 GB ya RAM, basi, ipasavyo, utakuwa na 64 GB ya buffers kubwa. Hesabu takriban na ukingo fulani - takwimu hii inapaswa kuwekwa nini.

Kabla ya toleo la 9.2 (ikiwa sijakosea, tangu toleo la 8.2), iliwezekana kuunganisha PostgreSQL na kurasa kubwa kwa kutumia maktaba ya wahusika wengine. Na hii inapaswa kufanywa kila wakati. Kwanza, unahitaji kernel kuweza kutenga kurasa kubwa kwa usahihi. Na, pili, ili programu inayofanya kazi nao iweze kuzitumia. Haitatumika tu kwa njia hiyo. Kwa kuwa PostgreSQL imetenga kumbukumbu katika mfumo wa 5, hii inaweza kufanywa kwa kutumia libhugetlbfs - hili ndilo jina kamili la maktaba.

Mnamo 9.3, utendaji wa PostgreSQL uliboreshwa wakati wa kufanya kazi na kumbukumbu na njia ya ugawaji wa kumbukumbu ya mfumo 5 iliachwa. Kila mtu alifurahi sana, kwa sababu vinginevyo unajaribu kuendesha matukio mawili ya PostgreSQL kwenye mashine moja, na anasema kuwa sina kumbukumbu ya kutosha ya pamoja. Na anasema kwamba sysctl inahitaji kusahihishwa. Na kuna sysctl vile kwamba bado unahitaji reboot, nk Kwa ujumla, kila mtu alikuwa na furaha. Lakini mgao wa kumbukumbu ya mmap ulivunja matumizi ya kurasa kubwa. Wateja wetu wengi hutumia vihifadhi vikubwa vilivyoshirikiwa. Na tulipendekeza sana tusibadili hadi 9.3, kwa sababu juu ya juu huko ilianza kuhesabiwa kwa asilimia nzuri.

Lakini jamii ilizingatia shida hii na mnamo 9.4 walirekebisha tukio hili vizuri sana. Na katika 9.4 parameta ilionekana katika postgresql.conf ambayo unaweza kuwezesha kujaribu, kuwasha au kuzima.

Jaribu ni chaguo salama zaidi. Wakati PostgreSQL inapoanza, inapogawa kumbukumbu iliyoshirikiwa, inajaribu kunyakua kumbukumbu hii kutoka kwa kurasa kubwa. Na ikiwa haifanyi kazi, basi inarudi kwenye uteuzi wa kawaida. Na ikiwa una FreeBSD au Solaris, basi unaweza kujaribu, daima ni salama.

Ikiwa imewashwa, basi haianzi ikiwa haikuweza kuchagua kutoka kwa kurasa kubwa. Hapa tayari ni juu ya nani na nini ni nzuri zaidi. Lakini ikiwa umejaribu, basi hakikisha kwamba una kile unachohitaji kuangaziwa, kwa sababu kuna nafasi nyingi ya makosa. Hivi sasa utendakazi huu unafanya kazi kwenye Linux pekee.

Ujumbe mmoja mdogo kabla hatujaendelea zaidi. Kurasa kubwa za uwazi bado hazihusu PostgreSQL. Hawezi kuzitumia kawaida. Na kwa Uwazi kurasa kubwa kwa mzigo kama huo wa kazi, wakati sehemu kubwa ya kumbukumbu iliyoshirikiwa inahitajika, faida huja tu na idadi kubwa sana. Ikiwa una kumbukumbu ya terabytes basi hii inaweza kutumika. Ikiwa tunazungumza juu ya utumizi zaidi wa kila siku, unapokuwa na kumbukumbu ya 32, 64, 128, 256 kwenye mashine yako, basi kurasa kubwa za kawaida ni sawa, na tunazima kwa urahisi Transparent.

Na jambo la mwisho kuhusu kumbukumbu haihusiani moja kwa moja na matunda, inaweza kuharibu maisha yako. Upitishaji wote utaathiriwa sana na ukweli kwamba seva inabadilishana kila wakati.

Na hii itakuwa mbaya sana kwa njia kadhaa. Na shida kuu ni kwamba kokwa za kisasa zina tabia tofauti kidogo na kokwa za zamani za Linux. Na jambo hili halifurahishi sana kuendelea, kwa sababu tunapozungumza juu ya aina fulani ya kazi na kubadilishana, inaisha na kuwasili kwa muuaji wa OOM kwa wakati. Na muuaji wa OOM, ambaye hakufika kwa wakati unaofaa na akaacha PostgreSQL, haifurahishi. Kila mtu atajua kuhusu hili, yaani, hadi mtumiaji wa mwisho.

Nini kinaendelea? Una kiasi kikubwa cha RAM huko, kila kitu kinafanya kazi vizuri. Lakini kwa sababu fulani seva hutegemea kubadilishana na kupungua kwa sababu ya hii. Inaweza kuonekana kuwa kuna kumbukumbu nyingi, lakini hii hufanyika.

Hapo awali, tulishauri kuweka vm.swappiness hadi sifuri, yaani kuzima ubadilishaji. Hapo awali, ilionekana kuwa 32 GB ya RAM na buffers sambamba iliyoshirikiwa ilikuwa kiasi kikubwa. Kusudi kuu la kubadilishana ni kuwa na mahali pa kutupa ukoko ikiwa tutaanguka. Na haikutimizwa tena haswa. Na kisha utafanya nini na ukoko huu? Hili ni jukumu ambalo haijulikani wazi kwa nini ubadilishaji unahitajika, haswa saizi kama hiyo.

Lakini katika kisasa zaidi, yaani, matoleo ya tatu ya kernel, tabia imebadilika. Na ikiwa utaweka ubadilishaji hadi sifuri, yaani, kuzima, basi mapema au baadaye, hata ikiwa RAM imesalia, muuaji wa OOM atakuja kwako ili kuua watumiaji wengi zaidi. Kwa sababu atazingatia kwamba kwa mzigo huo wa kazi bado tuna kidogo kushoto na tutaruka nje, yaani, sio msumari chini ya mchakato wa mfumo, lakini kwa msumari chini ya kitu kisicho muhimu. Huyu ambaye sio muhimu sana atakuwa mtumiaji mkubwa wa kumbukumbu iliyoshirikiwa, yaani msimamizi wa posta. Na baada ya hayo itakuwa nzuri ikiwa msingi haupaswi kurejeshwa.

Kwa hivyo, sasa chaguo-msingi, kwa kadiri ninavyokumbuka, usambazaji mwingi uko mahali pengine karibu 6, i.e. ni wakati gani unapaswa kuanza kutumia kubadilishana kulingana na kumbukumbu ngapi iliyobaki. Sasa tunapendekeza kuweka vm.swappiness = 1, kwa sababu hii inaizima, lakini haitoi athari sawa na muuaji wa OOM ambaye alifika bila kutarajia na kuua kitu kizima.

Nini kinafuata? Tunapozungumzia juu ya utendaji wa databases na hatua kwa hatua kuelekea disks, kila mtu huanza kunyakua vichwa vyao. Kwa sababu ukweli kwamba diski ni polepole na kumbukumbu ni ya haraka inajulikana kwa kila mtu kutoka utoto. Na kila mtu anajua kwamba database itakuwa na matatizo ya utendaji wa disk.

Shida kuu ya utendaji ya PostgreSQL inayohusishwa na miiba ya vituo vya ukaguzi haitokei kwa sababu diski ni polepole. Hii ni uwezekano mkubwa kutokana na ukweli kwamba kumbukumbu na diski bandwidth si usawa. Walakini, haziwezi kuwa na usawa katika sehemu tofauti. PostgreSQL haijasanidiwa, OS haijasanidiwa, maunzi hayajasanidiwa na maunzi si sahihi. Na shida hii haifanyiki tu ikiwa kila kitu kitatokea kama inavyopaswa, i.e. ama hakuna mzigo, au mipangilio na vifaa vimechaguliwa vizuri.

Ni nini na inaonekanaje? Kawaida watu wanaofanya kazi na PostgreSQL wameingia katika suala hili zaidi ya mara moja. Nitaeleza. Kama nilivyosema, PostgreSQL mara kwa mara hufanya vituo vya ukaguzi ili kutupa kurasa chafu kwenye kumbukumbu iliyoshirikiwa kwa diski. Ikiwa tuna idadi kubwa ya kumbukumbu iliyoshirikiwa, basi sehemu ya ukaguzi huanza kuwa na athari kubwa kwenye diski, kwa sababu inatupa kurasa hizi kwa fsync. Inafika kwenye bafa ya kernel na imeandikwa kwa diski kwa kutumia fsync. Na ikiwa kiasi cha biashara hii ni kikubwa, basi tunaweza kuona athari mbaya, yaani matumizi makubwa sana ya disks.

Hapa nina picha mbili. Sasa nitaelezea ni nini. Hizi ni grafu mbili zinazohusiana na wakati. Grafu ya kwanza ni matumizi ya diski. Hapa inafikia karibu 90% wakati huu kwa wakati. Ikiwa una kushindwa kwa database na disks za kimwili, na matumizi ya mtawala wa RAID kwa 90%, basi hii ni habari mbaya. Hii ina maana kwamba kidogo zaidi na itafikia 100 na I / O itaacha.

Ikiwa una safu ya diski, basi ni hadithi tofauti kidogo. Inategemea jinsi imeundwa, ni aina gani ya safu, nk.

Na kwa sambamba, grafu kutoka kwa mtazamo wa ndani wa postgres imeundwa hapa, ambayo inaelezea jinsi kituo cha ukaguzi kinatokea. Na rangi ya kijani hapa inaonyesha ni vibafa ngapi, kurasa hizi chafu, wakati huo zilifika kwenye kituo hiki cha ukaguzi kwa ulandanishi. Na hili ndilo jambo kuu unahitaji kujua hapa. Tunaona kwamba tuna kurasa nyingi hapa na wakati fulani tunapiga ubao, yaani, tuliandika na kuandika, hapa mfumo wa disk ni wazi sana. Na ukaguzi wetu una athari kubwa sana kwenye diski. Kwa kweli, hali inapaswa kuonekana zaidi kama hii, i.e. tulikuwa na rekodi ndogo hapa. Na tunaweza kuirekebisha na mipangilio ili iendelee kuwa hivi. Hiyo ni, kuchakata ni ndogo, lakini mahali fulani tunaandika kitu hapa.

Nini kifanyike ili kuondokana na tatizo hili? Ikiwa umesimamisha IO chini ya hifadhidata, hii ina maana kwamba watumiaji wote waliokuja kutimiza maombi yao watasubiri.

Ikiwa unatazama kutoka kwa mtazamo wa Linux, ikiwa ulichukua vifaa vyema, ukaisanidi kwa usahihi, umesanidi PostgreSQL kawaida ili ifanye vituo hivi vya ukaguzi chini mara nyingi, kueneza kwa muda kati ya kila mmoja, kisha unaingia kwenye vigezo vya Debian chaguo-msingi. Kwa usambazaji mwingi wa Linux, hii ndio picha: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Ina maana gani? Pepo mmoja anayefurusha alionekana kutoka kwa kernel 2.6. Pdglush, kulingana na ni nani anayetumia ambayo, ambayo inahusika katika utupaji wa nyuma wa kurasa chafu kutoka kwa bafa ya kernel na kutupa wakati inahitajika kutupa kurasa chafu bila kujali nini, wakati utupaji wa nyuma hausaidii.

Mandharinyuma huja lini? Wakati 10% ya jumla ya RAM inayopatikana kwenye seva inachukuliwa na kurasa chafu kwenye buffer ya kernel, kazi maalum ya kuandika inaitwa nyuma. Kwa nini ni background? Kama parameta, inazingatia ni kurasa ngapi za kuandika. Na, wacha tuseme, anaandika kurasa za N. Na kwa muda jambo hili hulala. Na kisha anakuja tena na kunakili kurasa zingine.

Hii ni hadithi rahisi sana. Tatizo hapa ni sawa na bwawa la kuogelea, likimiminika kwenye bomba moja, linatiririka hadi lingine. Kituo chetu cha ukaguzi kilifika na ikiwa kilituma kurasa chache chafu za kutupwa, basi hatua kwa hatua jambo zima litatatuliwa vizuri kutoka kwa pgflush ya kernel buffer.

Ikiwa kurasa hizi chafu zinaendelea kujilimbikiza, hujilimbikiza hadi 20%, baada ya hapo kipaumbele cha OS ni kuandika jambo zima kwenye diski, kwa sababu nguvu zitashindwa na kila kitu kitakuwa mbaya kwetu. Tutapoteza data hii, kwa mfano.

Ujanja ni nini? Ujanja ni kwamba vigezo hivi katika ulimwengu wa kisasa ni 20 na 10% ya jumla ya RAM iliyo kwenye mashine, ni mbaya kabisa kwa suala la upitishaji wa mfumo wowote wa diski unao.

Fikiria una GB 128 ya RAM. GB 12,8 hufika kwenye mfumo wako wa diski. Na haijalishi una kache gani hapo, haijalishi una safu gani hapo, hazitadumu kwa muda mrefu.

Kwa hivyo, tunapendekeza urekebishe nambari hizi mara moja kulingana na uwezo wa kidhibiti chako cha RAID. Mara moja nilitoa pendekezo hapa kwa kidhibiti ambacho kina 512 MB ya kache.

Kila kitu kinachukuliwa kuwa rahisi sana. Unaweza kuweka vm.dirty_background katika ka. Na mipangilio hii itaghairi mbili zilizopita. Uwiano wowote ni chaguo-msingi, au zile zilizo na ka zimewashwa, basi zile zilizo na ka zitafanya kazi. Lakini kwa kuwa mimi ni mshauri wa DBA na ninafanya kazi na wateja tofauti, ninajaribu kuteka majani na kwa hiyo, ikiwa ni kaiti, basi kwa ka. Hakuna mtu aliyetoa hakikisho lolote kwamba msimamizi mzuri hataongeza kumbukumbu zaidi kwenye seva, kuwasha upya, na takwimu itabaki sawa. Hesabu tu nambari hizi ili kila kitu kiingie huko na dhamana.

Nini kitatokea ikiwa haufai? Nimeandika kwamba kuvuta yoyote kunasimamishwa kwa ufanisi, lakini kwa kweli hii ni mfano wa hotuba. Mfumo wa uendeshaji una tatizo kubwa - una kurasa nyingi chafu, hivyo IO ambayo wateja wako huzalisha imesimamishwa kwa ufanisi, yaani, maombi yamekuja kutuma swali la sql kwenye hifadhidata, inasubiri. Pembejeo/pato lolote kwake ni la kipaumbele cha chini kabisa, kwa sababu hifadhidata inakaliwa na kituo cha ukaguzi. Na lini atamaliza haijulikani kabisa. Na wakati umefanikisha uboreshaji usio wa chinichini, inamaanisha kuwa IO yako yote imekaliwa nayo. Na mpaka mwisho, hutafanya chochote.

Kuna mambo mawili muhimu zaidi hapa ambayo yako nje ya upeo wa ripoti hii. Mipangilio hii inapaswa kuendana na mipangilio katika postgresql.conf, yaani mipangilio ya vituo vya ukaguzi. Na mfumo wako wa diski lazima usanidiwe vya kutosha. Ikiwa una cache kwenye RAID, basi lazima iwe na betri. Watu hununua RAID na kashe nzuri bila betri. Ikiwa una SSD katika RAID, basi lazima iwe na seva, lazima iwe na capacitors huko. Hapa kuna orodha ya kina. Kiunga hiki kina ripoti yangu ya jinsi ya kusanidi diski ya utendaji katika PostgreSQL. Kuna orodha zote hizi hapo.

Ni nini kingine kinachoweza kufanya maisha kuwa magumu sana? Hivi ni vigezo viwili. Wao ni mpya kiasi. Kwa chaguo-msingi, zinaweza kujumuishwa katika programu tofauti. Na wanaweza kufanya maisha kuwa magumu kama watawashwa kimakosa.

Kuna mambo mawili mapya kiasi. Tayari wameonekana katika cores ya tatu. Hii ni sched_migration_cost katika nanoseconds na sched_autogroup_enabled, ambayo ni moja kwa chaguomsingi.

Na wanaharibuje maisha yako? sched_migration_cost ni nini? Kwenye Linux, kipanga ratiba kinaweza kuhamisha mchakato kutoka CPU moja hadi nyingine. Na kwa PostgreSQL, ambayo hutekeleza maswali, kuhamia CPU nyingine haijulikani kabisa. Kutoka kwa mtazamo wa mfumo wa uendeshaji, unapobadilisha madirisha kati ya openoffice na terminal, hii inaweza kuwa nzuri, lakini kwa hifadhidata hii ni mbaya sana. Kwa hivyo, sera inayofaa ni kuweka migration_cost kwa thamani fulani kubwa, angalau nanoseconds elfu kadhaa.

Hii itamaanisha nini kwa mpanga ratiba? Itazingatiwa kuwa wakati huu mchakato bado ni moto. Hiyo ni, ikiwa una shughuli ya muda mrefu ambayo imekuwa ikifanya kitu kwa muda mrefu, mpangaji ataelewa hili. Atafikiri kwamba hadi muda huu upite, hakuna haja ya kuhamia mchakato huu popote. Ikiwa wakati huo huo mchakato unafanya kitu, basi haitahamishwa popote, itafanya kazi kwa utulivu kwenye CPU ambayo ilitengwa kwa hiyo. Na matokeo ni bora.

Jambo la pili ni kundi la kiotomatiki. Kuna wazo nzuri kwa mzigo maalum wa kazi ambao hauhusiani na hifadhidata za kisasa - hii ni kuweka michakato ya kikundi na terminal ya kawaida ambayo imezinduliwa. Hii ni rahisi kwa baadhi ya kazi. Kwa mazoezi, PostgreSQL ni mfumo wa michakato mingi na uma ambayo inaendesha kutoka kwa terminal moja. Una mtunzi wa kufuli, kituo cha ukaguzi, na maombi yako yote ya mteja yatapangwa katika kipanga ratiba kimoja, kwa kila CPU. Na watamsubiri hapo kwa pamoja ili awe huru, ili waingiliane wao kwa wao na kumshughulisha zaidi. Hii ni hadithi ambayo sio lazima kabisa katika kesi ya mzigo kama huo na kwa hivyo inahitaji kuzimwa.

Mwenzangu Alexey Lesovsky alifanya vipimo na pgbench rahisi, ambapo aliongeza migration_cost kwa amri ya ukubwa na kuzima autogroup. Tofauti kwenye vifaa vibaya ilikuwa karibu 10%. Kuna mjadala kwenye orodha ya postgres ambapo watu hutoa matokeo ya mabadiliko sawa na kasi ya hoja imeathiriwa 50%. Kuna hadithi nyingi sana kama hizo.

Na hatimaye, kuhusu sera ya kuokoa nguvu. Jambo zuri ni kwamba Linux sasa inaweza kutumika kwenye kompyuta ndogo. Na inadaiwa itatumia betri vizuri. Lakini ghafla inageuka kuwa hii inaweza pia kutokea kwenye seva.

Zaidi ya hayo, ikiwa unakodisha seva kutoka kwa mhudumu fulani, basi wasimamizi "wazuri" hawajali kuwa una utendaji bora. Kazi yao ni kuhakikisha kuwa chuma chao kinatumika kwa ufanisi iwezekanavyo. Kwa hiyo, kwa default wanaweza kuwezesha hali ya kuokoa nguvu ya laptop kwenye mfumo wa uendeshaji.

Ikiwa unatumia vitu hivi kwenye seva iliyo na hifadhidata chini ya mzigo mzito, basi chaguo lako ni acpi_cpufreq + permornce. Hata kwa mahitaji kutakuwa na matatizo.

Intel_pstate ni dereva tofauti kidogo. Na sasa upendeleo hutolewa kwa hii, kama ni baadaye na inafanya kazi vizuri zaidi.

Na, ipasavyo, gavana ni utendaji tu. Mahitaji, kuokoa nguvu na kila kitu kingine sio kukuhusu.

Matokeo ya uchanganuzi wa kuchambua PostgreSQL yanaweza kutofautiana kwa maagizo kadhaa ya ukubwa ikiwa utawezesha kuokoa nguvu, kwa sababu kivitendo CPU iliyo chini ya hifadhidata yako itakuwa ikifanya kazi kwa njia isiyotabirika kabisa.

Vipengee hivi vinaweza kujumuishwa kwa chaguomsingi. Angalia kwa uangalifu ili kuona ikiwa waliwasha kwa chaguo-msingi. Hili linaweza kuwa tatizo kubwa sana.

Na mwisho, nilitaka kusema asante kwa wavulana kutoka kwa timu yetu ya PosgreSQL-Consulting DBA, ambayo ni Max Boguk na Alexey Lesovsky, ambao wanapiga hatua katika suala hili kila siku. Na tunajaribu kufanya bora tuwezavyo kwa wateja wetu ili yote yawafanyie kazi. Ni sawa na maagizo ya usalama wa anga. Kila kitu hapa kimeandikwa kwa damu. Kila moja ya karanga hizi hupatikana katika mchakato wa aina fulani ya shida. Nina furaha kuwashirikisha nanyi.

Maswali:

Asante! Ikiwa, kwa mfano, kampuni inataka kuokoa pesa na kuweka hifadhidata na mantiki ya programu kwenye seva moja, au ikiwa kampuni inafuata mtindo wa usanifu wa huduma ndogo, ambayo PostgreSQL inaendesha kwenye kontena. Ujanja ni nini? Sysctl itaathiri kernel nzima kimataifa. Sijasikia kuhusu sysclts kuwa kwa namna fulani virtualized ili kufanya kazi tofauti kwenye chombo. Kuna kikundi tu na kuna sehemu tu ya udhibiti hapo. Unawezaje kuishi na hii? Au ikiwa unataka utendaji, basi endesha PostgreSQL kwenye seva tofauti ya vifaa na uifanye?

Tulijibu swali lako kwa njia tatu hivi. Ikiwa hatuzungumzii juu ya seva ya vifaa ambayo inaweza kupangwa, nk, kisha pumzika, kila kitu kitafanya kazi vizuri bila mipangilio hii. Ikiwa una mzigo ambao unahitaji kufanya mipangilio hii, basi utakuja kwenye seva ya chuma mapema kuliko kwa mipangilio hii.

Shida ni nini? Ikiwa hii ni mashine ya kawaida, basi uwezekano mkubwa utakuwa na matatizo mengi, kwa mfano, na ukweli kwamba kwenye mashine nyingi za kawaida latency ya disk haiendani kabisa. Hata ikiwa upitishaji wa diski ni mzuri, basi shughuli moja iliyoshindwa ya I / O ambayo haiathiri sana mtiririko wa wastani ambao ulifanyika wakati wa ukaguzi au wakati wa kuandika kwa WAL, basi hifadhidata itateseka sana kutokana na hili. Na utaona hili kabla ya kuingia kwenye matatizo haya.

Ikiwa unayo NGINX kwenye seva hiyo hiyo, pia utakuwa na shida sawa. Atapigania kumbukumbu ya pamoja. Na huwezi kupata matatizo yaliyoelezwa hapa.

Lakini kwa upande mwingine, baadhi ya vigezo hivi bado vitakuwa muhimu kwako. Kwa mfano, weka dirty_ratio na sysctl ili isiwe wazimu - kwa hali yoyote, hii itasaidia. Njia moja au nyingine, utakuwa na mwingiliano na diski. Na itakuwa kulingana na muundo mbaya. Kwa ujumla hii ni chaguo-msingi kwa vigezo ambavyo nilionyesha. Na kwa hali yoyote ni bora kuzibadilisha.

Lakini kunaweza kuwa na matatizo na NUMA. VmWare, kwa mfano, inafanya kazi vizuri na NUMA na mipangilio tofauti kabisa. Na hapa unapaswa kuchagua - seva ya chuma au isiyo ya chuma.

Nina swali linalohusiana na Amazon AWS. Zina picha zilizosanidiwa mapema. Mmoja wao anaitwa Amazon RDS. Je, kuna mipangilio maalum ya mfumo wao wa uendeshaji?

Kuna mipangilio huko, lakini ni mipangilio tofauti. Hapa tunasanidi mfumo wa uendeshaji kulingana na jinsi database itatumia jambo hili. Na kuna vigezo vinavyoamua ni wapi tunapaswa kwenda sasa, kama vile kuunda. Yaani tunahitaji rasilimali nyingi sana, sasa tutakula. Baada ya hayo, Amazon RDS inaimarisha rasilimali hizi, na utendaji hushuka hapo. Kuna hadithi za kibinafsi za jinsi watu wanavyoanza kuchafua jambo hili. Wakati mwingine hata kwa mafanikio kabisa. Lakini hii haina uhusiano wowote na mipangilio ya OS. Ni kama kudukua wingu. Hiyo ni hadithi tofauti.

Kwa nini kurasa kubwa za Uwazi hazina athari ikilinganishwa na Kubwa TLB?

Usitoe. Hii inaweza kuelezewa kwa njia nyingi. Lakini kwa kweli hawatoi. Historia ya PostgreSQL ni nini? Wakati wa kuanza, hutenga sehemu kubwa ya kumbukumbu iliyoshirikiwa. Ikiwa ni wazi au la sio muhimu kabisa. Ukweli kwamba wanajitokeza mwanzoni huelezea kila kitu. Na ikiwa kuna kumbukumbu nyingi na unahitaji kujenga upya sehemu ya pamoja_ya kumbukumbu, basi kurasa kubwa za Uwazi zitafaa. Katika PostgreSQL, imetengwa kwa sehemu kubwa mwanzoni na ndivyo ilivyo, na kisha hakuna kitu maalum kinachotokea hapo. Unaweza, kwa kweli, kuitumia, lakini kuna nafasi ya kupata ufisadi wa kumbukumbu_ya pamoja wakati inagawa tena kitu. PostgreSQL haijui kuhusu hili.

Chanzo: mapenzi.com