Pravi pristup je potpuno isklju\u010diti NUMA<\/strong>, na primjer, pri ponovnom pokretanju. U ve\u0107ini slu\u010dajeva dobitak je toliko velik da se ne postavlja pitanje koja je bolja opcija. <\/p>\n<\/p>\n
Postoji jo\u0161 jedna opcija. Otu\u017eni smo je vi\u0161e nego prvu, jer kada nam klijent do\u0111e na podr\u0161ku, ponovno pokretanje servera za njega je veliki posao. Njegov poslovanje se odvija. A problemi zbog NUMA su im poznati. Stoga se trudimo isklju\u010diti je manje invazivnim na\u010dinima, nego rebootom, ali ovdje budite pa\u017eljivi i provjerite da je zaista isklju\u010dena. Jer, kako iskustvo pokazuje, kada isklju\u010dujemo NUMA na roditeljskom procesu PostgreSQL-a, to je dobro, ali to nije nu\u017eno jamstvo da \u0107e to funkcionirati. Mora se provjeriti i vidjeti da je zaista isklju\u010dena. <\/p>\n
<\/p>\n
Post koji je napisao Robert Haas je izvrstan. On je jedan od committera PostgreSQL-a. Klju\u010dni je developer svih niskonivoznih elemenata. I ako se pro\u0111e kroz linkove u ovom postu, opisane su neke zanimljive pri\u010de o tome kako su ljudima NUMA ote\u017eavali \u017eivot. Pogledajte, prou\u010dite popis koji treba postaviti na serveru kako bi na\u0161a baza podataka dobro radila. Ove postavke treba zabilje\u017eiti i provjeravati, jer u suprotnom ne\u0107e biti dobro. <\/p>\n
<\/p>\n
Skre\u0107em pa\u017enju da se ovo odnosi na sve postavke o kojima \u0107u govoriti. Obi\u010dno se baze podataka organiziraju u na\u010dinu master-slave radi otpornosti na kvarove. Ne zaboravite unijeti ove postavke na slave, jer \u0107e u jednom trenutku do\u0107i do kvara, a vi \u0107ete se prebaciti na slave koji \u0107e postati master. <\/p>\n
<\/p>\n
U hitnoj situaciji, kada je stanje kriti\u010dno, kada vam neprestano zvoni telefon i kada \u0161ef dolazi s velikom palicom, ne\u0107ete imati vremena razmi\u0161ljati o provjeri. A rezultati mogu biti vrlo nepovoljni.<\/p>\n
<\/p>\n
<\/p>\n
Sljede\u0107a tema su huge pages. Te\u017ee ih je testirati posebno, a ni nema smisla to raditi, iako postoje benchmarkovi koji to mogu. Lako se nalaze na internetu. <\/p>\n
<\/p>\n
Koji je smisao? Imate server koji nije preskup a sadr\u017ei puno radne memorije, na primjer, vi\u0161e od 30 GB. Ne koristite huge pages. To zna\u010di da imate jasno preoptere\u0107enje u kori\u0161tenju memorije. A to preoptere\u0107enje nije nimalo ugodno. <\/p>\n
<\/p>\n
<\/p>\n
Za\u0161to je to tako? \u0160to se doga\u0111a? Operativni sustav se sje\u0107a memorije u malim dijelovima. To je zgodno, tako je historijski zapo\u010delo. Ako u\u0111emo u detalje, OS mora pretvarati virtualne adrese u fizi\u010dke. I to nije najjednostavniji proces, stoga OS rezultat te operacije pohranjuje u Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
I s obzirom na to da je TLB cache, u toj situaciji nastaju svi problemi koje cache ima. Prvo, ako imate jako puno radne memorije koja je podijeljena u sitne dijelove, taj buffer postaje jako velik. A ako je cache velik, pretra\u017eivanje postaje sporije. Preoptere\u0107enje je zna\u010dajno i ono samo zauzima prostor, tj. ne\u0161to neprikladno koristi radnu memoriju. <\/p>\n
<\/p>\n
Dva \u2013 \u0161to vi\u0161e cache raste u takvoj situaciji, to je ve\u0107a vjerojatnost da \u0107ete imati cache misses. I u\u010dinkovitost ovog cachea brzo pada s raste\u0107om veli\u010dinom. Stoga su operativni sustavi smislili jednostavan pristup. U Linuxu se to ve\u0107 dugo koristi. U FreeBSD-u se nedavno pojavilo. Ali govorimo o Linuxu. To su huge pages.<\/p>\n
<\/p>\n
I ovdje treba napomenuti da su huge pages, kao ideja, prvotno promovirali zajednice koje su uklju\u010divale Oracle i IBM, tj. proizvo\u0111a\u010di baza podataka su ozbiljno razmi\u0161ljali o tome kako \u0107e ovo koristiti, uklju\u010duju\u0107i baze podataka. <\/p>\n
<\/p>\n
<\/p>\n
Kako to povezati s PostgreSQL-om? Prvo, u Linux jezgru moraju biti uklju\u010dene huge pages.<\/p>\n
<\/p>\n
Drugo, moraju biti izri\u010dito navedene sysctl parametrom \u2013 koliko ih ima. Brojevi ovdje dolaze s nekog starog servera. Mo\u017eete izra\u010dunati koliko vam otprilike treba shared buffers kako bi huge pages stale unutra. <\/p>\n
<\/p>\n
I ako je cijeli server dodijeljen PostgreSQL-u, dobra polazna to\u010dka je ili 25 % RAM-a dodijeliti za shared buffers, ili 75 %, ako ste sigurni da \u0107e va\u0161a baza podataka sigurno stati u tih 75 %. Ovo je prva polazna to\u010dka. I izra\u010dunajte, ako imate 256 GB RAM-a, tada \u0107e vam otprilike 64 GB biti za shared buffers. Izra\u010dunajte s nekim marginama \u2013 koliko bi ta brojka trebala biti.<\/p>\n
<\/p>\n
Do verzije 9.2 (ako se ne varam, od verzije 8.2) mogla se koristiti vanjska biblioteka za povezivanje PostgreSQL-a s huge pages. A to se uvijek treba raditi. Prvo, trebate da jezgro ispravno alocira huge pages. A drugo, aplikacija koja radi s njima mora mo\u0107i iskoristiti te strane. Samo tako ne\u0107e mo\u0107i. Budu\u0107i da je PostgreSQL alocirao memoriju u stilu system 5, to se moglo u\u010diniti pomo\u0107u libhugetlbfs \u2014 to je potpuno ime biblioteke.<\/p>\n
<\/p>\n
U verziji 9.3 pobolj\u0161ana je izvedba PostgreSQL pri upravljanju memorijom i odustalo se od system 5 metode alokacije memorije. Svi su se jako obradovali, jer, ina\u010de, kada poku\u0161ate pokrenuti dva instanca PostgreSQL na jednoj ma\u0161ini, on ka\u017ee da mu nedostaje \u0161erirane memorije. I zahtijeva da se ispravi sysctl. A taj sysctl je takav da treba ponovo pokrenuti sistem i tako dalje. Uglavnom, svi su se obradovali. No, alokacija memorije preko mmap-a je pokvarila kori\u0161tenje ogromnih stranica. Ve\u0107ina na\u0161ih klijenata koristi velike \u0161erirane baferove. I sna\u017eno smo preporu\u010dili da se ne prelazi na 9.3, jer je tamo overhead po\u010dinjao u dobrim postotcima biti zna\u010dajan.<\/p>\n
<\/p>\n
Ali, zajednica je obratila pa\u017enju na ovaj problem i u 9.4 su vrlo dobro preradili ovo rje\u0161enje. I u 9.4 je uvedena opcija u postgresql.conf, gdje se mo\u017ee uklju\u010diti try, on ili off.<\/p>\n
<\/p>\n
Try je najbezbednija opcija. Prilikom pokretanja PostgreSQL-a, kada alocira \u0161eriranu memoriju, poku\u0161ava da dobije tu memoriju iz ogromnih stranica. I ako ne uspe, vra\u0107a se na uobi\u010dajenu alokaciju. I ako koristite FreeBSD ili Solaris, mo\u017eete postaviti try, to je uvek sigurno. <\/p>\n
<\/p>\n
Ako je on, jednostavno se ne pokre\u0107e ako nije uspeo da alocira iz ogromnih stranica. Ovo je ve\u0107 isklju\u010divo stvar izbora. Ali ako imate try, proverite da li ste zaista alocirali ono \u0161to vam treba, jer postoji puno prostora za gre\u0161ke. Trenutno, ova funkcionalnost radi samo na Linuxu.<\/p>\n
<\/p>\n
Jo\u0161 jedna mala napomena pre nego \u0161to pre\u0111emo dalje. Transparentne ogromne stranice jo\u0161 uvek nisu u PostgreSQL-u. Ne mo\u017ee ih pravilno iskoristiti. I pri transparentnim ogromnim stranicama, u situacijama gde je potreban veliki deo \u0161erirane memorije, prednosti se javljaju samo pri veoma velikim koli\u010dinama. Ako imate terabajte memorije, tada to mo\u017ee igrati ulogu. Kada govorimo o uobi\u010dajenim primenama, kada imate 32, 64, 128, 256 GB memorije na ma\u0161ini, tada su obi\u010dne ogromne stranice u redu, a transparentne jednostavno isklju\u010dujemo. <\/p>\n
<\/p>\n
<\/p>\n
I zadnja stvar koja se ti\u010de memorije, nije direktno povezana sa propusno\u0161\u0107u, ali mo\u017ee jako zakomplikovati \u017eivot. Cela propusnost \u0107e jako stradati zbog toga \u0161to server stalno prelazi u swap. <\/p>\n
<\/p>\n
I to \u0107e biti vrlo neugodno u nizu situacija. Glavna neugodnost le\u017ei u tome \u0161to se pona\u0161anje modernih jezgri malo razlikuje od starijih Linux jezgri. Ovo je ne\u0161to na \u0161to je neugodno naletjeti, jer kada govorimo o radu sa swapom, zavr\u0161ava to s nepravovremenim dolaskom OOM-killera. A OOM-killer koji nije stigao na vrijeme i skinuo PostgreSQL, to je neprijatno. O tome \u0107e svi saznati, tj. do posljednjeg korisnika. <\/p>\n
<\/p>\n
<\/p>\n
\u0160to se doga\u0111a? Imate puno RAM-a, sve dobro funkcionira. No, iz nekog razloga, server se zamrzava u swapu i time usporava. Naizgled, ima dovoljno memorije, ali tako se doga\u0111a. <\/p>\n
<\/p>\n
<\/p>\n
Ranije smo savjetovali da se vm.swappiness postavi na nulu, tj. da se isklju\u010di swap. Nekada se smatralo da 32 GB RAM-a i odgovaraju\u0107i shared bufferi predstavljaju ogromnu koli\u010dinu. Osnovna svrha swap-a je da bude mjesto gdje mo\u017eete smjestiti koru ako ispadnete. No, to vi\u0161e nije bila posebno ostvarena svrha. A \u0161to \u0107ete kasnije napraviti s tom korom? To postaje pitanje koje ne obja\u0161njava jasno za\u0161to je swap uop\u0107e potreban, pogotovo u toj veli\u010dini. <\/p>\n
<\/p>\n
No, u modernijim, tj. tre\u0107im verzijama jezgri, pona\u0161anje se promijenilo. Ako isklju\u010dite swap, tj. postavite ga na nulu, pre ili kasnije, \u010dak i uz preostalu koli\u010dinu RAM-a, OOM-killer \u0107e do\u0107i da ubije najintenzivnije potro\u0161a\u010de. Jer \u0107e smatrati da uz takvo optere\u0107enje imamo jo\u0161 malo raspolo\u017eive memorije i da \u0107emo pasti, tj. ne\u0107e ubiti sistemski proces, ve\u0107 ne\u0161to manje va\u017eno. To \u0107e manje va\u017eno biti intenzivni potro\u0161a\u010d shared memorije, to jest postmaster. Nakon toga, bit \u0107e dobro ako bazu ne\u0107ete morati obnavljati. <\/p>\n
<\/p>\n
Zato sada, koliko se sje\u0107am, ve\u0107ina distribucija postavlja podrazumijevano na oko 6, tj. u kojem trenutku po\u010deti koristiti swap ovisno o tome koliko je memorije preostalo. Sada savjetujemo da se postavi vm.swappiness = 1, jer to prakti\u010dki isklju\u010duje swap, ali ne dovodi do takvih efekata kao s nepredvi\u0111enim dolaskom OOM-killera koji sve to ubija.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
\u0160to dalje? Kada govorimo o performansama baza podataka i polako se pribli\u017eavamo diskovima, svi se hvataju za glavu. Jer istina da je disk spor, a memorija brza, svima je poznata od malih nogu. Svi znaju da \u0107e u bazi podataka biti problema s diskovnom performansom.<\/p>\n
<\/p>\n
Glavni problem s performansama PostgreSQL, povezan s uzletima checkpoints-a, ne nastaje zbog sporosti diska. Umjesto toga, dolazi do nerazmjernosti izme\u0111u propusnosti memorije i diska. Ova nerazmjernost mo\u017ee se javljati na razli\u010ditim mjestima. PostgreSQL nije pravilno pode\u0161en, operativni sustav nije pode\u0161en, hardver nije postavljen i hardver nije ispravan. Ovaj problem se ne javlja samo kada se sve odvija ispravno, tj. ili nema optere\u0107enja, ili su postavke i hardver dobro odabrani. <\/p>\n
<\/p>\n
<\/p>\n
\u0160to je to i kako to izgleda? Obi\u010dno, ljudi koji rade s PostgreSQL-om vi\u0161e puta su se suo\u010dili s tim problemom. Objasnit \u0107u. Kao \u0161to sam rekao, PostgreSQL povremeno pravi checkpoints kako bi prljave stranice u zajedni\u010dkoj memoriji prenio na disk. Ako imamo veliki kapacitet zajedni\u010dke memorije, checkpoint po\u010dinje intenzivno utjecati na disk, jer zapisuje te stranice putem fsync-a. Dolazi u kernel buffer i zapisuje se na diskove uz pomo\u0107 fsync-a. I ako je kapacitet ovog procesa velik, mo\u017eemo primijetiti neugodan u\u010dinak, to jest, vrlo visoku iskori\u0161tenost diskova.<\/p>\n
<\/p>\n
Ovdje imam dvije slike. Sada \u0107u objasniti \u0161to je to. To su dva vremenski korelirana grafikona. Prvi grafikon prikazuje diskovnu iskori\u0161tenost. Ovdje dose\u017ee gotovo 90% u tom trenutku. Ako imate optere\u0107enje baze podataka s fizi\u010dkim diskovima, s RAID kontrolerom, i iskori\u0161tenost je pod 90%, to su lo\u0161e vijesti. To zna\u010di da \u0107e uskoro do\u0107i do 100% i ulaz-izlaz \u0107e se zaustaviti. <\/p>\n
<\/p>\n
Ako imate diskovni niz, tada je pri\u010da malo druga\u010dija. Ovisi o tome kako je pode\u0161en, o kojoj se vrsti niza radi itd. <\/p>\n
<\/p>\n
A ovdje je paralelno konfiguriran grafikon iz unutarnje postgresove prikaze koja pokazuje kako se odvija checkpoint. I zelenom bojom ovdje je prikazano koliko je buffera, ovih prljavih stranica, u tom trenutku stiglo u ovaj checkpoint za sinkronizaciju. To je najva\u017enije \u0161to ovdje trebate znati. Vidimo da imamo mnogo stranica koje su stigle i u nekom trenutku naletjeli smo na ograni\u010denje, tj. pisanje je trajalo dugo, ovdje je o\u010dito diskovni sustav vrlo zauzet. I na\u0161 checkpoint sna\u017eno utje\u010de na disk. U idealnom slu\u010daju situacija bi trebala izgledati ovako, tj. manje pisanja bi se odvijalo ovdje. A mi to mo\u017eemo ispraviti postavkama kako bismo tako nastavili. Tj. mala iskori\u0161tenost, ali negdje ipak ne\u0161to pi\u0161emo. <\/p>\n
<\/p>\n
\u0160to trebate u\u010diniti kako biste pobijedili ovaj problem? Ako je IO pod bazom podataka stalo, to zna\u010di da \u0107e svi korisnici koji su do\u0161li izvr\u0161avati svoje upite \u010dekati. <\/p>\n
<\/p>\n
<\/p>\n
Ako pogledamo iz perspektive Linuxa, ako ste nabavili dobar hardver, pravilno ga konfigurirali i ispravno podesili PostgreSQL kako bi rje\u0111e radio ove checkpointove, \u0161ire\u0107i ih me\u0111usobno po vremenu, onda \u0107ete se na\u0107i u zadanim parametrima Debiana. Za ve\u0107inu Linux distribucija ovakva je slika: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
\u0160to to zna\u010di? S jezgre 2.6 pojavio se jedan demon za ispiranje. Pdglush ovisno o tome tko ga koristi, bavi se pozadinskim ispu\u0161tanjem prljavih stranica iz kernel buffera i ispu\u0161tanjem, kada god je to potrebno, prljavih stranica kada ve\u0107 pozadinsko ispu\u0161tanje ne poma\u017ee. <\/p>\n
<\/p>\n
Kada dolazi do pozadine? Kada je 10 % od cijelog operativnog pam\u0107enja koje je dostupno na serveru zauzeto prljavim stranicama u kernel buffera, poziva se posebna funkcija za ispu\u0161tanje u pozadini. Za\u0161to je ona pozadinska? Kao parametar prihva\u0107a koliko stranica ispu\u0161tati. I, recimo, ispu\u0161ta N stranica. Na neko vrijeme ta stvar zaspi. A onda se ponovno pojavljuje i ispu\u0161ta jo\u0161 odre\u0111eni broj stranica. <\/p>\n
<\/p>\n
Ovo je izuzetno jednostavna pri\u010da. Ovdje je zada\u0107a poput bazena, kada se u jednu cijev izlijeva, a u drugu ulijeva. Na\u0161 checkpoint je stigao i ako je poslao malo prljavih stranica na ispu\u0161tanje, postepeno \u0107e se iz kernel buffera pgflush sve to uredno razdvojiti. <\/p>\n
<\/p>\n
Ako se ove prljave stranice nastave nakupljati, nakupljat \u0107e se do 20%, a nakon toga \u0107e operativni sustav prioritizirati preslikavanje na disk, jer \u0107e do\u0107i do gubitka napajanja, a sve \u0107e biti lo\u0161e. Izgubit \u0107emo te podatke, primjerice. <\/p>\n
<\/p>\n
Koja je caka? Caka je u tome da su ovi parametri u modernom svijetu 20 i 10% od ukupne memorije koja postoji na ra\u010dunalu, jednostavno monstruozni s gledi\u0161ta propusnosti bilo kojeg diska koji imate.<\/strong> <\/p>\n<\/p>\n
Zamislite da imate 128 GB radne memorije. 12,8 GB dolazi u va\u0161 sustav za pohranu. I bez obzira na to kakav imate predmemorijski sustav ili polje, oni to ne\u0107e izdr\u017eati. <\/p>\n
<\/p>\n
<\/p>\n
Stoga preporu\u010dujemo odmah prilagoditi ove brojke prema mogu\u0107nostima va\u0161eg RAID kontrolera.<\/strong> Odmah imam preporuku za kontroler s 512 MB predmemorije. <\/p>\n<\/p>\n
Sve se vrlo jednostavno ra\u010duna. Mo\u017eete postaviti vm.dirty_background u bajtima. I ove postavke poni\u0161tavaju prethodne dvije. Bilo omjer prema zadanim postavkama ili aktivirani oni s bajtima, radit \u0107e oni s bajtima. Ali budu\u0107i da sam DBA konzultant i radim s razli\u010ditim klijentima, poku\u0161avam se osigurati, pa ako su u bajtima, neka budu u bajtima. Nitko nije dao nikakvo jamstvo da dobar administrator ne\u0107e dodati memoriju serveru, restartovati ga, a brojka \u0107e ostati ista. Samo izra\u010dunajte te brojke da sigurno sve stane unutra. <\/p>\n
<\/p>\n
\u0160to \u0107e se dogoditi ako ne stane? Imam zapisano da se bilo kakvo ispu\u0161tanje u\u010dinkovito zaustavlja, ali zapravo je to samo fraza. Operativni sustav ima veliki problem \u2013 ima mnogo prljavih stranica, stoga u\u010dinkovito se zaustavlja ono ulaz\/izlaz koje generiraju va\u0161i klijenti, tj. aplikacija koja je poslala sql upit prema bazi, \u010deka. Bilo koji ulaz\/izlaz u nju ima najni\u017ei prioritet, jer je baza zauzeta checkpointom. I kada \u0107e ga zavr\u0161iti nije jasno. Kada ste postigli ne pozadinsko ispu\u0161tanje, to zna\u010di da je sav IO zauzet njime. I dok se to ne zavr\u0161i, ne\u0107ete mo\u0107i ni\u0161ta u\u010diniti. <\/p>\n
<\/p>\n
Tamo su jo\u0161 dva va\u017ena trenutka koja nadma\u0161uju ovu prezentaciju. Ove postavke trebaju odgovarati postavkama u postgresql.conf, tj. postavkama checkpointa. A va\u0161 sustav za pohranu mora biti adekvatno konfiguriran. Ako imate cache na RAID-u, tada bi trebao imati bateriju.<\/strong> Ljudi kupuju RAID s dobrim cache-om bez baterije. Ako imate SSD u RAID-u, oni moraju biti serverni, trebali bi imati kondenzatore.<\/strong> Ovdje je op\u0161irna kontrolna lista. Na ovoj poveznici nalazi se moje izlaganje o tome kako pode\u0161avati performanse diska u PostgreSQL-u. Sve te kontrolne liste su tamo. <\/p>\n<\/p>\n
<\/p>\n
\u0160to jo\u0161 mo\u017ee ozbiljno zakomplicirati situaciju? To su dva parametra. Oni su relativno novi. Po defaultu mogu biti uklju\u010deni u razli\u010ditim aplikacijama. I mogu zakomplicirati \u017eivot jednako jako, ako su pogre\u0161no uklju\u010deni. <\/p>\n
<\/p>\n
<\/p>\n
Postoje dvije relativno nove stvari. Ve\u0107 su se pojavile u tre\u0107im jezgrama. To su sched_migration_cost u nanosekundama i sched_autogroup_enabled, koji je po defaultu samo jedan. <\/p>\n
<\/p>\n
Kako to kvare \u017eivot? \u0160to je sched_migration_cost? Linux scheduler mo\u017ee migrirati proces s jednog CPU-a na drugi. I za PostgreSQL, koji izvr\u0161ava upite, migracija na drugi CPU potpuno je nejasna. S stanovi\u0161ta operativnog sustava, kada prebacujete prozore izme\u0111u OpenOffice-a i terminala, to mo\u017ee biti dobro, ali<\/strong> za bazu podataka \u2013 to je vrlo lo\u0161e.<\/strong> <\/p>\n<\/p>\n
Zato je razumna politika postaviti migration_cost na neku visoku vrijednost, barem nekoliko tisu\u0107a nanosekundi. <\/p>\n
<\/p>\n
Druga stvar \u2013 to je autogroup. Postoji dobra ideja za specifi\u010dne radne optere\u0107enja, koja nisu vezana uz moderne baze podataka \u2013 to je grupiranje procesa prema virtualnom terminalu s kojeg su pokrenuti. To je prakti\u010dno za neke zadatke. U praksi, PostgreSQL je vi\u0161ekorisni\u010dka sistem s prefork arhitekturom, koji se pokre\u0107e iz jednog terminala. Imate lock writer, checkpoint, i svi va\u0161i klijentski zahtjevi bit \u0107e grupirani na jedan scheduler, na jedan CPU. I \u010dekat \u0107e zajedno da se oslobodi, ometaju\u0107i jedni druge i oduzimaju\u0107i mu vrijeme du\u017ee nego \u0161to bi trebali. To je situacija koja u slu\u010daju takvog optere\u0107enja nije potrebna i zato to treba isklju\u010diti.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Moj kolega Aleksej Lesovski radio je testove s jednostavnim pgbench, gdje je pove\u0107avao migracijski tro\u0161ak i isklju\u010divao autogroup. Razlika na slabom hardveru bila je skoro 10%.<\/strong>Postoji rasprava na postgres mailing listi gdje ljudi dijele rezultate kako su sli\u010dne promjene utjecale na brzinu zahtjeva. utjecale na 50%.<\/strong>Takvih pri\u010da ima prili\u010dno mnogo.<\/p>\n<\/p>\n
<\/p>\n
I na kraju, o politici \u0161tednje energije. Dobro je \u0161to sada Linux mo\u017eete koristiti na laptopu. I navodno \u0107e dobro tro\u0161iti bateriju. Ali iznenada se pokazuje da to mo\u017ee biti slu\u010daj i na serveru. <\/p>\n
<\/p>\n
\u0160tovi\u0161e, ako iznajmljujete server od nekog hostera, \u201edobri\u201c hosting<\/a> ne brinu o tome da va\u0161a performansa bude bolja. Njihov cilj je da iskoriste svoje hardverske resurse maksimalno efikasno. Stoga mogu u operativnom sistemu po defaultu uklju\u010diti laptop re\u017eim \u0161tednje energije.<\/p>\n<\/p>\n
Ako koristite na serveru s bazom podataka pod intenzivnim optere\u0107enjem ovu stvar, va\u0161 izbor je acpi_cpufreq + performance. \u010cak \u0107e ve\u0107 s ondemandom biti problema.<\/strong> <\/p>\n<\/p>\n
Intel_pstate je ve\u0107 malo druga\u010diji drajver. Sada se preferira ovaj, kao novijeg i efikasnijeg.<\/p>\n
<\/p>\n
I, sukladno tome, governor samo performance. Ondemand, powersave i sve drugo \u2013 to nije za vas. <\/p>\n
<\/p>\n
Rezultati prema explain analyze PostgreSQL mogu se razlikovati za nekoliko redoslijeda ako uklju\u010dite powersave, jer \u0107e CPU pod va\u0161om bazom biti raspore\u0111en na potpuno nepredvidiv na\u010din.<\/p>\n
<\/p>\n
Ove stvari mogu biti uklju\u010dene po defaultu. Pa\u017eljivo provjerite \u2013 nisu li uklju\u010dene po defaultu. To mo\u017ee biti zaista veliki problem. <\/p>\n
<\/p>\n
<\/p>\n
I na kraju \u017eelim zahvaliti ekipi iz na\u0161e DBA tima PosgreSQL-Consulting, a posebno Maksu Boguku i Alekseju Lesovskom, koji svaki dan sti\u010du iskustvo u ovom poslu. Poku\u0161avamo u\u010diniti sve najbolje za na\u0161e klijente kako bi im sve ovo radilo. To je poput uputa za sigurnost u aviotransportu. Sve je napisano krvlju. Svaki od ovih vijaka otkriven je tijekom nekog problema. S rado\u0161\u0107u ih dijelim s vama.<\/p>\n
<\/p>\n
Pitanja:<\/p>\n
<\/p>\n
Hvala! Ako, na primjer, tvrtka \u017eeli u\u0161tedjeti i na jednom serveru smjestiti bazu podataka i aplikacijsku logiku ili, ako tvrtka slijedi modnu tendenciju mikroservisnih arhitektura, u kojima se PostgreSQL pokre\u0107e u kontejneru. U \u010demu je stvar? Sysctl globalno utje\u010de na cijelo jezgro. Nisam \u010duo da se sysctl na neki na\u010din virtualiziraju kako bi radili odvojeno u kontejneru. Postoji samo cgroup i kontrola postoji samo za dio. Kako s tim \u017eivjeti? Ili ako \u017eelite performanse, pokrenite PostgreSQL na odvojenom fizi\u010dkom serveru i optimizirajte ga?<\/em><\/p>\n<\/p>\n
Na va\u0161e pitanje smo odgovorili na otprilike tri na\u010dina. Ako se radi o fizi\u010dkom serveru koji se mo\u017ee optimizirati itd., opustite se, sve \u0107e dobro raditi bez tih postavki. Ako dobijete optere\u0107enje koje zahtijeva ove postavke, do fizi\u010dkog servera \u0107ete do\u0107i prije nego do ovih postavki.<\/p>\n
<\/p>\n
Koji je problem? Ako je to virtualka, vjerojatno \u0107ete imati mnogo problema, na primjer, s tim da na ve\u0107ini virtualki postoji prili\u010dno neuskla\u0111eno ka\u0161njenje diska. \u010cak i ako je propusnost diskova dobra, jedna neuspje\u0161na transakcija operacije ulaza-izlaza, koja ne utje\u010de zna\u010dajno na prosje\u010dnu propusnost, koja se dogodila tijekom checkpointa ili zapisivanja u WAL, znatno \u0107e na\u0161tetiti bazi. I to \u0107ete primijetiti prije nego se suo\u010dite s tim problemima. <\/p>\n
<\/p>\n
Ako imate NGINX na istom serveru, imat \u0107ete isti problem. Borit \u0107e se za zajedni\u010dku memoriju. I do problema opisanih ovdje ne\u0107ete do\u0107i.<\/p>\n
<\/p>\n
No s druge strane, neki od ovih parametara \u0107e vam ipak biti relevantni. Na primjer, s sysctl postavite dirty_ratio kako ne bi bio prevelik \u2013 u svakom slu\u010daju, to \u0107e pomo\u0107i. Na ovaj ili onaj na\u010din, imat \u0107ete interakciju s diskom. I to \u0107e biti po pogre\u0161nom modelu. Ovo su u su\u0161tini defaultni parametri koje sam pokazao. I u svakom slu\u010daju, bolje ih je promijeniti. <\/p>\n
<\/p>\n
Mogu\u0107i su problemi s NUMA. VmWare, primjerice, dobro radi s NUMA s potpuno suprotnim postavkama. I ovdje treba birati \u2013 fizi\u010dki server ili ne. <\/p>\n
<\/p>\n
Imam pitanje vezano uz Amazon AWS. Imaju unaprijed konfigurirane slike. Jedna od njih zove se Amazon RDS. Ima li tamo nekih prilago\u0111enih postavki za njihov operativni sustav?<\/em><\/p>\n<\/p>\n
Ima postavki, ali to su druga\u010dije postavke. Ovdje konfiguriramo operativni sustav s obzirom na to kako \u0107e baza podataka to koristiti. A ondje postoje parametri koji odre\u0111uju kamo idemo, takvo oblikovanje. Dakle, trebamo toliko resursa, a sada \u0107emo ih tro\u0161iti. Nakon toga, Amazon RDS te resurse priklju\u010duje, i tu se performanse smanjuju. Ima pojedina\u010dnih pri\u010da o tome kako ljudi po\u010dinju s tim eksperimentirati. Ponekad \u010dak i prili\u010dno uspje\u0161no. No to nema veze s postavkama OS-a. To je kao hakiranje oblaka. To je druga pri\u010da.<\/p>\n
<\/p>\n
Za\u0161to Transparent huge pages ne daju u\u010dinak u usporedbi s Huge TLB?<\/em><\/p>\n<\/p>\n
Ne daju. Ovo se mo\u017ee objasniti na mnogo na\u010dina. No, zapravo, oni jednostavno ne daju taj u\u010dinak. Kakva je pri\u010da s PostgreSQL? On pri pokretanju dodjeljuje veliki dio zajedni\u010dke memorije. Transparent, ili ne transparent \u2013 potpuno je neva\u017eno. \u010cinjenica da se dodjeljuju pri pokretanju obja\u0161njava sve. I ako je memorije jako puno i treba rekonstruirati shared_memory segment, tada \u0107e Transparent huge pages biti relevantni. U PostgreSQL-u je on jednostavno tijekom pokretanja dodijeljen ogromnoj komadu i to je to, a dalje se ne doga\u0111a ni\u0161ta posebno. Naravno, mo\u017ee se koristiti, ali postoji rizik od curruption shared_memory, kada \u0107e ne\u0161to ponovo dodijeliti. PostgreSQL o tome ne zna.<\/p>\n
Izvor: 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
![\"Linux](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n