stre\u017enikom<\/a> i sve to na kraju ide na SATA hard disk bez bilo kakvog ke\u0161a, ceo server baze podataka ne postaje samo slabo, ve\u0107 postaje slabo sa SATA interfejsom. Onda \u0107ete se direktno suo\u010diti sa tim problemom i ni\u0161ta vas ne\u0107e spasiti.<\/p>\n<\/p>\n
<\/p>\n
\u0160to se ti\u010de prvog dela o memoriji, postoje tri stvari koje mogu uveliko ote\u017eati situaciju. <\/p>\n
<\/p>\n
Prva od njih jeste NUMA. NUMA je sistem napravljen radi pobolj\u0161anja performansi. U zavisnosti od optere\u0107enja, razli\u010dite stvari se mogu optimizovati. U svom trenutnom obliku nije ba\u0161 najbolja za aplikacije kao \u0161to su baze podataka, koje intenzivno koriste page cache i deljene baferne resurse. <\/p>\n
<\/p>\n
<\/p>\n
U nekoliko re\u010di. Kako znati da ne\u0161to nije u redu sa NUMA-om? Mo\u017eda imate neki neprijatan zvuk, iznenada jedan CPU postane preoptere\u0107en. Pri tome analizirate zahteve u PostgreSQL-u i ne vidite ni\u0161ta sli\u010dnog. Ti zahtevi ne bi trebali da konzumiraju CPU toliko intenzivno. Mo\u017ee potrajati dugo da to uhvatite. Lak\u0161e je odmah po\u0161tovati ispravnu preporuku kako konfigurisati NUMA za PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
\u0160ta se zapravo de\u0161ava? NUMA je Non-Uniform Memory Access. U \u010demu je stvar? Imate CPU, pored njega je njegova lokalna memorija. Ta memorija mo\u017ee pristupiti memoriji drugih CPU-a putem interkonekcija.<\/p>\n
<\/p>\n
Ako pokrenete numactl --hardware<\/code>, dobi\u0107ete veliku stanicu. Me\u0111u ostalim, tu \u0107e biti polje razdaljina. Bi\u0107e cifara \u2013 10-20, ne\u0161to u tom smislu. Te cifre su ni\u0161ta drugo do broj hopova potrebnih da bi se ta udaljena memorija povezala i koristila lokalno. U osnovi, dobra ideja. To poma\u017ee u ubrzavanju performansi pod odre\u0111enim optere\u0107enjima.<\/p>\n<\/p>\n
Zdaj si predstavljajte, da ima\u0161 en CPU, ki najprej posku\u0161a uporabiti svojo lokalno pomnilnik, nato pa posku\u0161a po interconnectu pritegniti drugo pomnilnik za kaj. In na ta CPU pride celoten va\u0161 page cache PostgreSQL \u2013 vse, kar ima nekaj gigabajtov. Vedno dobite najslab\u0161i scenarij, ker na CPU-ju v tem modulu pomnilnika obi\u010dajno ni veliko. In vsa pomnilnika, ki se upravlja, prehaja skozi te interconnects. To je po\u010dasi in \u017ealostno. In imate procesor, ki nenehno obremenjuje ta vozel. In \u010das dostopa do tega pomnilnika je slab, po\u010dasen. To je situacija, ki je ne \u017eelite, \u010de to uporabljate za bazo podatkov. <\/p>\n
<\/p>\n
Zato je bolj pravilna izbira za bazo podatkov, da operacijski sistem Linux sploh ne ve, kaj se dogaja. Da se obravnava pomnilnik, kot se obravnava. <\/p>\n
<\/p>\n
Zakaj tako? Zdi se, da bi moralo biti obratno. Do tega prihaja iz enostavnega razloga, da potrebujemo veliko pomnilnika za page cache \u2013 desetine, sto gigabajtov. <\/p>\n
<\/p>\n
In \u010de smo to vse dodelili in zakasnili na\u0161e podatke tam, bo pridobitev od uporabe cache-a bistveno ve\u010dja kot pridobitev od takega pametnega dostopa do pomnilnika. Tako bomo na ta na\u010din pridobili nesorazmerno v primerjavi s tem, da bomo u\u010dinkoviteje dostopali do pomnilnika z uporabo NUMA.<\/p>\n
<\/p>\n
Zato sta do sedaj dva pristopa, dokler ne pride svetla prihodnost, ko baza podatkov ne more sama ugotoviti, na katerih CPU-jih deluje in od kje naj potegne. <\/p>\n
<\/p>\n
<\/p>\n
Zato je pravi pristop popolnoma onemogo\u010diti NUMA<\/strong>, na primer, ob ponovnem zagonu. V ve\u010dini primerov so prihranki tako veliki, da vpra\u0161anje, kaj je bolje, sploh ne nastane. <\/p>\n<\/p>\n
Obstaja \u0161e en na\u010din. Pogosteje ga uporabljamo kot prvega, ker ko nam stranka pride na podporo, je ponovno zagon stre\u017enika za njih velik dogodek. Imajo tam razpeto poslovanje. In te\u017eave zaradi NUMA do\u017eivljajo. Zato se trudimo onemogo\u010diti na manj invazivne na\u010dine kot ponovno zagon, vendar tukaj previdno preverite, da je onemogo\u010deno. Ker, kot ka\u017ee izku\u0161nja, onemogo\u010dimo NUMA star\u0161evskega procesa PostgreSQL, kar je dobro, vendar ni nujno, da deluje. Potrebno je preveriti in videti, da se dejansko onemogo\u010dilo. <\/p>\n
<\/p>\n
Obstaja dober \u010dlanek Roberta Haasa. Je eden od razvijalcev PostgreSQL, eden od klju\u010dnih razvijalcev vseh nizkoro\u010dnih komponent. In \u010de sledite povezavam iz tega \u010dlanka, boste na\u0161li ve\u010d barvitih zgodb o tem, kako je ljudem NUMA ote\u017eila \u017eivljenje. Oglejte si in preu\u010dite seznam nastavitev za skrbnike, ki jih je treba konfigurirati na stre\u017eniku, da bo na\u0161a baza podatkov delovala dobro. Te nastavitve je treba zapisati in preverjati, sicer ne bo dobro. <\/p>\n
<\/p>\n
Opa\u017eam, da to velja za vse nastavitve, o katerih bom govoril. Obi\u010dajno se baze podatkov postavijo v na\u010din master-slave za odpornost na napake. Ne pozabite uvesti teh nastavitev na slave, ker se bo v dolo\u010denem trenutku zgodila napaka, vi pa se boste preklopili na slave, ki bo postal master. <\/p>\n
<\/p>\n
V izredni situaciji, ko je vse zelo slabo, bo va\u0161 telefon nenehno zvonil, direktor bo prihitel s palico, in takrat ne boste imeli \u010dasa razmi\u0161ljati o preverjanju. Rezultati so lahko zelo ob\u017ealovanja vredni.<\/p>\n
<\/p>\n
<\/p>\n
Naslednja to\u010dka so huge pages. Huge pages je te\u017eko testirati lo\u010deno, niti ni pretiranega smisla za to, \u010deprav obstajajo benchmarki, ki to znajo storiti. Ti so enostavno dostopni preko iskalnika. <\/p>\n
<\/p>\n
Kak\u0161en je smisel? Imate server, ki ni zelo drag, vendar ima veliko RAM-a, na primer ve\u010d kot 30 GB. Huge pages niso uporabljene. To pomeni, da zagotovo imate overhead pri uporabi pomnilnika. In ta overhead ni ravno prijeten. <\/p>\n
<\/p>\n
<\/p>\n
Zakaj tako? Kaj se dogaja? Operacijski sistem dodeljuje pomnilnik v majhnih kosih. To je priro\u010dno, tako je zgodovinsko postalo. \u010ce se poglobimo, mora OS pretvoriti virtualne naslove v fizi\u010dne. Ta proces ni najpreprostej\u0161i, zato OS rezultat te operacije predpomni v Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
In ker je TLB predpomnilnik, se v tej situaciji pojavljajo vsi problemi, ki jih povzro\u010dajo predpomnilniki. Prvi\u010d, \u010de imate zelo veliko operativne pomnilnika in je ta dodeljena v majhnih kosih, potem ta predpomnilnik postane zelo velik. In \u010de je predpomnilnik velik, je iskanje po njem po\u010dasnej\u0161e. Overhead je zdrav in sam zavzema prostor, tj. operativna pomnilnik porabi nekaj, kar ni pravilno. To je ena stvar. <\/p>\n
<\/p>\n
Dva \u2013 \u010dim se ke\u0161 u ovoj situaciji vi\u0161e \u0161iri, ve\u0107a je verovatno\u0107a da \u0107e vam se desiti cache misses. Efikasnost ovog ke\u0161a naglo opada sa pove\u0107anjem njegove veli\u010dine. Stoga su u operativnim sistemima smislili jednostavan pristup. U Linuxu se ve\u0107 dugo koristi. U FreeBSD-ju je nedavno uveden. No, govorimo o Linuxu. To su huge pages.<\/p>\n
<\/p>\n
Ovde treba napomenuti da su huge pages, kao ideja, prvobitno podr\u017eali zajednice koje su obuhvatale Oracle i IBM, tj. proizvo\u0111a\u010di baza podataka su ozbiljno razmi\u0161ljali o tome kako \u0107e to biti korisno, uklju\u010duju\u0107i i baze podataka. <\/p>\n
<\/p>\n
<\/p>\n
Kako to povezati sa PostgreSQL-om? Prvo, u Linux jezgru moraju biti uklju\u010dene huge pages.<\/p>\n
<\/p>\n
Drugo, moraju biti eksplicitno navedene putem sysctl parametra \u2013 koliko ih ima. Brojevi ovde poti\u010du sa nekog starog servera. Mo\u017eete izra\u010dunati koliko otprilike imate shared buffers, da bi huge pages stali u njih. <\/p>\n
<\/p>\n
Ako je ceo server dodeljen PostgreSQL-u, onda je dobra polazna ta\u010dka ili 25 % RAM-a odvojiti za shared buffers, ili 75 %, ako ste sigurni da va\u0161a baza podataka sigurno staje u tih 75 %. To je prva polazna ta\u010dka. I izra\u010dunajte, ako imate 256 GB RAM-a, tada \u0107ete imati 64 GB shared buffers. Izra\u010dunajte otprilike sa nekim rezervama \u2013 kolika bi ta cifra trebala da bude.<\/p>\n
<\/p>\n
Do verzije 9.2 (ako se ne varam, od verzije 8.2) moglo je da se pomo\u0107u eksternih biblioteka pove\u017eu PostgreSQL i huge pages. To uvek treba u\u010diniti. Prvo, potrebno je da jezgro ume pravilno da alocira huge pages. A, drugo, aplikacija koja s njima radi mora mo\u0107i da ih iskoristi. Ne\u0107e to uraditi samo od sebe. Po\u0161to je PostgreSQL alocirao memoriju na na\u010din system 5, to se moglo uraditi pomo\u0107u libhugetlbfs \u2013 to je puno ime biblioteke.<\/p>\n
<\/p>\n
V razli\u010dici 9.3 smo izbolj\u0161ali zmogljivost PostgreSQL pri delu z pomnilnikom in opustili metodo dodeljevanja pomnilnika system 5. Vsi smo bili zelo veseli, saj sicer, ko posku\u0161ate zagnati dva primerka PostgreSQL na eni napravi, re\u010de, da mi zmanjkuje deljenega pomnilnika. In pove, da je treba popraviti sysctl. In tam je tak sysctl, da je treba \u0161e ponovno zagnati itd. Na splo\u0161no smo bili vsi veseli. Vendar pa je dodeljevanje pomnilnika mmap pokvarilo uporabo ogromnih strani. Ve\u010dina na\u0161ih strank uporablja velike deljene buferje. Zelo priporo\u010damo, da ne prehajate na 9.3, saj se je tam overhead za\u010del meriti v ve\u010d odstotkih.<\/p>\n
<\/p>\n
Toda skupnost se je osredoto\u010dila na ta problem in v 9.4 so zelo dobro prenovili to zadevo. V 9.4 se je pojavil parameter v postgresql.conf, s katerim lahko omogo\u010dite mo\u017enost try, on ali off.<\/p>\n
<\/p>\n
Try je najbolj varna mo\u017enost. Ob zagonu PostgreSQL, ko dodeljuje deljen pomnilnik, posku\u0161a pobrati ta pomnilnik iz ogromnih strani. In \u010de mu ne uspe, se preklopi na obi\u010dajno dodelitev. \u010ce imate FreeBSD ali Solaris, lahko nastavite try, to je vedno varno. <\/p>\n
<\/p>\n
\u010ce je nastavitev on, se preprosto ne za\u017eene, \u010de mu ne uspe pridobiti iz ogromnih strani. Tu je odvisno od va\u0161ih preferenc. Toda \u010de imate try, preverite, da se je res dodelil tisto, kar potrebujete, ker je tam veliko prostora za napake. Ta funkcionalnost trenutno deluje samo na Linuxu.<\/p>\n
<\/p>\n
\u0160e ena majhna opomba, preden gremo naprej. Transparent huge pages trenutno niso povezane s PostgreSQL. Na normalno uporabo le-teh ne more. In pri Transparent huge pages za tak workload, ko potrebujete velik kos deljenega pomnilnika, so prednosti prisotne le pri zelo velikih koli\u010dinah. \u010ce imate terabajne pomnilnika, potem to lahko igra vlogo. \u010ce govorimo o bolj obi\u010dajnih uporabah, ko imate 32, 64, 128, 256 GB pomnilnika na napravi, so obi\u010dajne ogromne strani v redu, transparentne pa preprosto izklopimo. <\/p>\n
<\/p>\n
<\/p>\n
In zadnja stvar, ki se nana\u0161a na pomnilnik in ni neposredno povezana s prepustnostjo, lahko mo\u010dno pokvari \u017eivljenje. Vsa prepustnost lahko mo\u010dno trpi, \u010de se stre\u017enik nenehno swap-a. <\/p>\n
<\/p>\n
In this case, it can be quite unpleasant for various reasons. The main inconvenience lies in the fact that modern kernels behave slightly differently than older Linux kernels. This is a situation we want to avoid, because when we talk about working with swap, it often leads to an untimely arrival of the OOM-killer. An OOM-killer that comes too late and terminates PostgreSQL is certainly an inconvenience. Everyone will notice this, including end users. <\/p>\n
<\/p>\n
<\/p>\n
What is happening? You have a large amount of RAM, everything is functioning well. But for some reason, the server hangs in swap and slows down because of this. It seems like there is plenty of memory, but that doesn\u2019t help. <\/p>\n
<\/p>\n
<\/p>\n
Previously, we recommended setting vm.swappiness to zero, meaning to disable swap. We once thought that having 32 GB of RAM and corresponding shared buffers was substantial. The main purpose of swap is to have a space where we can put pages when we run out of memory. And that purpose was no longer effectively fulfilled. And what do you do with those pages after? It becomes a task where it\u2019s not entirely clear why swap is needed, especially of such a large size. <\/p>\n
<\/p>\n
However, in more modern, i.e., third versions of the kernel, the behavior has changed. If you set swap to zero, or disable it, sooner or later, even with some RAM left, the OOM-killer will arrive to terminate the most intensive consumers. Because it will assume that with this workload, we have just a bit left and we're going to run out of memory. The OOM-killer won\u2019t terminate system processes but will eliminate something less critical. This less critical process will usually be the intensive consumer of shared memory, namely postmaster. After this, we can only hope that the database won\u2019t need recovery. <\/p>\n
<\/p>\n
Therefore, currently, by default, as far as I remember, most distributions set it around 6, which indicates when to start using swap depending on the remaining memory. We now recommend setting vm.swappiness to 1 because it practically disables swap but prevents the issues associated with an unexpectedly arriving OOM-killer that terminates processes.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Kaj je naslednje? Ko govorimo o zmogljivosti podatkovnih baz in postopoma prehajamo k diskovom, se vsi za\u010dnejo prijemati za glavo. Kajti resnica, da so diski po\u010dasni in spomin hiter, je vsem znana \u017ee od otro\u0161tva. Vsi vedo, da se bodo v podatkovni bazi pojavili problemi z diskovno zmogljivostjo.<\/p>\n
<\/p>\n
Glavni problem zmogljivosti PostgreSQL, povezan s sunkovom checkpoints, ne izhaja iz tega, da je disk po\u010dasen. Gre bolj zato, da propustnost spomina in diska nista uravnote\u017eeni. Hkrati sta lahko neuravnote\u017eeni na razli\u010dnih mestih. PostgreSQL ni nastavljena, operacijski sistem ni nastavljen, strojna oprema ni nastavljena in strojna oprema ni pravilna. Te te\u017eave se ne pojavijo le takrat, ko vse poteka, kot je treba, torej bodisi da ni obremenitve bodisi da so nastavitve in strojna oprema dobro izbrane. <\/p>\n
<\/p>\n
<\/p>\n
Kaj to je in kako izgleda? Obi\u010dajno ljudje, ki delajo s PostgreSQL, v to zadevo vstopajo ve\u010dkrat. Pojasnil bom. Kot sem rekel, PostgreSQL ob\u010dasno izvaja checkpoints, da 'umazane' strani iz deljenega spomina shranjuje na disk. \u010ce imamo velik obseg deljenega spomina, checkpoint za\u010dne intenzivno vplivati na disk, ker shranjuje te strani z fsync. Prihaja v jedrni pomnilnik in se zapisuje na diske z uporabo fsync. In \u010de je obseg tega velikega, lahko opazujemo neprijeten u\u010dinek, in sicer zelo veliko obremenitev diskov.<\/p>\n
<\/p>\n
Tukaj imam dve sliki. Zdaj bom pojasnil, kaj to je. To sta dva s \u010dasovno koreliranimi grafi. Prvi graf je obremenitev diska. Tu dose\u017ee skoraj 90 % v tem trenutku. \u010ce imate podatkovno bazo s fizi\u010dnimi diski, z RAID kontrolerjem in obremenitev skoraj dose\u017ee 90 %, so to slabe novice. To pomeni, da \u0161e malo in bo dosegla 100 ter vhod-izhod se bo ustavil. <\/p>\n
<\/p>\n
\u010ce imate diskovni niz, je tu nekoliko druga\u010dna zgodba. Odvisno je od tega, kako je nastavljen, kak\u0161en niz je itd. <\/p>\n
<\/p>\n
In parallel, there is a graph configured here from the internal Postgres view, which shows how the checkpoint occurs. The green color indicates the amount of buffers, those dirty pages that arrived at this checkpoint for synchronization at that moment. This is the main thing to know here. We see that a lot of pages have arrived, and at some point, we hit a bottleneck, i.e., we were writing and clearly the disk system is very busy. The checkpoint has a significant impact on the disk. Ideally, the situation should look more like this, meaning we had less writing here. We can fix this with settings to ensure it remains so. That is, utilization is low, but we are still writing something here. <\/p>\n
<\/p>\n
What needs to be done to overcome this problem? If your IO has stopped under the database, it means that all users who came to execute their queries will be waiting. <\/p>\n
<\/p>\n
<\/p>\n
From a Linux perspective, if you have good hardware, set it up correctly, and configured PostgreSQL properly to perform these checkpoints less frequently, spreading them out over time, then you are complying with the default parameters of Debian. For most Linux distributions, the picture looks like this: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
What does this mean? Since version 2.6, there has been a demon for flushing. Pgflush, depending on what is used, is responsible for background flushing of dirty pages from the kernel buffer and for forcibly flushing dirty pages when background flushing is no longer effective. <\/p>\n
<\/p>\n
When does background occur? When 10% of the total RAM available on the server is occupied by dirty pages in the kernel buffer, a special background write function is triggered. Why is it called background? It takes as a parameter how many pages to flush. For example, it flushes N pages. For some time, this process sleeps and then comes back to flush another amount of pages. <\/p>\n
<\/p>\n
This is a very simple story. It's like a pool where water flows in one pipe and out another. We have a checkpoint that arrived, and if it sent few dirty pages for flushing, then gradually, the pgflush will carefully disperse everything from the kernel buffer. <\/p>\n
<\/p>\n
\u010ce se te umazane strani \u0161e naprej kopi\u010dijo, se naberejo do 20 %, nato pa operacijski sistem prednostno zapi\u0161e vse to na disk, ker se lahko izklopi napajanje, in imeli bomo te\u017eave. Tako bomo izgubili te podatke, na primer. <\/p>\n
<\/p>\n
Kaj je trik? Trik je v tem, da so ti parametri v sodobnem svetu 20 in 10 % celotne operativne pomnilnosti, ki jo ima naprava, povsem obupni z vidika prepustnosti katere koli diskovne sisteme, ki jo imate.<\/strong> <\/p>\n<\/p>\n
Predstavljajte si, da imate 128 GB operativne pomnilnosti. 12,8 GB pride v va\u0161 diskovni sistem. In kakr\u0161na koli predpomnilni\u0161ka enota ali niz, ki ga imate tam, ne bo prenesla toliko. <\/p>\n
<\/p>\n
<\/p>\n
Zato priporo\u010damo, da te \u0161tevilke takoj nastavite glede na mo\u017enosti va\u0161ega RAID nadzornika.<\/strong> Tukaj imam takoj priporo\u010dilo za nadzornik, ki ima 512 MB predpomnilnika. <\/p>\n<\/p>\n
Vse to se \u0161teje zelo enostavno. Lahko nastavite vm.dirty_background v bajtih. Te nastavitve prekli\u010dejo prej\u0161nji dve. Ali je razmerje privzeto, ali so aktivirane tiste, ki so z bajti, delovale bodo tiste, ki so z bajti. Ampak ker sem DBA svetovalec in delam z razli\u010dnimi strankami, se trudim biti previden, zato, \u010de so v bajtih, potem v bajtih. Nih\u010de ni dal nobenih jamstev, da dober administrator ne bo dodal pomnilnika stre\u017eniku, ga znova zagnal in da bo \u0161tevilka ostala enaka. Preprosto izra\u010dunajte te \u0161tevilke, da se bo vse zanesljivo prilegalo. <\/p>\n
<\/p>\n
Kaj se zgodi, \u010de se ne prilegate? Zapisano imam, da se u\u010dinkovito ustavi vsak flushing, ampak v resnici je to figura govora. Operacijski sistem ima velik problem \u2013 ima veliko umazanih strani, zato se u\u010dinkovito ustavi tisti IO, ki ga generirajo va\u0161i odjemalci, tj. aplikacija po\u0161lje sql poizvedbo bazi, ona \u010daka. Vsak vhod-izhod v to \u2013 ima najni\u017ejo prioriteto, ker je baza zasedena z checkpointom. In kdaj jo bo kon\u010dala, sploh ni jasno. In ko dose\u017eete ne ozadnjo, ne dokon\u010dno flushing, to pomeni, da je vse va\u0161e IO zasedeno z njim. In dokler se ne kon\u010da, ne morete ni\u010desar narediti. <\/p>\n
<\/p>\n
Tu sta \u0161e dva pomembna vidika, ki presegata ta poro\u010dilo. Te nastavitve morajo ustrezati nastavitvam v postgresql.conf, tj. nastavitvam checkpointov. In va\u0161 diskovni sistem mora biti ustrezno nastavljen. \u010ce imate predpomnilnik na RAID-u, mora imeti baterijo.<\/strong> Ljudje kupujejo RAID z dobrim predpomnilnikom brez baterije. \u010ce imate SSD v RAID-u, morajo biti stre\u017eni\u0161ki, tam morajo biti kondenzatorji.<\/strong> Tukaj je obse\u017een kontrolni seznam. Na tej povezavi je moja predstavitev o tem, kako nastaviti zmogljivost diskov v PostgreSQL. Tam so vsi ti kontrolni seznami. <\/p>\n<\/p>\n
<\/p>\n
Kaj \u0161e lahko zelo ote\u017ei \u017eivljenje? To sta dva parametra. Oba sta razmeroma nova. Po privzetku sta lahko vklju\u010dena v razli\u010dne aplikacije. In lahko zapleteta \u017eivljenje prav tako, \u010de sta vklju\u010dena nepravilno. <\/p>\n
<\/p>\n
<\/p>\n
Obstajata dve razmeroma novi stvari. \u017de v tretjih jedrih sta se pojavili. To sta sched_migration_cost v nanosekundah in sched_autogroup_enabled, ki je po privzetku en. <\/p>\n
<\/p>\n
In kako vplivata na kakovost \u017eivljenja? Kaj je sched_migration_cost? Linuxov na\u010drtovalnik lahko migrira proces z enega CPU na drugega. In za PostgreSQL, ki izvaja poizvedbe, migracija na drugi CPU ni povsem jasna. Za bazo podatkov je to zelo slabo.<\/strong> Zato je smiselna politika nastaviti migration_cost na neko veliko vrednost, vsaj nekaj tiso\u010d nanosekund.<\/strong> <\/p>\n<\/p>\n
Kaj to pomeni za na\u010drtovalnik? \u0160tel bo, da je ta proces \u0161e vedno aktiven v tem \u010dasu. To pomeni, da \u010de imate dolgo transakcijo, ki se ukvarja s \u010dim dolgotrajnim, bo na\u010drtovalnik to razumel. Menil bo, da dokler ne mine ta \u010das, migracija tega procesa ni potrebna. \u010ce proces kaj dela, ne bo nikamor migriran, temve\u010d bo mirno kon\u010dal na tistem CPU, ki mu je bil dodeljen. In rezultat je odli\u010den. <\/p>\n
<\/p>\n
Druga stvar je autogroup. To je dobra ideja za specifi\u010dne delovne obremenitve, ki nimajo zveze z modernimi bazami podatkov \u2013 skupina procesov po tistem virtualnem terminalu, iz katerega so zagnani. To je priro\u010dno za nekatere naloge. V praksi je PostgreSQL ve\u010dprocesni sistem s preforkom, ki se za\u017eene iz enega terminala. Imate lock writer, checkpoint in vse va\u0161e odjemalske poizvedbe se zdru\u017eijo na en scheduler, na en CPU. Tam bodo mirno \u010dakali, da se osvobodi, da si lahko medsebojno prepre\u010dijo in ga zasedejo dlje. To je zgodba, ki ni potrebna pri takem obremenitvi in zato jo je treba izklopiti.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Moj kolega Aleksej Lesovski je izvajal teste s preprostim pgbenchom, kjer je pove\u010deval na reda migration_cost in izklapljal autogroup. Razlika na slabem strojni opremi je bila skoraj 10%.<\/strong>. Na postgresovi mailing listi poteka razprava, kjer ljudje poro\u010dajo o rezultatih, kako so tovrstne spremembe vplivale na hitrost poizvedb. na 50%.<\/strong>. Tak\u0161nih zgodb je kar nekaj.<\/p>\n<\/p>\n
<\/p>\n
In na koncu o politiki zmanj\u0161anja porabe energije. Dobro je, da lahko zdaj Linux uporabljamo na prenosniku. In naj bi prav tako dobro var\u010deval z baterijo. A nenadoma se izka\u017ee, da je to lahko tudi na stre\u017eniku. <\/p>\n
<\/p>\n
Poleg tega, \u010de najemate stre\u017enike pri kak\u0161nem gostitelju, potem \"prijazni\" gostitelji<\/a> ne skrbijo, da bi imeli bolj\u0161o zmogljivost. Njihova naloga je, da optimizirajo izkori\u0161\u010denost strojne opreme. Zato lahko privzeto omogo\u010dijo na\u010din var\u010devanja z energijo operacijskega sistema.<\/p>\n<\/p>\n
\u010ce na stre\u017eniku z bazo podatkov pod intenzivno obremenitvijo uporabljate to, potem je va\u0161 izbor acpi_cpufreq + performance. \u017de z ondemandom se lahko pojavijo te\u017eave.<\/strong> <\/p>\n<\/p>\n
Intel_pstate je \u017ee nekoliko druga\u010den gonilnik. In trenutno se daje prednost temu, saj je novej\u0161i in bolje deluje.<\/p>\n
<\/p>\n
In seveda, governor samo performance. Ondemand, powersave in vse ostalo niso za vas. <\/p>\n
<\/p>\n
Rezultati po explain analyze PostgreSQL se lahko razlikujejo za ve\u010d reda, \u010de omogo\u010dite powersave, saj bo va\u0161 CPU pod bazo deloval na povsem nepredictabilen na\u010din.<\/p>\n
<\/p>\n
Te stvari so lahko privzeto vklju\u010dene. Pazljivo si oglejte \u2013 ali jih niso vklju\u010dili privzeto. To je lahko resna te\u017eava. <\/p>\n
<\/p>\n
<\/p>\n
Na koncu bi se rad zahvaliti ekipi iz na\u0161e DBA tima PosgreSQL-Consulting, posebno Maksu Boguku i Alekseju Lesovskom, koji se svakodnevno suo\u010davaju s izazovima ovog posla. Trudimo se da za na\u0161e klijente napravimo sve kako treba, da sve funkcioni\u0161e bez problema. Ovo je kao kod uputstava za avijacijsku sigurnost. Sve je ovde zapisano krvlju. Svaka od ovih matica je otkrivena tokom odre\u0111ene problema. Rado ih delimo s vama.<\/p>\n
<\/p>\n
Vpra\u0161anja:<\/p>\n
<\/p>\n
Hvala! Ako, na primer, kompanija \u017eeli da u\u0161tedi i postavi bazu podataka i aplikacionu logiku na istom serveru, ili ako kompanija prati modernu tendenciju mikroservisnih arhitektura u kojima se PostgreSQL pokre\u0107e u kontejneru. U \u010demu je caka? Sysctl globalno uti\u010de na celo jezgro. Nisam \u010duo da se sysctl kao nekako virtualizuje, da rade odvojeno u kontejneru. Ima samo cgroup i tu postoji kontrola samo za deo. Kako se mo\u017ee \u017eiveti s tim? Ili, ako \u017eelite performanse, pokrenite PostgreSQL na posebnom fizi\u010dkom serveru i optimizujte ga.<\/em><\/p>\n<\/p>\n
Odgovorili smo na va\u0161e pitanje na otprilike tri na\u010dina. Ako ne govorimo o fizi\u010dkom serveru koji se mo\u017ee optimizovati itd., onda se opustite, sve \u0107e raditi dobro bez tih pode\u0161avanja. Ako dobijete takvo optere\u0107enje da treba da uradite ta pode\u0161avanja, br\u017ee \u0107ete do\u0107i do fizi\u010dkog servera nego do ovih pode\u0161avanja.<\/p>\n
<\/p>\n
U \u010demu je problem? Ako je to virtuelna ma\u0161ina, verovatno \u0107ete imati mnogo problema, na primer, zbog dosta neuskla\u0111enosti latencije diska na ve\u0107ini virtuelnih ma\u0161ina. \u010cak i ako je propusnost diskova dobra, jedna neuspela transakcija operacija ulaza-izlaza, koja ne uti\u010de zna\u010dajno na prose\u010dnu propusnost, a koja se dogodila tokom checkpoint-a ili tokom pisanja u WAL, mo\u017ee zna\u010dajno da na\u0161kodi bazi. To \u0107ete primetiti pre nego \u0161to se suo\u010dite s ovim problemima. <\/p>\n
<\/p>\n
Ako imate NGINX na istom serveru, i dalje \u0107e biti isti problem. Borit \u0107e se za deljenu memoriju. Ne\u0107ete sti\u0107i do problema koji su ovde opisani.<\/p>\n
<\/p>\n
Vendar pa so nekateri od teh parametrov \u0161e vedno pomembni za vas. Na primer, z uporabo sysctl nastavite dirty_ratio, da ne bo tako ekstremno \u2013 v vsakem primeru bo to pomagalo. Tako ali tako bo va\u0161e zanimanje za disk. In to bo potekalo po napa\u010dni shemi. To so dejansko privzete nastavitve, ki sem jih prikazal. In v vsakem primeru jih je bolje spremeniti. <\/p>\n
<\/p>\n
Z NUMA se lahko pojavijo te\u017eave. VmWare, na primer, dobro deluje z NUMA pri natan\u010dno nasprotnih nastavitvah. In tukaj je treba izbrati \u2013 fizi\u010dni stre\u017enik ali ne. <\/p>\n
<\/p>\n
Imam vpra\u0161anje v zvezi z Amazon AWS. Imajo vnaprej nastavljene slike. Ena izmed njih se imenuje Amazon RDS. Ali obstajajo kak\u0161ne prilagojene nastavitve za njihovo operacijski sistem?<\/em><\/p>\n<\/p>\n
Obstajajo nastavitve, vendar so to druge nastavitve. Tu nastavljamo operacijski sistem z vidika tega, kako bo baza podatkov to uporabljala. Obstajajo parametri, ki dolo\u010dajo, kam gremo sedaj, torej tak\u0161no oblikovanje. To pomeni, da potrebujemo toliko virov, ki jih bomo zdaj uporabili. Po tem Amazon RDS te vire povezuje, in takrat se zmogljivost zmanj\u0161a. Imajo lo\u010dene zgodbe, kako se ljudje na to lotijo uporabiti. V\u010dasih celo precej uspe\u0161no. Vendar to nima zveze z nastavitvami operacijskega sistema. To je nekak\u0161no hekanje oblakov. To je druga zgodba.<\/p>\n
<\/p>\n
Zakaj Transparent huge pages ne dajejo u\u010dinka v primerjavi z Huge TLB?<\/em><\/p>\n<\/p>\n
Ne dajejo. To lahko pojasnimo na mnoge na\u010dine. Vendar dejansko ne dajejo u\u010dinka. Katera zgodba je s PostgreSQL? Ob zagonu dodeli velik kos deljene pomnilnika. Ne glede na to, ali so Transparent ali niso - to nima pomena. Dejstvo, da se dodelijo ob zagonu, pojasnjuje vse. In \u010de je pomnilnika zelo veliko in ga je treba prestrukturirati v segment deljenega pomnilnika, potem bo Transparent huge pages pomemben. Pri PostgreSQL je enostavno dodeljen velik kos ob zagonu in to je to, nadalje tam ne poteka ni\u010d posebnega. Seveda ga je mogo\u010de uporabljati, vendar obstaja mo\u017enost, da pride do po\u0161kodbe deljenega pomnilnika, ko bo ponovno dodeljeval kaj. PostgreSQL tega ne ve.<\/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