Prandaj, qasja e duhur \u00ebsht\u00eb q\u00eb t\u00eb \u00e7aktivizohet NUMA<\/strong>, p\u00ebr shembull, gjat\u00eb rinisjes. N\u00eb shumic\u00ebn e rasteve, p\u00ebrfitimet jan\u00eb kaq t\u00eb m\u00ebdha sa q\u00eb nuk ka asnj\u00eb pyetje se si \u00ebsht\u00eb m\u00eb mir\u00eb. <\/p>\n<\/p>\n
Ka nj\u00eb opsion tjet\u00ebr. Ne e p\u00ebrdorim at\u00eb m\u00eb shpesh se sa t\u00eb parin, sepse kur nj\u00eb klient vjen p\u00ebr mb\u00ebshtetje, rinisja e serverit \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje e madhe. Ai ka biznes q\u00eb funksionon. Dhe ai p\u00ebrballet me probleme p\u00ebr shkak t\u00eb NUMA. Prandaj ne p\u00ebrpiqemi ta \u00e7aktivizojm\u00eb n\u00eb m\u00ebnyra m\u00eb pak invazive se sa rinisja, por k\u00ebtu duhet t\u00eb kontrolloni se \u00e7far\u00eb \u00ebsht\u00eb \u00e7aktivizuar. Sepse, si\u00e7 e tregon p\u00ebrvoja, \u00e7aktivizimi i NUMA p\u00ebr procesin prindor t\u00eb PostgreSQL \u00ebsht\u00eb i mir\u00eb, por nuk \u00ebsht\u00eb domosdoshm\u00ebrisht se do t\u00eb funksionoj\u00eb. Duhet ta kontrolloni dhe shikoni se a \u00ebsht\u00eb \u00e7aktivizuar me t\u00eb v\u00ebrtet\u00eb. <\/p>\n
<\/p>\n
Ka nj\u00eb post t\u00eb mir\u00eb nga Robert Haas. Ai \u00ebsht\u00eb nj\u00eb nga kontribuesit e PostgreSQL. Nj\u00eb nga zhvilluesit kryesor\u00eb t\u00eb t\u00eb gjitha derivateve t\u00eb ul\u00ebta. Dhe n\u00ebse ndiheni p\u00ebrmes lidhjeve nga ky post, atje p\u00ebrshkruhen disa histori interesante p\u00ebr m\u00ebnyr\u00ebn si NUMA ka komplikuar jet\u00ebn e njer\u00ebzve. Shikoni, studioni check-list-in p\u00ebr administratorin e sistemeve, \u00e7far\u00eb duhet t\u00eb mund\u00ebsohet n\u00eb server p\u00ebr q\u00eb baza e t\u00eb dh\u00ebnave t\u00eb funksionoj\u00eb mir\u00eb. K\u00ebto konfigurime duhet t\u00eb shkruhen dhe kontrollohen, sepse ndryshe nuk do t\u00eb jet\u00eb shum\u00eb mir\u00eb. <\/p>\n
<\/p>\n
V\u00ebrej se kjo p\u00ebrfshin t\u00eb gjitha konfigurimet p\u00ebr t\u00eb cilat do t\u00eb flas. Por zakonisht bazat e t\u00eb dh\u00ebnave mblidhen n\u00eb modin master-slave p\u00ebr q\u00ebndrueshm\u00ebri. Mos haroni t\u00eb b\u00ebni k\u00ebto konfigurime n\u00eb slave, sepse nj\u00eb dit\u00eb do t'ju ndodh\u00eb nj\u00eb katastrof\u00eb dhe do t\u00eb kaloni n\u00eb slave, dhe ai do t\u00eb b\u00ebhet master. <\/p>\n
<\/p>\n
N\u00eb nj\u00eb situat\u00eb katastrofike, kur gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e keqe, telefoni juaj do t\u00eb th\u00ebrras\u00eb vazhdimisht dhe shefi do t\u00eb vij\u00eb me nj\u00eb shkop t\u00eb madh, nuk do t\u00eb keni koh\u00eb t\u00eb mendoni p\u00ebr t\u00eb kontrolluar. Dhe rezultatet mund t\u00eb jen\u00eb mjaft tragjike.<\/p>\n
<\/p>\n
<\/p>\n
Moment tjet\u00ebr \u2013 jan\u00eb huge pages. Huge pages jan\u00eb t\u00eb v\u00ebshtira p\u00ebr t'u testuar ve\u00e7mas, dhe nuk ka kuptim p\u00ebr k\u00ebt\u00eb, megjith\u00ebse ka benchmarke q\u00eb din\u00eb ta b\u00ebjn\u00eb. Ato jan\u00eb t\u00eb lehta p\u00ebr t'u gjetur n\u00eb internet. <\/p>\n
<\/p>\n
\u00c7far\u00eb ka kuptim? Keni nj\u00eb server jo shum\u00eb t\u00eb shtrenjt\u00eb, n\u00eb t\u00eb cilin ka shum\u00eb memorje operative, p\u00ebr shembull, m\u00eb shum\u00eb se 30 GB. Nuk jeni duke p\u00ebrdorur huge pages. Kjo do t\u00eb thot\u00eb q\u00eb patjet\u00ebr ka overhead nga p\u00ebrdorimi i memorjes. Dhe ky overhead nuk \u00ebsht\u00eb aspak i k\u00ebndsh\u00ebm. <\/p>\n
<\/p>\n
<\/p>\n
Pse k\u00ebshtu? \u00c7far\u00eb ndodh? Sistemi operativ e ndan memorjen n\u00eb cop\u00ebza t\u00eb vogla. Aq e p\u00ebrshtatshme, aq historikisht \u00ebsht\u00eb vendosur. Dhe n\u00ebse shtojm\u00eb holl\u00ebsira, OS duhet t\u00eb translate adresat virtuale n\u00eb ato fizike. Dhe ky proces nuk \u00ebsht\u00eb m\u00eb i lehti, prandaj OS e ruan rezultatin e k\u00ebsaj operacioneje n\u00eb Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Dhe p\u00ebr sa koh\u00eb TLB \u2013 \u00ebsht\u00eb nj\u00eb cache, n\u00eb k\u00ebt\u00eb situat\u00eb ndodhin t\u00eb gjitha problemet e njohura t\u00eb cache-it. S\u00eb pari, n\u00ebse keni shum\u00eb memorje operative dhe e gjith\u00eb ajo \u00ebsht\u00eb e ndar\u00eb n\u00eb cop\u00ebza t\u00eb vogla, at\u00ebher\u00eb ky buffer b\u00ebhet shum\u00eb i madh. Dhe n\u00ebse cache-i \u00ebsht\u00eb i madh, k\u00ebrkimi n\u00eb t\u00eb b\u00ebhet m\u00eb i ngadalsh\u00ebm. Overhead-i \u00ebsht\u00eb i sh\u00ebndosh\u00eb dhe ai vet\u00eb konsumon vend, dmth. memorja operative konsumon di\u00e7ka t\u00eb pap\u00ebrshtatshme. Kjo \u00ebsht\u00eb nj\u00ebra nga arsyet. <\/p>\n
<\/p>\n
Dy \u2013 sa m\u00eb shum\u00eb q\u00eb rritet cache n\u00eb nj\u00eb situat\u00eb t\u00eb till\u00eb, aq m\u00eb shum\u00eb rritet mund\u00ebsia q\u00eb t\u00eb keni cache misses. Efikasiteti i k\u00ebtij cache bie shum\u00eb shpejt me rritjen e madh\u00ebsis\u00eb s\u00eb tij. Prandaj, n\u00eb sistemet operative \u00ebsht\u00eb ideuar nj\u00eb qasje e thjesht\u00eb. N\u00eb Linux, kjo \u00ebsht\u00eb e njohur prej koh\u00ebsh. N\u00eb FreeBSD, kjo u shfaq jo shum\u00eb koh\u00eb m\u00eb par\u00eb. Por ne po flasim p\u00ebr Linux. K\u00ebto jan\u00eb huge pages.<\/p>\n
<\/p>\n
Dhe k\u00ebtu duhet t\u00eb theksohet se huge pages, si ide, fillimisht u promovua nga komunitetet q\u00eb p\u00ebrfshinin Oracle dhe IBM, dmth. prodhuesit e bazave t\u00eb t\u00eb dh\u00ebnave mendojn\u00eb se kjo do t\u00eb jet\u00eb e dobishme, p\u00ebrfshir\u00eb p\u00ebr bazat e t\u00eb dh\u00ebnave. <\/p>\n
<\/p>\n
<\/p>\n
Dhe si ta lidhim k\u00ebt\u00eb me PostgreSQL? S\u00eb pari, n\u00eb b\u00ebrtham\u00ebn e Linux-it duhet t\u00eb aktivizohen huge pages.<\/p>\n
<\/p>\n
S\u00eb dyti, ato duhet t\u00eb p\u00ebrcaktohen qart\u00eb me parametrin sysctl - sa prej tyre do t\u00eb ket\u00eb. Numrat k\u00ebtu jan\u00eb nga ndonj\u00eb server i vjet\u00ebr. Mund t\u00eb llogaritni se sa af\u00ebrsisht keni shared buffers, n\u00eb m\u00ebnyr\u00eb q\u00eb huge pages t\u00eb p\u00ebrshtaten atje. <\/p>\n
<\/p>\n
Dhe n\u00ebse e gjith\u00eb serveri \u00ebsht\u00eb dedikuar p\u00ebr PostgreSQL, nj\u00eb pik\u00eb e mir\u00eb fillestare \u00ebsht\u00eb t\u00eb ndajm\u00eb ose 25% t\u00eb memorie RAM p\u00ebr shared buffers, ose 75%, n\u00ebse jeni t\u00eb sigurt se n\u00eb k\u00ebt\u00eb 75% baza juaj e t\u00eb dh\u00ebnave do t\u00eb p\u00ebrshtatet me siguri. Nj\u00eb pik\u00eb fillestare e par\u00eb. Dhe llogaritni, n\u00ebse keni 256 GB memorie RAM, at\u00ebher\u00eb, p\u00ebrkat\u00ebsisht, do t\u00eb keni 64 GB t\u00eb shared buffers. Llogaritni pak me ndonj\u00eb rezerv\u00eb \u2013 se \u00e7far\u00eb duhet t\u00eb jet\u00eb ky num\u00ebr.<\/p>\n
<\/p>\n
Derisa t\u00eb arrij\u00eb versionin 9.2 (nese nuk gaboj, q\u00eb nga versioni 8.2) mund t\u00eb lidhni PostgreSQL me huge pages p\u00ebrmes nj\u00eb biblioteke t\u00eb jashtme. Dhe kjo gjithmon\u00eb duhet b\u00ebr\u00eb. S\u00eb pari, ju duhet q\u00eb b\u00ebrthama t\u00eb dij\u00eb si t\u00eb alokoj\u00eb sakt\u00ebsisht huge pages. Dhe, s\u00eb dyti, aplikacioni q\u00eb punon me to duhet t\u00eb jet\u00eb n\u00eb gjendje t'i p\u00ebrdor\u00eb ato. Ajo nuk do t'i p\u00ebrdor\u00eb thjesht p\u00ebr asgj\u00eb. Duke qen\u00eb se PostgreSQL alokonte memorie n\u00eb stilin e sistemit 5, kjo mund t\u00eb b\u00ebhej p\u00ebrmes libhugetlbfs - ky \u00ebsht\u00eb emri i plot\u00eb i bibliotek\u00ebs.<\/p>\n
<\/p>\n
N\u00eb versionin 9.3, u p\u00ebrmir\u00ebsua performanca e PostgreSQL-it n\u00eb pun\u00ebn me memorien dhe u hoq metoda e alokimit t\u00eb memories s\u00eb sistemit 5. T\u00eb gjith\u00eb u g\u00ebzuan shum\u00eb, sepse ndryshe, kur p\u00ebrpiqesh t\u00eb nis\u00ebsh dy instanca PostgreSQL n\u00eb nj\u00eb makin\u00eb, ai thot\u00eb se nuk kam mjaftuesh\u00ebm memorje t\u00eb ndar\u00eb. Dhe thot\u00eb se duhet t\u00eb rregullohet sysctl. Dhe aty \u00ebsht\u00eb nj\u00eb sysctl t\u00eb till\u00eb, q\u00eb duhet t\u00eb rivendosesh dhe k\u00ebshtu me radh\u00eb. P\u00ebrmbledhtazi, t\u00eb gjith\u00eb u g\u00ebzuan. Por alokimi i memories mmap prishi p\u00ebrdorimin e huge pages. Shumica e klient\u00ebve tan\u00eb p\u00ebrdorin buffers t\u00eb m\u00ebdha t\u00eb ndara. Dhe ne e rekomanduam me k\u00ebmb\u00ebngulje q\u00eb t\u00eb mos kalojn\u00eb n\u00eb 9.3, sepse aty overhead-i fillonte t\u00eb ishte n\u00eb p\u00ebrqindje t\u00eb mira.<\/p>\n
<\/p>\n
Por, komuniteti i vuri re k\u00ebt\u00eb problem dhe n\u00eb versionin 9.4 e p\u00ebrmir\u00ebsuan shum\u00eb k\u00ebt\u00eb proces. Dhe n\u00eb 9.4 u shfaq nj\u00eb parameter n\u00eb postgresql.conf, ku mund t\u00eb aktivizoni try, on ose off.<\/p>\n
<\/p>\n
Try \u2013 \u00ebsht\u00eb parametri m\u00eb i sigurt. Kur PostgreSQL fillon, kur alokon memorjen e ndar\u00eb, ai p\u00ebrpiqet t\u00eb marr\u00eb k\u00ebt\u00eb memorje nga huge pages. Dhe n\u00ebse nuk arrin, at\u00ebher\u00eb rikthehet n\u00eb alokim t\u00eb zakonsh\u00ebm. Dhe n\u00ebse keni FreeBSD ose Solaris, at\u00ebher\u00eb mund ta vendosni try, kjo \u00ebsht\u00eb gjithmon\u00eb e sigurt. <\/p>\n
<\/p>\n
N\u00ebse \u00ebsht\u00eb on, at\u00ebher\u00eb ai thjesht nuk nis n\u00ebse nuk ka arritur t\u00eb alokoj\u00eb nga huge pages. K\u00ebtu tashm\u00eb \u2013 kush e preferon \u00e7far\u00eb m\u00eb shum\u00eb. Por n\u00ebse keni vendosur try, at\u00ebher\u00eb kontrolloni q\u00eb v\u00ebrtet t\u00eb keni marr\u00eb at\u00eb q\u00eb duhet alokuar, sepse ka shum\u00eb hap\u00ebsir\u00eb p\u00ebr gabime. Tani ky funksionalitet punon vet\u00ebm n\u00eb Linux.<\/p>\n
<\/p>\n
Nj\u00eb v\u00ebrejtje e vog\u00ebl, para se t\u00eb vazhdojm\u00eb m\u00eb tej. Transparent huge pages - nuk ka t\u00eb b\u00ebj\u00eb me PostgreSQL derim\u00eb. Ai nuk mund ta p\u00ebrdor\u00eb normalisht. Dhe me Transparent huge pages, p\u00ebr nj\u00eb ngarkes\u00eb t\u00eb till\u00eb pune, kur nevojitet nj\u00eb cop\u00eb e madhe e memorjes t\u00eb ndar\u00eb, p\u00ebrfitimet ndodhin vet\u00ebm n\u00ebse volumet jan\u00eb shum\u00eb t\u00eb m\u00ebdha. N\u00ebse keni terabajt t\u00eb memories, at\u00ebher\u00eb kjo mund t\u00eb ket\u00eb r\u00ebnd\u00ebsi. N\u00ebse flasim p\u00ebr aplikacione m\u00eb t\u00eb zakonshme, kur keni 32, 64, 128, 256 GB memorie n\u00eb makin\u00eb, at\u00ebher\u00eb huge pages e zakonshme \u00ebsht\u00eb e mir\u00eb, dhe Transparent thjesht e ndalojm\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Dhe gj\u00ebja e fundit n\u00eb lidhje me memorien, q\u00eb nuk \u00ebsht\u00eb drejtp\u00ebrdrejt e lidhur me throughput, mund t\u00eb prish\u00eb shum\u00eb jet\u00ebn tuaj. E gjith\u00eb kapaciteti i kalimit do t\u00eb vuaj\u00eb p\u00ebr shkak se serveri vazhdimisht swap-on. <\/p>\n
<\/p>\n
Dhe kjo do t\u00eb jet\u00eb shum\u00eb e pak\u00ebndshme n\u00eb disa momente. Dhe e keqja kryesore \u00ebsht\u00eb se n\u00eb b\u00ebrthamat moderne, sjellja pak a shum\u00eb ndryshon nga b\u00ebrthamat m\u00eb t\u00eb vjetra t\u00eb Linux-it. Dhe kjo \u00ebsht\u00eb nj\u00eb gj\u00eb, mbi t\u00eb cil\u00ebn \u00ebsht\u00eb mjaft e pak\u00ebndshme t\u00eb q\u00ebndrosh, sepse, kur flasim p\u00ebr ndonj\u00eb pun\u00eb me swap-in, p\u00ebrfundon me nj\u00eb ardhje t\u00eb pap\u00ebrshtatshme t\u00eb OOM-killer. Dhe OOM-killer, i cili nuk arriti n\u00eb koh\u00eb dhe ndaloi PostgreSQL-in, \u00ebsht\u00eb e pak\u00ebndshme. K\u00ebt\u00eb do ta din\u00eb t\u00eb gjith\u00eb, dmth. deri te p\u00ebrdoruesi i fundit. <\/p>\n
<\/p>\n
<\/p>\n
\u00c7far\u00eb ndodh? Ju keni nj\u00eb sasi t\u00eb madhe t\u00eb memorjes RAM, gjith\u00e7ka funksionon mir\u00eb. Por p\u00ebr nj\u00eb arsye, serveri ngec n\u00eb swap dhe ngadal\u00ebson p\u00ebr k\u00ebt\u00eb shkak. Duket se ka shum\u00eb memorie, por ndodhi k\u00ebshtu. <\/p>\n
<\/p>\n
<\/p>\n
M\u00eb par\u00eb ne rekomandonim t\u00eb vendosnim vm.swappiness n\u00eb zero, dometh\u00ebn\u00eb, t\u00eb \u00e7aktivizonim swap-in. Ishte dukur se 32 GB memorie RAM dhe buffer\u00ebt e ndar\u00eb t\u00eb ngjash\u00ebm ishin nj\u00eb sasi e madhe. Q\u00ebllimi kryesor i swap-it \u00ebsht\u00eb t\u00eb ket\u00eb nj\u00eb vend p\u00ebr t\u00eb hedhur nj\u00eb proces, n\u00ebse ne d\u00ebshtojm\u00eb. Dhe ndodhte q\u00eb ky funksion nuk po realizohej shum\u00eb. Por \u00e7far\u00eb do t\u00eb b\u00ebsh me at\u00eb proces m\u00eb pas? Ky \u00ebsht\u00eb nj\u00eb problem ku nuk \u00ebsht\u00eb shum\u00eb e qart\u00eb pse ne kemi nevoj\u00eb p\u00ebr swap, sidomos nj\u00eb t\u00eb till\u00eb n\u00eb k\u00ebt\u00eb madh\u00ebsi. <\/p>\n
<\/p>\n
Por n\u00eb versionet m\u00eb moderne, dometh\u00ebn\u00eb, n\u00eb versionet e treta t\u00eb b\u00ebrtham\u00ebs, sjellja ka ndryshuar. Dhe n\u00ebse vendosni swap-in n\u00eb zero, dometh\u00ebn\u00eb, ta \u00e7aktivizoni, p\u00ebr shum\u00eb shpejt, edhe kur keni akoma nj\u00eb sasi t\u00eb caktuar memorie operativ, do t\u00eb vij\u00eb OOM-killer-i p\u00ebr t\u00eb vrar\u00eb konsumator\u00ebt m\u00eb intensiv\u00eb. Sepse ai do t\u00eb mendoj\u00eb se me k\u00ebt\u00eb ngarkes\u00eb na ka mbetur pak dhe do t\u00eb dalim, dmth t\u00eb mos vrasim procesin sistemor, por t\u00eb ulim di\u00e7ka m\u00eb pak t\u00eb r\u00ebnd\u00ebsishme. Kjo gj\u00eb m\u00eb pak e r\u00ebnd\u00ebsishme do t\u00eb jet\u00eb konsumatori intensiv i memories s\u00eb ndar\u00eb, konkretisht postmaster. Pas k\u00ebsaj, do t\u00eb jet\u00eb mir\u00eb n\u00ebse nuk do t\u00eb duhet t\u00eb rikuperojm\u00eb baz\u00ebn. <\/p>\n
<\/p>\n
Prandaj tani defolt, sa mbaj mend, shumica e distribucioneve jan\u00eb diku 6, dometh\u00ebn\u00eb, n\u00eb \u00e7far\u00eb momenti t\u00eb fillojm\u00eb t\u00eb p\u00ebrdorim swap-in n\u00eb var\u00ebsi t\u00eb asaj q\u00eb ka mbetur nga memoria. Tani ne rekomandojm\u00eb t\u00eb vendosim vm.swappiness = 1, sepse kjo n\u00eb praktik\u00eb e \u00e7aktivizon at\u00eb, por nuk shkakton efekte t\u00eb tilla si me OOM-killer-in q\u00eb vjen papritur dhe gjith\u00eb kjo e vret.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
\u00c7far\u00eb ndodh m\u00eb pas? Kur flasim p\u00ebr performanc\u00ebn e bazave t\u00eb t\u00eb dh\u00ebnave dhe gradualisht arrijm\u00eb te disqet, t\u00eb gjith\u00eb fillojn\u00eb t\u00eb shqet\u00ebsohen. Sepse e v\u00ebrteta se disku \u00ebsht\u00eb i ngadalsh\u00ebm dhe memoria \u00ebsht\u00eb e shpejt\u00eb \u00ebsht\u00eb e njohur p\u00ebr t\u00eb gjith\u00eb nga f\u00ebmij\u00ebria. \u00c7do kush e di se do t\u00eb ket\u00eb probleme me performanc\u00ebn e diskut n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave.<\/p>\n
<\/p>\n
Problemi kryesor me performanc\u00ebn e PostgreSQL-it, i lidhur me rritjet n\u00eb checkpoints, nuk ndodh p\u00ebr shkak se disku \u00ebsht\u00eb i ngadalsh\u00ebm. Kjo \u00ebsht\u00eb m\u00eb shum\u00eb p\u00ebr shkak se kapaciteti i memories dhe disqet nuk jan\u00eb t\u00eb balancuar. P\u00ebr m\u00eb tep\u00ebr, ato mund t\u00eb mos jen\u00eb t\u00eb balancuara n\u00eb vende t\u00eb ndryshme. PostgreSQL nuk \u00ebsht\u00eb i konfiguruesh\u00ebm, OS nuk \u00ebsht\u00eb konfiguruesh\u00ebm, hardueri nuk \u00ebsht\u00eb i konfiguruesh\u00ebm dhe hardueri \u00ebsht\u00eb i gabuar. Dhe ky problem nuk ndodh vet\u00ebm n\u00ebse gjith\u00e7ka po shkon si\u00e7 duhet, dmth ose nuk ka ngarkesa, ose konfigurimet dhe hardueri jan\u00eb t\u00eb p\u00ebrshtatura mir\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
\u00c7far\u00eb \u00ebsht\u00eb kjo dhe si duket? Zakonisht njer\u00ebzit q\u00eb punojn\u00eb me PostgreSQL kan\u00eb kaluar shpesh n\u00eb k\u00ebt\u00eb situat\u00eb. Ta sqaroj. Si\u00e7 e thash\u00eb, PostgreSQL her\u00eb pas here b\u00ebn checkpoints, p\u00ebr t\u00eb hedhur faqet e ndotura n\u00eb memorie n\u00eb disk. N\u00ebse kemi nj\u00eb sasi t\u00eb madhe t\u00eb memories s\u00eb ndar\u00eb, at\u00ebher\u00eb checkpoint fillon t\u00eb ndikoj\u00eb fuqish\u00ebm n\u00eb disk, sepse transferon k\u00ebto faqe me fsync. Ai arrin n\u00eb buffer-in e kernel-it dhe shkruhet n\u00eb disqe me an\u00eb t\u00eb fsync. Dhe n\u00ebse sasia e k\u00ebtij procesi \u00ebsht\u00eb e madhe, ne mund t\u00eb shohim nj\u00eb efekt t\u00eb pak\u00ebndsh\u00ebm, dmth nj\u00eb shfryt\u00ebzim shum\u00eb t\u00eb madh t\u00eb disqeve.<\/p>\n
<\/p>\n
K\u00ebtu kam dy figura. Do t'i shpjegoj se \u00e7far\u00eb jan\u00eb. K\u00ebto jan\u00eb dy grafika t\u00eb korrelacionuara n\u00eb koh\u00eb. Grafiku i par\u00eb \u00ebsht\u00eb shfryt\u00ebzimi i diskut. Aty rritet pothuajse deri n\u00eb 90% n\u00eb at\u00eb moment. N\u00ebse keni nj\u00eb baz\u00eb t\u00eb dh\u00ebnash me disqe fizike, me nj\u00eb kontrollues RAID dhe shfryt\u00ebzimi \u00ebsht\u00eb deri n\u00eb 90%, at\u00ebher\u00eb kjo \u00ebsht\u00eb lajm i keq. Kjo do t\u00eb thot\u00eb se pak m\u00eb von\u00eb do t\u00eb arrij\u00eb 100 dhe hyrja-dalja do t\u00eb ndaloj\u00eb. <\/p>\n
<\/p>\n
N\u00ebse keni nj\u00eb \u00e7ik t\u00eb disqeve, at\u00ebher\u00eb aty \u00ebsht\u00eb nj\u00eb histori pak m\u00eb ndryshe. Ajo varet nga m\u00ebnyra si \u00ebsht\u00eb ndar\u00eb, \u00e7far\u00eb lloj disku \u00ebsht\u00eb, etj. <\/p>\n
<\/p>\n
Dhe paralelisht k\u00ebtu \u00ebsht\u00eb konfigurimi i grafikut nga nj\u00eb pamje e brendshme e PostgreSQL-it, e cila tregon se si ndodh checkpoint-i. Dhe me ngjyr\u00eb t\u00eb gjelb\u00ebr k\u00ebtu \u00ebsht\u00eb sh\u00ebnuar sasia e bufferave, k\u00ebto faqe t\u00eb ndotura q\u00eb arrit\u00ebn n\u00eb k\u00ebt\u00eb checkpoint p\u00ebr sinkronizim. Dhe kjo \u00ebsht\u00eb kryesorja q\u00eb duhet t\u00eb dini k\u00ebtu. Ne shohim se shum\u00eb faqe jan\u00eb arritur dhe n\u00eb nj\u00eb moment jemi p\u00ebrballur me nj\u00eb penges\u00eb, dometh\u00ebn\u00eb kemi shkruar-shkruar, k\u00ebtu \u00ebsht\u00eb e qart\u00eb se sistemi i disqeve \u00ebsht\u00eb shum\u00eb i angazhuar. Dhe checkpoint-i ka ndikim t\u00eb madh n\u00eb disk. N\u00eb m\u00ebnyr\u00eb ideale, situata duhet t\u00eb duket m\u00eb shum\u00eb k\u00ebshtu, dometh\u00ebn\u00eb k\u00ebtu kemi pasur m\u00eb pak shkrime. Dhe ne mund ta rregullojm\u00eb k\u00ebt\u00eb me konfigurime, p\u00ebr ta mbajtur m\u00eb k\u00ebshtu. Dometh\u00ebn\u00eb, shfryt\u00ebzimi \u00ebsht\u00eb i vog\u00ebl, por ndonj\u00ebher\u00eb ne shkruajm\u00eb di\u00e7ka. <\/p>\n
<\/p>\n
\u00c7far\u00eb duhet t\u00eb b\u00ebni p\u00ebr ta zgjidhur k\u00ebt\u00eb problem? N\u00ebse ju ka ndaluar IO n\u00ebn baz\u00ebn e t\u00eb dh\u00ebnave, at\u00ebher\u00eb kjo do t\u00eb thot\u00eb se t\u00eb gjith\u00eb p\u00ebrdoruesit q\u00eb erdh\u00ebn p\u00ebr t\u00eb ekzekutuar k\u00ebrkesat e tyre do t\u00eb presin. <\/p>\n
<\/p>\n
<\/p>\n
N\u00ebse e shikoni nga k\u00ebndv\u00ebshtrimi i Linux-it, n\u00ebse keni marr\u00eb nj\u00eb harduer t\u00eb mir\u00eb, e keni konfiguruar si\u00e7 duhet, e keni konfigurur PostgreSQL-in q\u00eb t\u00eb b\u00ebj\u00eb k\u00ebto checkpoints m\u00eb rrall\u00eb, p\u00ebr t'i shp\u00ebrndar\u00eb ato nd\u00ebrmjet nj\u00ebri-tjetrit, at\u00ebher\u00eb ju jeni t\u00eb futur n\u00eb parametrat defolt t\u00eb Debian-it. P\u00ebr shumic\u00ebn e distribucioneve Linux, kjo \u00ebsht\u00eb pamja: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
\u00c7far\u00eb do t\u00eb thot\u00eb kjo? Me kernelin 2.6, \u00ebsht\u00eb shfaqur nj\u00eb demon flushing. Pdglush, n\u00eb var\u00ebsi t\u00eb asaj q\u00eb p\u00ebrdorim, merret me pastrimin e faqeve t\u00eb papastra nga buffer-i i kernel-it dhe i hedh ato kur \u00ebsht\u00eb e nevojshme, duke hedhur faqe t\u00eb papastra kur pastrimi n\u00eb sfond nuk ndihmon m\u00eb. <\/p>\n
<\/p>\n
Kur fillon pastrimi n\u00eb sfond? Kur 10% e gjith\u00eb memorie s\u00eb aksesor\u00ebve n\u00eb server \u00ebsht\u00eb e mbushur me faqe t\u00eb papastra n\u00eb bufferin e kernel-it, aktivizohet nj\u00eb funksion special p\u00ebr pastrim n\u00eb sfond. Pse quhet pastrim n\u00eb sfond? Sepse merr si paramet\u00ebr numrin e faqeve q\u00eb t\u00eb heq\u00eb. Dhe, p\u00ebr shembull, heq N faqe. Dhe p\u00ebr nj\u00eb koh\u00eb t\u00eb caktuar kjo gj\u00eb b\u00ebn pushim. Pastaj kthehet dhe heq nj\u00eb sasi m\u00eb t\u00eb madhe faqeve. <\/p>\n
<\/p>\n
Kjo \u00ebsht\u00eb nj\u00eb histori shum\u00eb e thjesht\u00eb. K\u00ebtu ndodhemi si me nj\u00eb pishin\u00eb, ku n\u00eb nj\u00eb tub derdhet, n\u00eb tjetrin derdhet. Na ka ardhur nj\u00eb checkpoint dhe, n\u00ebse ka d\u00ebrguar pak faqe t\u00eb papastra p\u00ebr pastrim, at\u00ebher\u00eb gradualisht nga buffer-i i kernel-it pgflush do ta heq\u00eb k\u00ebt\u00eb ndihm\u00ebn e kujdesshme. <\/p>\n
<\/p>\n
N\u00ebse vazhdojn\u00eb t\u00eb grumbullohen k\u00ebto faqe t\u00eb papastra, ato grumbullohen deri n\u00eb 20%, pas s\u00eb cil\u00ebs prioritare p\u00ebr sistemin operativ \u00ebsht\u00eb q\u00eb ta heq\u00eb k\u00ebt\u00eb n\u00eb disk, sepse n\u00ebse ndalon energjia, do t\u00eb kemi probleme. Ne do t\u00eb humbasim k\u00ebto t\u00eb dh\u00ebna, p\u00ebr shembull. <\/p>\n
<\/p>\n
Cila \u00ebsht\u00eb strategjia? Strategjia \u00ebsht\u00eb se k\u00ebto parametra n\u00eb bot\u00ebn moderne, 20% dhe 10% nga e gjith\u00eb memoria q\u00eb ka makina, jan\u00eb t\u00eb tmerrshme n\u00eb aspektin e kapacitetit t\u00eb \u00e7do sistemi disk q\u00eb keni.<\/strong> <\/p>\n<\/p>\n
Imagjinoni se keni 128 GB RAM. 12,8 GB arrijn\u00eb n\u00eb sistemin tuaj t\u00eb diskut. Dhe \u00e7far\u00ebdo q\u00eb keni si cache, \u00e7far\u00ebdo array, ato nuk do ta mbajn\u00eb k\u00ebt\u00eb sasi. <\/p>\n
<\/p>\n
<\/p>\n
Prandaj ne rekomandojm\u00eb q\u00eb k\u00ebto numra t\u00eb konfigurohen menj\u00ebher\u00eb sipas mund\u00ebsive t\u00eb kontrollorit tuaj RAID.<\/strong> K\u00ebtu \u00ebsht\u00eb dh\u00ebn\u00eb nj\u00eb rekomandim p\u00ebr kontrollorin q\u00eb ka 512 MB cache. <\/p>\n<\/p>\n
T\u00eb gjith\u00eb e llogarisin shum\u00eb thjesht\u00eb. Mund ta vendosni vm.dirty_background n\u00eb byte. Dhe k\u00ebto konfigurime anullojn\u00eb dy t\u00eb parat. Ose ratio sipas parazgjedhjes, ose jan\u00eb aktivizuar ato q\u00eb jan\u00eb n\u00eb byte, at\u00ebher\u00eb do t\u00eb funksionojn\u00eb ato q\u00eb jan\u00eb n\u00eb byte. Por, sepse jam nj\u00eb konsulent DBA dhe punoj me klient\u00eb t\u00eb ndrysh\u00ebm, p\u00ebrpiqem t\u00eb mbaj gj\u00ebrat t\u00eb sigurta, prandaj, n\u00ebse \u00ebsht\u00eb n\u00eb byte, at\u00ebher\u00eb n\u00eb byte. Askush nuk dha asnj\u00eb garanci se nj\u00eb administrator i mir\u00eb nuk do t\u00eb shtoj\u00eb memorie n\u00eb server dhe nuk do ta rindez\u00eb at\u00eb, nd\u00ebrsa numri do t\u00eb mbetet i nj\u00ebjt\u00eb. Thjesht llogaritni k\u00ebta numra q\u00eb t\u00eb siguroheni se gjith\u00e7ka do t\u00eb hyj\u00eb atje. <\/p>\n
<\/p>\n
\u00c7far\u00eb do t\u00eb ndodh\u00eb n\u00ebse nuk do t\u00eb hyj\u00eb? Kam shkruar se \u00e7do flushing efektivisht ndalohet, por n\u00eb t\u00eb v\u00ebrtet\u00eb kjo \u00ebsht\u00eb nj\u00eb figur\u00eb e fjal\u00ebs. Sistemi operativ ka nj\u00eb problem t\u00eb madh \u2013 ka shum\u00eb faqe t\u00eb papastra, prandaj ndalohet efektivisht IO-t\u00eb q\u00eb krijojn\u00eb klient\u00ebt tuaj, dmth. aplikacioni q\u00eb ka d\u00ebrguar nj\u00eb k\u00ebrkes\u00eb SQL n\u00eb baz\u00eb, po pret. \u00c7do hyrje \u2013 dalje n\u00eb t\u00eb \u00ebsht\u00eb n\u00eb prioritetin m\u00eb t\u00eb ul\u00ebt, sepse baza \u00ebsht\u00eb e z\u00ebn\u00eb me checkpoint. Dhe kur do t\u00eb p\u00ebrfundoj\u00eb, nuk dihet. Dhe kur keni arritur deri n\u00eb flushing t\u00eb zakonsh\u00ebm, kjo do t\u00eb thot\u00eb se t\u00eb gjitha IO-t\u00eb jan\u00eb t\u00eb z\u00ebna me t\u00eb. Dhe derisa t\u00eb p\u00ebrfundoj\u00eb, nuk do t\u00eb b\u00ebni asgj\u00eb. <\/p>\n
<\/p>\n
K\u00ebtu jan\u00eb edhe dy pika t\u00eb r\u00ebnd\u00ebsishme q\u00eb dalin jasht\u00eb k\u00ebtij raporti. K\u00ebto konfigurime duhet t\u00eb p\u00ebrputhen me konfigurimet n\u00eb postgresql.conf, dmth. konfigurimet e checkpoints. Dhe sistemi juaj i disqeve duhet t\u00eb jet\u00eb i konfiguruar n\u00eb m\u00ebnyr\u00eb adekuate. N\u00ebse keni cache n\u00eb RAID, at\u00ebher\u00eb duhet t\u00eb ket\u00eb nj\u00eb bateri.<\/strong> Njer\u00ebzit blejn\u00eb RAID me cache t\u00eb mir\u00eb pa bateri. N\u00ebse keni SSD n\u00eb RAID, ato duhet t\u00eb jen\u00eb t\u00eb destinuara p\u00ebr server\u00eb dhe duhet t\u00eb ken\u00eb kondensator\u00eb.<\/strong> K\u00ebtu \u00ebsht\u00eb nj\u00eb list\u00eb e detajuar. N\u00eb k\u00ebt\u00eb link ndodhet raporti im n\u00eb lidhje me konfigurimin e performanc\u00ebs s\u00eb disqeve n\u00eb PostgreSQL. Atje jan\u00eb t\u00eb gjitha k\u00ebto lista kontrolle. <\/p>\n<\/p>\n
<\/p>\n
\u00c7far\u00eb tjet\u00ebr mund ta nd\u00ebrlikoj\u00eb shum\u00eb jet\u00eb? K\u00ebta jan\u00eb dy parametra. Ata jan\u00eb relativisht t\u00eb rinj. Mund t\u00eb jen\u00eb t\u00eb aktivizuar si parazgjedhje n\u00eb aplikacione t\u00eb ndryshme. Dhe ata mund t\u00eb nd\u00ebrlikojn\u00eb jet\u00ebn n\u00eb t\u00eb nj\u00ebjt\u00ebn mas\u00eb, n\u00ebse aktivizohen gabim. <\/p>\n
<\/p>\n
<\/p>\n
Ka dy gj\u00ebra relativisht t\u00eb reja. T\u00eb dy u shfaq\u00ebn n\u00eb b\u00ebrtham\u00ebn e tret\u00eb. Ky \u00ebsht\u00eb sched_migration_cost n\u00eb nanosekonda dhe sched_autogroup_enabled, i cili \u00ebsht\u00eb nj\u00eb n\u00eb parazgjedhje. <\/p>\n
<\/p>\n
Dhe si i prishin jet\u00ebn? \u00c7far\u00eb \u00ebsht\u00eb sched_migration_cost? Me planifikuesin Linux, nj\u00eb proces mund t\u00eb migrohet nga nj\u00eb CPU n\u00eb tjetrin. Dhe p\u00ebr PostgreSQL, q\u00eb ekzekuton k\u00ebrkesa, migrimi n\u00eb nj\u00eb CPU tjet\u00ebr \u00ebsht\u00eb komplet i paqart\u00eb. Nga k\u00ebndv\u00ebshtrimi i sistemit operativ, kur nd\u00ebrmerrni dritaret midis openoffice dhe terminalit, ndoshta \u00ebsht\u00eb e mir\u00eb, por p\u00ebr baz\u00ebn e t\u00eb dh\u00ebnave \u00ebsht\u00eb shum\u00eb e keqe.<\/strong> Prandaj, politika e arsyeshme \u00ebsht\u00eb t\u00eb vendosni migration_cost n\u00eb nj\u00eb vler\u00eb t\u00eb madhe, t\u00eb pakt\u00ebn disa mij\u00ebra nanosekonda.<\/strong> <\/p>\n<\/p>\n
\u00c7far\u00eb do t\u00eb thot\u00eb kjo p\u00ebr scheduler? Do t\u00eb mendoj\u00eb se gjat\u00eb k\u00ebtij koh\u00eb ky proces \u00ebsht\u00eb ende aktiv. Pra, n\u00ebse keni ndonj\u00eb transaksion t\u00eb gjat\u00eb q\u00eb merret me di\u00e7ka p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, scheduler do ta kuptoj\u00eb k\u00ebt\u00eb. Ai do t\u00eb mendoj\u00eb se derisa t\u00eb kaloj\u00eb kjo koh\u00eb skadimi, nuk ka nevoj\u00eb t\u00eb migroj\u00eb k\u00ebt\u00eb proces askund. N\u00ebse procesi po b\u00ebn di\u00e7ka, at\u00ebher\u00eb ai nuk do t\u00eb migrohet askund, ai do t\u00eb p\u00ebrfundoj\u00eb pa shqet\u00ebsim n\u00eb CPU-n\u00eb q\u00eb i \u00ebsht\u00eb alokuar. Dhe rezultati \u00ebsht\u00eb p\u00ebr ta \u00e7muar. <\/p>\n
<\/p>\n
Pika tjet\u00ebr \u00ebsht\u00eb autogroup. Ka nj\u00eb ide t\u00eb mir\u00eb p\u00ebr ngarkesa specifike q\u00eb nuk kan\u00eb lidhje me bazat e t\u00eb dh\u00ebnave moderne \u2013 grupimi i proceseve sipas terminalit virtual, nga i cili jan\u00eb nisur. Kjo \u00ebsht\u00eb e dobishme p\u00ebr disa detyra. N\u00eb praktik\u00eb, PostgreSQL \u00ebsht\u00eb nj\u00eb sistem me shum\u00eb procese me prefork, i cili niset nga nj\u00eb terminal. Ju keni lock writer, checkpoint dhe t\u00eb gjitha k\u00ebrkesat tuaja nga klient\u00ebt do t\u00eb grupohen n\u00eb nj\u00eb scheduler, n\u00eb nj\u00eb CPU. Aty do t\u00eb presin s\u00eb bashku, kur ai t\u00eb lirohet, q\u00eb t\u00eb mos e pengojn\u00eb nj\u00ebri-tjetrin dhe t\u00eb q\u00ebndrojn\u00eb atje sa m\u00eb gjat\u00eb. Kjo histori nuk \u00ebsht\u00eb aspak e nevojshme n\u00eb rast t\u00eb till\u00eb ngarkese dhe prandaj duhet t\u00eb \u00e7aktivizohet.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Kolegji im Aleksej Lesovski ka b\u00ebr\u00eb teste me pgbench t\u00eb thjesht\u00eb, ku rriti ndjesh\u00ebm migration_cost dhe \u00e7aktivizoi autogroup. Ndryshimi n\u00eb nj\u00eb harduer t\u00eb dob\u00ebt doli gati 10%.<\/strong>. Ka nj\u00eb diskutim n\u00eb list\u00ebn e postimeve t\u00eb postgres, ku njer\u00ebzit tregojn\u00eb rezultate se si k\u00ebto ndryshime kan\u00eb ndikuar n\u00eb shpejt\u00ebsin\u00eb e k\u00ebrkeseve. kan\u00eb ndikuar deri n\u00eb 50%.<\/strong>. Ka shum\u00eb histori t\u00eb tilla.<\/p>\n<\/p>\n
<\/p>\n
Dhe p\u00ebrfundimisht lidhur me politik\u00ebn e kursimit t\u00eb energjis\u00eb. Mir\u00eb \u00ebsht\u00eb q\u00eb tani Linux mund t\u00eb p\u00ebrdoret n\u00eb laptop. Dhe ai do t\u00eb konsumonte n\u00eb dukje mir\u00eb baterin\u00eb. Por papritur del se kjo mund t\u00eb ndodhi edhe n\u00eb server. <\/p>\n
<\/p>\n
P\u00ebr m\u00eb tep\u00ebr, n\u00ebse merrni server\u00eb me qira nga ndonj\u00eb host, at\u00ebher\u00eb 't\u00eb mir\u00ebt' hostuese<\/a> nuk e kujdesen q\u00eb ju t\u00eb keni performanc\u00eb m\u00eb t\u00eb mir\u00eb. Detyra e tyre \u00ebsht\u00eb t\u00eb sigurojn\u00eb q\u00eb hardueri t\u00eb p\u00ebrdoret maksimumi n\u00eb m\u00ebnyr\u00eb efikase. Prandaj ata mund t\u00eb aktivizojn\u00eb si parazgjedhje modalitetin e kursimit t\u00eb energjis\u00eb t\u00eb laptopit n\u00eb sistemin operativ.<\/p>\n<\/p>\n
N\u00ebse p\u00ebrdorni n\u00eb nj\u00eb server me baz\u00ebn e t\u00eb dh\u00ebnave n\u00ebn ngarkes\u00eb intensive k\u00ebt\u00eb mund, at\u00ebher\u00eb zgjedhja juaj \u00ebsht\u00eb acpi_cpufreq + performance. Edhe me ondemand do t\u00eb keni probleme.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u00ebsht\u00eb nj\u00eb drejtues pak m\u00eb ndryshe. Dhe tani preferohet ky, si nj\u00eb m\u00eb i vonsh\u00ebm dhe m\u00eb mir\u00eb funksionues.<\/p>\n
<\/p>\n
Dhe, p\u00ebrkat\u00ebsisht, guvernatori vet\u00ebm performance. Ondemand, powersave dhe t\u00eb tjera \u2013 nuk jan\u00eb p\u00ebr ju. <\/p>\n
<\/p>\n
Rezultatet nga explain analyze PostgreSQL mund t\u00eb ndryshojn\u00eb me disa rend mjeshtrive, n\u00ebse aktivizoni powersave, sepse praktikisht CPU-t\u00eb do t\u00eb programohen n\u00eb nj\u00eb m\u00ebnyr\u00eb krejt t\u00eb paparashikueshme.<\/p>\n
<\/p>\n
K\u00ebto gj\u00ebra mund t\u00eb jen\u00eb t\u00eb aktivizuara si parazgjedhje. Shikoni me kujdes \u2013 a jan\u00eb aktivizuar automatikisht. Kjo mund t\u00eb jet\u00eb nj\u00eb problem i v\u00ebrtet\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Dhe n\u00eb fund doja t\u00eb falenderoja djemt\u00eb nga ekipi yn\u00eb DBA i PosgreSQL-Consulting, ve\u00e7an\u00ebrisht Maksim Boguk dhe Aleksej Lesovski, t\u00eb cil\u00ebt \u00e7do dit\u00eb d\u00ebshmojn\u00eb k\u00ebt\u00eb \u00e7\u00ebshtje. Dhe p\u00ebr klient\u00ebt tan\u00eb p\u00ebrpiqemi t\u00eb b\u00ebjm\u00eb sa m\u00eb mir\u00eb q\u00eb ata t\u00eb funksionojn\u00eb. Kjo \u00ebsht\u00eb si me udh\u00ebzimet p\u00ebr sigurin\u00eb n\u00eb aviacion. K\u00ebtu gjith\u00e7ka \u00ebsht\u00eb shkruar me gjak. \u00c7do kap\u00ebse e k\u00ebtyre \u00ebsht\u00eb zbuluar n\u00eb procesin e ndonj\u00eb problemi. Un\u00eb me k\u00ebnaq\u00ebsi ndaja ato me ju.<\/p>\n
<\/p>\n
Pyetje:<\/p>\n
<\/p>\n
Faleminderit! N\u00ebse, p\u00ebr shembull, nj\u00eb kompani d\u00ebshiron t\u00eb kursej\u00eb dhe t\u00eb vendos\u00eb baz\u00ebn e t\u00eb dh\u00ebnave dhe logjik\u00ebn e aplikacionit n\u00eb nj\u00eb server t\u00eb vet\u00ebm, ose n\u00ebse kompania ndjek tendenc\u00ebn bashk\u00ebkohore t\u00eb arkitekturave me mikrosh\u00ebrbime, ku PostgreSQL ekzekutohet n\u00eb nj\u00eb kontejner. \u00c7far\u00eb \u00ebsht\u00eb k\u00ebtu? Sysctl-ka globalisht ndikon n\u00eb t\u00eb gjith\u00eb b\u00ebrtham\u00ebn. Nuk kam d\u00ebgjuar q\u00eb sysctl jan\u00eb virtualizuar ndonj\u00ebher\u00eb, q\u00eb ata t\u00eb funksiononin ve\u00e7mas n\u00eb kontejner. Ka vet\u00ebm cgroup dhe aty ka vet\u00ebm nj\u00eb pjes\u00eb t\u00eb kontrollit. Si mund t\u00eb jetoni me k\u00ebt\u00eb? Ose n\u00ebse d\u00ebshironi performanc\u00eb, at\u00ebher\u00eb ekzekutoni PostgreSQL n\u00eb nj\u00eb server t\u00eb dedikuar dhe b\u00ebjeni at\u00eb t\u00eb optimizuar?<\/em><\/p>\n<\/p>\n
Ne i kemi p\u00ebrgjigjur pyetjes tuaj n\u00eb m\u00ebnyr\u00eb t\u00eb p\u00ebraf\u00ebrt n\u00eb tre m\u00ebnyra. N\u00ebse nuk b\u00ebhet fjal\u00eb p\u00ebr nj\u00eb server t\u00eb dedikuar, q\u00eb mund t\u00eb optimizohet etj., at\u00ebher\u00eb relaksohuni, gjith\u00e7ka do t\u00eb funksionoj\u00eb mir\u00eb pa k\u00ebto caktime. N\u00ebse keni nj\u00eb ngarkes\u00eb t\u00eb till\u00eb q\u00eb duhet t\u00eb b\u00ebni k\u00ebto caktime, at\u00ebher\u00eb ju do t\u00eb kaloni m\u00eb par\u00eb te serveri i dedikuar sesa te ato caktime.<\/p>\n
<\/p>\n
Cila \u00ebsht\u00eb problemi? N\u00ebse kjo \u00ebsht\u00eb nj\u00eb virtualk\u00eb, at\u00ebher\u00eb, p\u00ebr shum\u00eb mund\u00ebsi, do t\u00eb keni shum\u00eb probleme, p\u00ebr shembull, me at\u00eb q\u00eb n\u00eb shumic\u00ebn e virtualkave ka nj\u00eb latency mjaft t\u00eb pamjaftueshme t\u00eb diskut. Edhe n\u00ebse kapaciteti i disqeve \u00ebsht\u00eb i mir\u00eb, nj\u00eb transaksion me probleme operacioni I\/O, i cili nuk ndikon shum\u00eb n\u00eb kapacitetin mesatar, ndodhi n\u00eb momentin e checkpoint-it ose n\u00eb momentin e shkruar n\u00eb WAL, at\u00ebher\u00eb baza do t\u00eb vuaje shum\u00eb nga kjo. Dhe ju do ta v\u00ebreni k\u00ebt\u00eb m\u00eb par\u00eb se do t\u00eb ashp\u00ebrsoheni n\u00eb k\u00ebto probleme. <\/p>\n
<\/p>\n
N\u00ebse keni NGINX n\u00eb t\u00eb nj\u00ebjtin server, do t\u00eb keni t\u00eb nj\u00ebjtin problem. Ai do t\u00eb luftoj\u00eb p\u00ebr memorien e p\u00ebrbashk\u00ebt. Dhe nuk do t\u00eb arrini n\u00eb problemet q\u00eb p\u00ebrshkruhen k\u00ebtu.<\/p>\n
<\/p>\n
Por nga ana tjet\u00ebr, disa nga k\u00ebta parametra megjithat\u00eb do t\u00eb jen\u00eb t\u00eb r\u00ebnd\u00ebsish\u00ebm p\u00ebr ju. P\u00ebr shembull, vendosni dirty_ratio me sysctl, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos jet\u00eb kaq ekstrem \u2013 n\u00eb \u00e7do rast do t\u00eb ndihmoj\u00eb. Pavar\u00ebsisht, do t\u00eb keni nd\u00ebrveprim me diskun. Dhe do t\u00eb ndodh\u00eb me nj\u00eb skem\u00eb t\u00eb gabuar. K\u00ebto jan\u00eb cil\u00ebsimet standarde q\u00eb tregova. Dhe n\u00eb \u00e7do rast \u00ebsht\u00eb m\u00eb mir\u00eb t'i modificoni. <\/p>\n
<\/p>\n
Me NUMA mund t\u00eb ket\u00eb probleme. VmWare, p\u00ebr shembull, funksionon mir\u00eb me NUMA me cil\u00ebsimet e kund\u00ebrta. Dhe k\u00ebtu duhet t\u00eb zgjidhni \u2013 server t\u00eb \u00e7elikt\u00eb ose jo. <\/p>\n
<\/p>\n
Kam nj\u00eb pyetje lidhur me Amazon AWS. Ata kan\u00eb imazhe t\u00eb parakonfiguruara. Nj\u00eb prej tyre quhet Amazon RDS. A ka ndonj\u00eb cil\u00ebsim t\u00eb personalizuar p\u00ebr sistemin e tyre operativ?<\/em><\/p>\n<\/p>\n
Aty ka cil\u00ebsime, por \u00ebsht\u00eb nj\u00eb set tjet\u00ebr cil\u00ebsimesh. K\u00ebtu ne konfigurojm\u00eb sistemin operativ nga pik\u00ebpamja se si do ta p\u00ebrdor\u00eb databaza. Dmth, ne kemi nevoj\u00eb p\u00ebr kaq shum\u00eb resurse, dhe tani do t'i konsumojm\u00eb ato. Pas k\u00ebsaj, Amazon RDS u merr k\u00ebto resurse, dhe atje performanca bie. Ka histori t\u00eb ve\u00e7anta se si njer\u00ebzit fillojn\u00eb t\u00eb manipulojn\u00eb me k\u00ebt\u00eb. Disa her\u00eb mjaft me sukses. Por kjo nuk ka lidhje me cil\u00ebsimet e OS. Kjo \u00ebsht\u00eb n\u00eb nj\u00ebfar\u00eb m\u00ebnyre hacking i cloud-it. Kjo \u00ebsht\u00eb nj\u00eb histori tjet\u00ebr.<\/p>\n
<\/p>\n
Pse Transparent huge pages nuk japin efektin e krahasuar me Huge TLB?<\/em><\/p>\n<\/p>\n
Nuk japin. Kjo mund t\u00eb shpjegohet n\u00eb shum\u00eb m\u00ebnyra. Por n\u00eb fakt, ata thjesht nuk e ofrojn\u00eb. Cila \u00ebsht\u00eb historia me PostgreSQL? Ai rezervon nj\u00eb pjes\u00eb t\u00eb madhe t\u00eb memories s\u00eb p\u00ebrbashk\u00ebt n\u00eb nisje. Transparent apo jo Transparent \u2013 nuk ka r\u00ebnd\u00ebsi fare. Fakti se ata rezervohen n\u00eb nisje shpjegon gjith\u00e7ka. Dhe n\u00ebse ka shum\u00eb memorie dhe \u00ebsht\u00eb e nevojshme t\u00eb ri-strukturohet segmenti i shared_memory, at\u00ebher\u00eb Transparent huge pages do t\u00eb ishin t\u00eb r\u00ebnd\u00ebsishme. Tek PostgreSQL, ai \u00ebsht\u00eb rezervuar thjesht si nj\u00eb cop\u00eb e madhe n\u00eb fillim dhe asgj\u00eb e ve\u00e7ant\u00eb nuk ndodh m\u00eb tej. Sigurisht, mund t\u00eb p\u00ebrdoret, por ka mund\u00ebsin\u00eb e marrjes s\u00eb korrupsionit t\u00eb shared_memory, kur ai do t\u00eb ri-rezervohet di\u00e7ka. PostgreSQL nuk e di k\u00ebt\u00eb.<\/p>\n
Burimi: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Rregullimi](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n