szerveren<\/a> \u00e9s mindez v\u00e9g\u00fcl egy SATA merevlemezre \u00e9rkezik, mindenf\u00e9le cache n\u00e9lk\u00fcl, akkor az eg\u00e9sz adatb\u00e1zis szerver nemcsak \u00fagy n\u00e9z ki, mint egy t\u00f6k, hanem egy SATA interf\u00e9szes t\u00f6k lesz. K\u00f6zvetlen\u00fcl tapasztalni fogja ezt. \u00c9s semmi sem mentheti meg \u00f6nt.<\/p>\n<\/p>\n
<\/p>\n
A mem\u00f3ri\u00e1val kapcsolatos els\u0151 ponttal kapcsolatban h\u00e1rom dolog van, ami nagyon megnehez\u00edtheti az \u00e9letet. <\/p>\n
<\/p>\n
Az els\u0151 a NUMA. A NUMA egy olyan dolog, amelyet a teljes\u00edtm\u00e9ny jav\u00edt\u00e1sa \u00e9rdek\u00e9ben hoztak l\u00e9tre. A workload f\u00fcggv\u00e9ny\u00e9ben k\u00fcl\u00f6nb\u00f6z\u0151 dolgokat lehet optimaliz\u00e1lni. Jelenlegi form\u00e1j\u00e1ban nem t\u00fal kedvez\u0151 azokhoz az alkalmaz\u00e1sokhoz, mint p\u00e9ld\u00e1ul a nagy m\u00e9rt\u00e9kben page cache-t haszn\u00e1l\u00f3 adatb\u00e1zisok. <\/p>\n
<\/p>\n
<\/p>\n
K\u00e9t sz\u00f3ban. Hogyan \u00e9rts\u00fck meg, hogy a NUMA-val valami nincs rendben? Valamilyen kellemetlen zajt hall, hirtelen egyik CPU t\u00falterheltnek bizonyul. Ek\u00f6zben elemzi a k\u00e9rd\u00e9seket a PostgreSQL-ben, \u00e9s l\u00e1tja, hogy ott semmi hasonl\u00f3 nincs. Ezeknek a k\u00e9rd\u00e9seknek nem szabad ennyire intenz\u00edven CPU-t fogyasztaniuk. Ezt sok\u00e1ig lehet figyelni. Jobb az elej\u00e9t\u0151l fogva a megfelel\u0151 aj\u00e1nl\u00e1st k\u00f6vetni, hogy hogyan kell be\u00e1ll\u00edtani a NUMA-t a PostgreSQL-hez.<\/p>\n
<\/p>\n
<\/p>\n
Mi is t\u00f6rt\u00e9nik val\u00f3j\u00e1ban? A NUMA \u2013 Non-Uniform Memory Access. Mi az \u00e9rtelme? Van egy CPU-ja, mellette helyileg l\u00e9v\u0151 mem\u00f3ri\u00e1val. \u00c9s ez a mem\u00f3ria interconnects m\u00e1s CPU-k mem\u00f3ri\u00e1j\u00e1t is leh\u00edvhatja.<\/p>\n
<\/p>\n
Ha futtatja a(z) numactl --hardware<\/code>, akkor egy nagy le\u00edr\u00e1s fog megjelenni. T\u00f6bbek k\u00f6z\u00f6tt ott lesz egy distances mez\u0151. Lesznek sz\u00e1mok \u2013 10-20, valami ilyesmi. Ezek a sz\u00e1mok nem m\u00e1sok, mint a t\u00e1voli mem\u00f3ria el\u00e9r\u00e9s\u00e9hez sz\u00fcks\u00e9ges hopsz\u00e1mok, hogy azt helyben haszn\u00e1lhassa. Alapvet\u0151en j\u00f3 \u00f6tlet. Ez jelent\u0151sen jav\u00edtja a teljes\u00edtm\u00e9nyt bizonyos terhel\u00e9sek sor\u00e1n.<\/p>\n<\/p>\n
Most k\u00e9pzelje el, hogy van egy CPU, amely el\u0151sz\u00f6r megpr\u00f3b\u00e1lja haszn\u00e1lni a helyi mem\u00f3ri\u00e1j\u00e1t, majd pr\u00f3b\u00e1l m\u00e1s mem\u00f3ri\u00e1t beh\u00fazni interconnecten kereszt\u00fcl valamihez. \u00c9s erre a CPU-ra jut el az \u00f6sszes page cache PostgreSQL \u2013 mind, ami ott van, n\u00e9h\u00e1ny gigabyte. Mindig a legrosszabb esetet kapja, mert a CPU-n k\u00f6zvetlen\u00fcl ezen a mem\u00f3riamodulon \u00e1ltal\u00e1ban kev\u00e9s mem\u00f3ria van. \u00c9s minden mem\u00f3ria, ami szolg\u00e1ltatva van, ezeken az interconnecteken kereszt\u00fcl megy. Ez lass\u00fa \u00e9s szomor\u00fa helyzet. \u00c9s a processzor, amely ezt a csom\u00f3pontot kezeli, folyamatosan t\u00falterhelt. \u00c9s a mem\u00f3ria hozz\u00e1f\u00e9r\u00e9si ideje \u2013 rossz, lass\u00fa. Ez az a helyzet, amit nem szeretne, ha adatb\u00e1zisk\u00e9nt haszn\u00e1lja ezt az eg\u00e9szet. <\/p>\n
<\/p>\n
Ez\u00e9rt a megfelel\u0151bb megold\u00e1s, hogy az oper\u00e1ci\u00f3s rendszer Linux egy\u00e1ltal\u00e1n ne tudja, hogy mi t\u00f6rt\u00e9nik odabent. Hogy \u00fagy hivatkozzon a mem\u00f3ri\u00e1ra, ahogy szeretne. <\/p>\n
<\/p>\n
Mi\u00e9rt van ez \u00edgy? \u00dagy t\u0171nne, hogy ennek \u00e9ppen ellenkez\u0151leg kellene lennie. Ennek egy egyszer\u0171 oka van, hogy sok mem\u00f3ri\u00e1ra van sz\u00fcks\u00e9g\u00fcnk a page cache-hez \u2013 t\u00edz-, sz\u00e1z gigabyte. <\/p>\n
<\/p>\n
\u00c9s ha mindezt kiemelt\u00fck \u00e9s megcachingoltuk az adatainkat ott, akkor a cache haszn\u00e1lat\u00e1b\u00f3l sz\u00e1rmaz\u00f3 nyeres\u00e9g jelent\u0151sen nagyobb lesz, mint a mem\u00f3ria ilyen okos kezel\u00e9se. \u00cdgy teh\u00e1t nem \u00f6sszehasonl\u00edthat\u00f3 nyeres\u00e9get \u00e9r\u00fcnk el azzal, hogy hat\u00e9konyabban b\u00e1nunk a mem\u00f3ri\u00e1val NUMA haszn\u00e1lat\u00e1val.<\/p>\n
<\/p>\n
Ez\u00e9rt k\u00e9t megk\u00f6zel\u00edt\u00e9s van itt jelenleg, am\u00edg a vil\u00e1gos j\u00f6v\u0151 el nem \u00e9rkezik, \u00e9s az adatb\u00e1zis nem k\u00e9pes \u00f6n\u00e1ll\u00f3an meg\u00e9rteni, hogy melyik CPU-n fut \u00e9s honnan kellene valamit beh\u00faznia. <\/p>\n
<\/p>\n
<\/p>\n
Ez\u00e9rt a helyes megk\u00f6zel\u00edt\u00e9s az, hogy teljesen letiltjuk a NUMA-t<\/strong>, p\u00e9ld\u00e1ul \u00fajraind\u00edt\u00e1skor. A legt\u00f6bb esetben a nyeres\u00e9gek olyan rendk\u00edv\u00fcliek, hogy fel sem mer\u00fcl a k\u00e9rd\u00e9s, mi a jobb. <\/p>\n<\/p>\n
Van egy m\u00e1sik lehet\u0151s\u00e9g. Ezt gyakrabban haszn\u00e1ljuk, mint az els\u0151t, mert amikor \u00fcgyf\u00e9l \u00e9rkezik a t\u00e1mogat\u00e1sra, az sz\u00e1m\u00e1ra a szerver \u00fajraind\u00edt\u00e1sa hatalmas dolog. Ott az \u00fczlete m\u0171k\u00f6dik. A NUMA-val kapcsolatos probl\u00e9m\u00e1kba \u00fctk\u00f6znek. Ez\u00e9rt igyeksz\u00fcnk kev\u00e9sb\u00e9 invaz\u00edv m\u00f3don letiltani, mint az \u00fajraind\u00edt\u00e1s, de itt figyelmesen ellen\u0151rizze, hogy val\u00f3ban letilt\u00f3dott. Mert a tapasztalatok azt mutatj\u00e1k, hogy a PostgreSQL sz\u00fcl\u0151processz sz\u00e1m\u00e1ra a NUMA letilt\u00e1sa j\u00f3, de egy\u00e1ltal\u00e1n nem biztos, hogy ez m\u0171k\u00f6dni fog. Ellen\u0151rizni \u00e9s figyelni kell, hogy val\u00f3ban letilt\u00f3dott. <\/p>\n
<\/p>\n
Van egy j\u00f3 poszt Robert Haasr\u00f3l. \u0150 az egyik PostgreSQL fejleszt\u0151je. Az alapvet\u0151 szoftverelemek egyik kulcsfejleszt\u0151je. Ha \u00e1tn\u00e9zz\u00fck ennek a posztnak a linkjeit, t\u00f6bb sz\u00ednes t\u00f6rt\u00e9net is olvashat\u00f3 arr\u00f3l, hogy a NUMA hogyan nehez\u00edtette meg az emberek \u00e9let\u00e9t. N\u00e9zze meg, tanulm\u00e1nyozza a rendszergazd\u00e1k sz\u00e1m\u00e1ra k\u00e9sz\u00fclt ellen\u0151rz\u0151list\u00e1t, amely tartalmazza a szerveren be\u00e1ll\u00edtand\u00f3 dolgokat, hogy az adatb\u00e1zisunk j\u00f3l m\u0171k\u00f6dj\u00f6n. Ezeket a be\u00e1ll\u00edt\u00e1sokat meg kell jegyezni \u00e9s ellen\u0151rizni, mert k\u00fcl\u00f6nben nem fogj\u00e1k j\u00f3l v\u00e9gezni a dolgukat. <\/p>\n
<\/p>\n
Felh\u00edvom a figyelmet, hogy ez minden be\u00e1ll\u00edt\u00e1st \u00e9rint, amir\u0151l besz\u00e9lni fogok. De \u00e1ltal\u00e1ban az adatb\u00e1zisokat master-slave m\u00f3dban \u00e1ll\u00edtj\u00e1k \u00f6ssze a magas rendelkez\u00e9sre \u00e1ll\u00e1s \u00e9rdek\u00e9ben. Ne felejtse el ezeket a be\u00e1ll\u00edt\u00e1sokat a slave-re is \u00e1tvinni, mert egy sz\u00e9p napon baleset t\u00f6rt\u00e9nhet, \u00e9s \u00e1t kell kapcsolnia a slave-re, ami ezut\u00e1n masterr\u00e9 v\u00e1lik. <\/p>\n
<\/p>\n
Baleseti helyzetben, amikor minden nagyon rosszul megy, a telefon folyamatosan cs\u00f6r\u00f6g, \u00e9s a f\u0151n\u00f6k nagy bottal rohan be, nem lesz ideje gondolkodni az ellen\u0151rz\u00e9sr\u0151l. Az eredm\u00e9nyek nagyon szomor\u00faak lehetnek.<\/p>\n
<\/p>\n
<\/p>\n
A k\u00f6vetkez\u0151 pont a huge pages. A huge pages k\u00fcl\u00f6n tesztel\u00e9se neh\u00e9zkes, \u00e9s nincs is sok \u00e9rtelme, b\u00e1r vannak benchmarkok, amelyek k\u00e9pesek erre. Ezek k\u00f6nnyen fellelhet\u0151k. <\/p>\n
<\/p>\n
Mi az \u00e9rtelme? Van egy nem t\u00fal dr\u00e1ga szervere, amelynek sok a RAM-ja, p\u00e9ld\u00e1ul t\u00f6bb mint 30 GB. A huge pages nincs haszn\u00e1latban. Ez azt jelenti, hogy egy\u00e9rtelm\u0171en van overhead a mem\u00f3riahaszn\u00e1latban. \u00c9s ez az overhead nem \u00e9ppen kellemes. <\/p>\n
<\/p>\n
<\/p>\n
Mi\u00e9rt van ez \u00edgy? Mi t\u00f6rt\u00e9nik? Az oper\u00e1ci\u00f3s rendszer apr\u00f3 darabokban osztja ki a mem\u00f3ri\u00e1t. Ez k\u00e9nyelmes, \u00edgy alakult ki t\u00f6rt\u00e9nelmileg. Ha belemer\u00fcl\u00fcnk a r\u00e9szletekbe, az oper\u00e1ci\u00f3s rendszernek le kell ford\u00edtania a virtu\u00e1lis c\u00edmeket fizikai c\u00edmekre. Ez a folyamat nem a legegyszer\u0171bb, ez\u00e9rt az oper\u00e1ci\u00f3s rendszer a m\u0171velet eredm\u00e9ny\u00e9t a Translation Lookaside Buffer (TLB) t\u00e1rolja.<\/p>\n
<\/p>\n
Mivel a TLB egy cache, ebben a helyzetben minden olyan probl\u00e9ma felmer\u00fcl, amely a cache-re jellemz\u0151. El\u0151sz\u00f6r is, ha nagyon sok RAM-je van, \u00e9s mindegyik kicsi darabokban van kiosztva, a buffer nagyon nagy lesz. Ha a cache nagy, akkor nehezebb benne keresni. Az overhead jelent\u0151s, \u00e9s \u00f6n\u00e1ll\u00f3an is foglal helyet, azaz a RAM nem megfelel\u0151en haszn\u00e1lt r\u00e9szeit fogyasztja. Ez az els\u0151 dolog. <\/p>\n
<\/p>\n
Kett\u0151 \u2013 min\u00e9l nagyobb a gyors\u00edt\u00f3t\u00e1r ilyen helyzetben, ann\u00e1l val\u00f3sz\u00edn\u0171bb, hogy cache hi\u00e1nyok fognak el\u0151fordulni. A gyors\u00edt\u00f3t\u00e1r hat\u00e9konys\u00e1ga gyorsan cs\u00f6kken a m\u00e9ret\u00e9nek n\u00f6veked\u00e9s\u00e9vel. Ez\u00e9rt az oper\u00e1ci\u00f3s rendszerekben kital\u00e1ltak egy egyszer\u0171 megk\u00f6zel\u00edt\u00e9st. A Linuxban ezt r\u00e9g\u00f3ta haszn\u00e1lj\u00e1k. A FreeBSD-ben nemr\u00e9giben ker\u00fclt bevezet\u00e9sre. De mi a Linuxr\u00f3l besz\u00e9l\u00fcnk. Ez a huge pages.<\/p>\n
<\/p>\n
Itt meg kell jegyezni, hogy a huge pages, mint \u00f6tlet, eredetileg olyan k\u00f6z\u00f6ss\u00e9gek \u00e1ltal ker\u00fclt el\u0151t\u00e9rbe, mint az Oracle \u00e9s az IBM, teh\u00e1t az adatb\u00e1zis-gy\u00e1rt\u00f3k nagyban gondolkodtak azon, hogy ez hasznos lesz, t\u00f6bbek k\u00f6z\u00f6tt az adatb\u00e1zisok sz\u00e1m\u00e1ra is. <\/p>\n
<\/p>\n
<\/p>\n
Hogyan kapcsoljuk ezt \u00f6ssze a PostgreSQL-lel? El\u0151sz\u00f6r is, a Linux kernelben enged\u00e9lyezve kell, hogy legyenek a huge pages.<\/p>\n
<\/p>\n
M\u00e1sodszor, ezeknek egy\u00e9rtelm\u0171en meg kell lennie adva a sysctl param\u00e9ter r\u00e9v\u00e9n \u2013 mennyi van bel\u0151l\u00fck. A sz\u00e1mok egy r\u00e9gi szerverb\u0151l sz\u00e1rmaznak. Meg tudja becs\u00fclni, mennyit haszn\u00e1lt sharied buffers-b\u00f3l, hogy a huge pages belef\u00e9rjenek. <\/p>\n
<\/p>\n
Ha az eg\u00e9sz szerver \u00e1t van adva a PostgreSQL-nek, akkor egy j\u00f3 kiindul\u00e1si pont lehet, hogy a RAM 25%-\u00e1t a shared buffer-eknek adja, vagy 75%-ot, ha biztos benne, hogy ebbe a 75%-ba az adatb\u00e1zisa pontosan belef\u00e9r. Ez az els\u0151 kiindul\u00e1si pont. \u00c9s sz\u00e1molja ki, ha 256 GB RAM-ja van, akkor megfelel\u0151en 64 GB-ot fog kapni shared buffer-ekb\u0151l. Sz\u00e1molja ki egy kicsit tartal\u00e9kkal - mennyire kell ezt a sz\u00e1mot be\u00e1ll\u00edtani.<\/p>\n
<\/p>\n
A 9.2-es verzi\u00f3 el\u0151tt (ha nem t\u00e9vedek, a 8.2-es verzi\u00f3t\u00f3l kezdve) egy k\u00fcls\u0151 k\u00f6nyvt\u00e1rral \u00f6sszef\u00e9rhet\u0151v\u00e9 lehetett tenni a PostgreSQL-t a huge pages-szel. Ezt mindig el kell v\u00e9gezni. El\u0151sz\u00f6r is, a kernelnek megfelel\u0151en kell tudnia kiosztani a huge pages-t. M\u00e1sodszor, az alkalmaz\u00e1snak, amelyikkel ezeket haszn\u00e1lj\u00e1k,k\u00e9pesnek kell lennie rendelkeznie vel\u00fck. Csak \u00fagy nem fog tudni \u00e9lni vel\u00fck. Mivel a PostgreSQL a system 5 st\u00edlus\u00e1ban osztotta el a mem\u00f3ri\u00e1t, ezt a libhugetlbfs seg\u00edts\u00e9g\u00e9vel lehetett megoldani \u2013 ez a k\u00f6nyvt\u00e1r teljes neve.<\/p>\n
<\/p>\n
A 9.3-ban jav\u00edtott\u00e1k a PostgreSQL teljes\u00edtm\u00e9ny\u00e9t a mem\u00f3riakezel\u00e9s ter\u00e9n, \u00e9s elhagyt\u00e1k az 5-\u00f6s rendszer mem\u00f3riatall\u00f3z\u00e1si m\u00f3dszer\u00e9t. Mindenki nagyon \u00f6r\u00fclt, mert k\u00fcl\u00f6nben, ha megpr\u00f3b\u00e1ln\u00e1d futtatni a k\u00e9t PostgreSQL p\u00e9ld\u00e1nyt egy g\u00e9pen, azt mondan\u00e1, hogy nincs el\u00e9g megosztott mem\u00f3ri\u00e1m. \u00c9s azt mondja, jav\u00edtani kell a sysctl-t. \u00c9s ott olyan sysctl van, hogy m\u00e9g \u00fajra kell ind\u00edtani meg bla-bla. Sz\u00f3val mindenki \u00f6r\u00fclt. De a mmap mem\u00f3riaallok\u00e1ci\u00f3 megbicsaklotta a nagy oldalak haszn\u00e1lat\u00e1t. \u00dcgyfeleink t\u00f6bbs\u00e9ge nagy megosztott puffereket haszn\u00e1l. \u00e9s hat\u00e1rozottan javasoltuk, hogy ne v\u00e1ltsanak 9.3-ra, mert ott a t\u00falfejleszt\u00e9s j\u00f3 sz\u00e1zal\u00e9kos ar\u00e1nyban kezdett megjelenni.<\/p>\n
<\/p>\n
De a k\u00f6z\u00f6ss\u00e9g felh\u00edvta erre a probl\u00e9m\u00e1ra a figyelmet, \u00e9s a 9.4-ben nagyon j\u00f3l \u00e1tdolgozt\u00e1k ezt a folyamatot. A 9.4-ben megjelent egy \u00faj param\u00e9ter a postgresql.conf f\u00e1jlban, amivel bekapcsolhatod a try-t, on-t vagy off-ot.<\/p>\n
<\/p>\n
A try a legbiztons\u00e1gosabb param\u00e9ter. PostgreSQL ind\u00edt\u00e1sakor, amikor a megosztott mem\u00f3ri\u00e1t c\u00edmzi, pr\u00f3b\u00e1lja megszerezni az ebb\u0151l a nagy oldalakb\u00f3l val\u00f3 mem\u00f3ri\u00e1t. \u00c9s ha nem siker\u00fcl, akkor visszav\u00e1lt a norm\u00e1l allok\u00e1ci\u00f3ra. Ha FreeBSD vagy Solaris van, akkor be\u00e1ll\u00edthatod a try-t, ez mindig biztons\u00e1gos. <\/p>\n
<\/p>\n
Ha on, akkor csak nem indul el, ha nem tudta megszerezni a nagy oldalakb\u00f3l. Ez m\u00e1r \u2013 kinek mi a sz\u00edv\u00e9hez k\u00f6zel \u00e1ll. De ha try van be\u00e1ll\u00edtva, ellen\u0151rizd, hogy val\u00f3ban azt kaptad, aminek kell, mert ott sok a hib\u00e1z\u00e1si lehet\u0151s\u00e9g. Jelenleg ez a funkci\u00f3 csak Linuxon m\u0171k\u00f6dik.<\/p>\n
<\/p>\n
M\u00e9g egy kis megjegyz\u00e9s, miel\u0151tt tov\u00e1bbmenn\u00e9nk. A transparent huge pages nem a PostgreSQL-r\u00f3l sz\u00f3l ezid\u00e1ig. Nem tud a norm\u00e1lis m\u00f3don \u00e9lni vel\u00fck. \u00c9S a transparent huge pages mellett, amikor nagy megosztott mem\u00f3ri\u00e1ra van sz\u00fcks\u00e9g, az el\u0151ny\u00f6k csak nagyon nagy mennyis\u00e9gek eset\u00e9n jelennek meg. Ha terab\u00e1jt mem\u00f3ria van n\u00e1lad, akkor ez sz\u00e1m\u00edthat. Ha h\u00e9tk\u00f6znapi alkalmaz\u00e1sokr\u00f3l besz\u00e9l\u00fcnk, amikor 32, 64, 128, 256 GB mem\u00f3ria van a g\u00e9pen, akkor a sima nagy oldalak rendben vannak, a transparentet pedig csak kikapcsoljuk. <\/p>\n
<\/p>\n
<\/p>\n
\u00c9s az utols\u00f3 dolog a mem\u00f3ri\u00e1val kapcsolatban, k\u00f6zvetlen\u00fcl nem kapcsol\u00f3dik a throughput-hoz; nagyon meg tudja nehez\u00edteni az \u00e9letedet. Az eg\u00e9sz \u00e1tereszt\u0151k\u00e9pess\u00e9g nagyon megs\u00ednyli, ha a szerver folyamatosan swap-el. <\/p>\n
<\/p>\n
Ez el\u00e9g kellemetlen lesz sz\u00e1mos szempontb\u00f3l. A f\u0151 probl\u00e9ma pedig abban rejlik, hogy a modern magok viselked\u00e9se kiss\u00e9 elt\u00e9r a r\u00e9gebbi Linux magokt\u00f3l. Ez egy olyan dolog, ami meglehet\u0151sen kellemetlen, mert amikor a swap haszn\u00e1lat\u00e1r\u00f3l besz\u00e9l\u00fcnk, az OOM-killer \u00e9rkez\u00e9se nem id\u0151ben t\u00f6rt\u00e9nik. Az OOM-killer, ami nem \u00e9rkezett id\u0151ben \u00e9s le\u00e1ll\u00edtotta a PostgreSQL-t, nem \u00e9ppen kellemes. Err\u0151l mindenki tudni fog, teh\u00e1t az utols\u00f3 felhaszn\u00e1l\u00f3ig mindenki \u00e9rtes\u00fcl r\u00f3la. <\/p>\n
<\/p>\n
<\/p>\n
Mi t\u00f6rt\u00e9nik? Sok RAM van, minden j\u00f3l m\u0171k\u00f6dik. De valami\u00e9rt a szerver a swap-ban le\u00e1ll \u00e9s ez lass\u00edtja a m\u0171k\u00f6d\u00e9s\u00e9t. \u00dagy t\u0171nik, hogy sok mem\u00f3ria van, de ez m\u00e9gis megt\u00f6rt\u00e9nik. <\/p>\n
<\/p>\n
<\/p>\n
Kor\u00e1bban azt javasoltuk, hogy \u00e1ll\u00edtsuk a vm.swappiness-t null\u00e1ra, azaz kapcsoljuk ki a swap-ot. Kor\u00e1bban \u00fagy t\u0171nt, hogy a 32 GB RAM \u00e9s a megfelel\u0151 megosztott pufferek hatalmas mennyis\u00e9g. A swap alapvet\u0151 c\u00e9lja, hogy legyen egy hely, ahov\u00e1 el lehet dobni egy kernel le\u00e1ll\u00e1sakor a mem\u00f3ri\u00e1t. Ez azonban m\u00e1r nem igaz\u00e1n teljes\u00edtette a funkci\u00f3j\u00e1t. A k\u00e9rd\u00e9s az, hogy mit kezdj\u00fcnk ezzel a kernellel? M\u00e1r nem vil\u00e1gos, hogy val\u00f3j\u00e1ban mi\u00e9rt van sz\u00fcks\u00e9g swap-ra, f\u0151leg ilyen m\u00e9retben. <\/p>\n
<\/p>\n
De a modernebb, azaz harmadik verzi\u00f3s magok eset\u00e9ben a viselked\u00e9s megv\u00e1ltozott. Ha a swap-ot null\u00e1ra \u00e1ll\u00edtod, azaz kikapcsolod, akkor el\u0151bb vagy ut\u00f3bb, m\u00e9g ha van is n\u00e9mi RAM a rendszerben, meg\u00e9rkezik az OOM-killer, hogy meg\u00f6lje a legintenz\u00edvebb er\u0151forr\u00e1s-haszn\u00e1l\u00f3kat. Mert \u00fagy fogja sz\u00e1m\u00edtani, hogy ilyen terhel\u00e9s mellett m\u00e9g maradt egy kis mem\u00f3ria \u00e9s ki fogunk ugrani, teh\u00e1t nem a rendszerfolyamatot \u00f6li meg, hanem valami kev\u00e9sb\u00e9 fontosat. Ez a kev\u00e9sb\u00e9 fontos felhaszn\u00e1l\u00f3 \u00e1ltal\u00e1ban a megosztott mem\u00f3ria intenz\u00edv fogyaszt\u00f3ja, nevezetesen a postmaster. Ezut\u00e1n m\u00e1r \u00f6r\u00fclni lehet, ha nem kell vissza\u00e1ll\u00edtani az adatb\u00e1zist. <\/p>\n
<\/p>\n
Ez\u00e9rt most az alap\u00e9rtelmezett be\u00e1ll\u00edt\u00e1s, amennyire eml\u00e9kszem, a legt\u00f6bb disztrib\u00faci\u00f3ban k\u00f6r\u00fclbel\u00fcl 6, azaz hogy mikor kezdj\u00fck el haszn\u00e1lni a swap-ot a megmaradt mem\u00f3ria f\u00fcggv\u00e9ny\u00e9ben. Jelenleg azt javasoljuk, hogy \u00e1ll\u00edtsuk a vm.swappiness-t 1-re, mert ez gyakorlatilag kikapcsolja, de nem okoz olyan hat\u00e1sokat, mint az v\u00e1ratlanul \u00e9rkez\u0151 OOM-killer \u00e9s az \u00f6sszes t\u00f6bbi dolog le\u00e1ll\u00edt\u00e1sa.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Mi a k\u00f6vetkez\u0151 l\u00e9p\u00e9s? Amikor az adatb\u00e1zisok teljes\u00edtm\u00e9ny\u00e9r\u0151l besz\u00e9l\u00fcnk, \u00e9s fokozatosan el\u00e9rkez\u00fcnk a lemezekhez, mindenki a fej\u00e9t fogja. Az igazs\u00e1g az, hogy a lemez lass\u00fa, m\u00edg a mem\u00f3ria gyors, mindenkinek ismer\u0151s. Mindenki tudja, hogy az adatb\u00e1zisokban probl\u00e9m\u00e1k mer\u00fclnek fel a lemezes teljes\u00edtm\u00e9nnyel.<\/p>\n
<\/p>\n
A PostgreSQL teljes\u00edtm\u00e9nye szempontj\u00e1b\u00f3l a f\u0151 probl\u00e9ma a checkpointok cs\u00facsain\u00e1l nem a lemez lass\u00fas\u00e1g\u00e1b\u00f3l ad\u00f3dik. Ink\u00e1bb abb\u00f3l, hogy a mem\u00f3ria \u00e9s a lemez kapacit\u00e1sa nincs egyens\u00falyban. Ez k\u00fcl\u00f6nb\u00f6z\u0151 helyeken el\u0151fordulhat. A PostgreSQL nem megfelel\u0151en van be\u00e1ll\u00edtva, az oper\u00e1ci\u00f3s rendszer nincs megfelel\u0151en konfigur\u00e1lva, a hardver nem megfelel\u0151, \u00e9s a hardver is rosszul van kiv\u00e1lasztva. Ez a probl\u00e9ma csak akkor nem mer\u00fcl fel, ha minden \u00fagy t\u00f6rt\u00e9nik, ahogy kell: vagy nincs terhel\u00e9s, vagy a be\u00e1ll\u00edt\u00e1sok \u00e9s a hardver j\u00f3l vannak kiv\u00e1lasztva. <\/p>\n
<\/p>\n
<\/p>\n
Mi ez \u00e9s hogyan n\u00e9z ki? \u00c1ltal\u00e1ban akik PostgreSQL-lel dolgoznak, t\u00f6bbsz\u00f6r is belefutnak ebbe. Megmagyar\u00e1zom. Ahogy m\u00e1r eml\u00edtettem, a PostgreSQL id\u0151nk\u00e9nt v\u00e9grehajtja a checkpointokat, hogy a megosztott mem\u00f3ri\u00e1ban l\u00e9v\u0151 szennyezett lapokat lementse a lemezre. Ha nagy mennyis\u00e9g\u0171 megosztott mem\u00f3ri\u00e1nk van, akkor a checkpoint intenz\u00edven hat a lemezre, mert a lapokat fsync seg\u00edts\u00e9g\u00e9vel \u00edrja le. Ezek a kernel pufferbe \u00e9rkeznek, \u00e9s az fsync seg\u00edts\u00e9g\u00e9vel \u00edr\u00f3dnak a lemezekre. Ha ennek a mennyis\u00e9ge nagy, akkor kellemetlen hat\u00e1st tapasztalhatunk, nevezetesen, hogy a lemezek kihaszn\u00e1lts\u00e1ga nagyon magas.<\/p>\n
<\/p>\n
Itt van k\u00e9t k\u00e9pem. Most megmagyar\u00e1zom, mit jelent ez. Ezek id\u0151ben korrel\u00e1lt grafikonok. Az els\u0151 grafikon a lemez kihaszn\u00e1lts\u00e1g\u00e1t mutatja. Itt majdnem 90%-ra emelkedik ebben az id\u0151pontban. Ha az adatb\u00e1zisa fizikailag lemezekkel rendelkezik, \u00e9s a RAID-vez\u00e9rl\u0151 lemez kihaszn\u00e1lts\u00e1ga 90% k\u00f6r\u00fcl van, akkor rossz h\u00edrek vannak. Ez azt jelenti, hogy hamarosan el\u00e9rj\u00fck a 100%-ot, \u00e9s a bemenet-kimenet meg\u00e1ll. <\/p>\n
<\/p>\n
Ha van lemezmeghajt\u00f3-rendszere, akkor ott egy kicsit m\u00e1s t\u00f6rt\u00e9net van. Ez att\u00f3l f\u00fcgg, hogyan van be\u00e1ll\u00edtva, milyen rendszer \u00e9s \u00edgy tov\u00e1bb. <\/p>\n
<\/p>\n
Egy p\u00e1rhuzamos grafikon van konfigur\u00e1lva a bels\u0151 Postgres n\u00e9zetb\u0151l, amely megmutatja, hogyan zajlik a checkpoint. Z\u00f6ld sz\u00ednnel van felt\u00fcntetve, hogy az adott checkpoint sor\u00e1n mennyi buffer, azaz piszkos oldal \u00e9rkezett a szinkroniz\u00e1ci\u00f3hoz. Ez a legfontosabb, amit tudni \u00e9rdemes. L\u00e1tjuk, hogy sok oldal \u00e9rkezett, \u00e9s egy ponton el\u00e9rt\u00fck a hat\u00e1rt, azaz \u00edrtunk-\u00edrtunk, a lemezes rendszer nyilv\u00e1nval\u00f3an nagyon elfoglalt volt. A checkpoint jelent\u0151sen hat a lemezre. Ide\u00e1lis esetben a helyzet ink\u00e1bb \u00edgy n\u00e9zne ki, azaz kevesebb \u00edr\u00e1s t\u00f6rt\u00e9nt volna. A be\u00e1ll\u00edt\u00e1sainkkal ezt megjav\u00edthatjuk, hogy a j\u00f6v\u0151ben \u00edgy legyen. Azaz az kihaszn\u00e1l\u00e1s alacsony, de valahol \u00edrunk. <\/p>\n
<\/p>\n
Mit kell tenni a probl\u00e9ma megold\u00e1s\u00e1hoz? Ha le\u00e1llt az IO az adatb\u00e1zis alatt, akkor ez azt jelenti, hogy minden felhaszn\u00e1l\u00f3nak, aki v\u00e9grehajtja a lek\u00e9rdez\u00e9seit, v\u00e1rakoznia kell. <\/p>\n
<\/p>\n
<\/p>\n
Ha a Linux szempontj\u00e1b\u00f3l vizsg\u00e1ljuk, ha j\u00f3 hardvert v\u00e1lasztott, helyesen \u00e1ll\u00edtotta be, \u00e9s norm\u00e1lisan konfigur\u00e1lta a PostgreSQL-t, hogy ritk\u00e1bban v\u00e9gezzen checkpointokat, \u00e9s azokat sz\u00e9tsz\u00f3rja az id\u0151ben, akkor a Debian alap\u00e9rtelmezett param\u00e9tereivel tal\u00e1lkozik. A legt\u00f6bb Linux disztrib\u00faci\u00f3 eset\u00e9ben ez a k\u00e9p: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Mit jelent ez? A 2.6 verzi\u00f3t\u00f3l kezdve megjelent egy d\u00e9mon, amely a t\u00f6rl\u00e9s\u00e9rt felel\u0151s. A Pdglush, att\u00f3l f\u00fcgg\u0151en, hogy ki mit haszn\u00e1l, amely a piszkos oldalak h\u00e1tt\u00e9rb\u0151l t\u00f6rt\u00e9n\u0151 t\u00f6rl\u00e9s\u00e9vel foglalkozik, \u00e9s akkor t\u00f6rli, amikor m\u00e1r minden\u00e1ron t\u00f6r\u00f6lni kell a piszkos oldalakat, amikor a h\u00e1tt\u00e9rben t\u00f6rt\u00e9n\u0151 t\u00f6rl\u00e9s m\u00e1r nem seg\u00edt. <\/p>\n
<\/p>\n
Mikor l\u00e9p \u00e9letbe a h\u00e1tt\u00e9r? Amikor a szerver teljes mem\u00f3ri\u00e1j\u00e1nak 10%-a piszkos oldalakkal van elfoglalva a kernel bufferben, akkor egy speci\u00e1lis h\u00e1tt\u00e9rbeli t\u00f6rl\u00e9si funkci\u00f3 l\u00e9p m\u0171k\u00f6d\u00e9sbe. Mi\u00e9rt h\u00e1tt\u00e9rbeli? Mert param\u00e9terk\u00e9nt meghat\u00e1rozza, hogy h\u00e1ny oldalt kell t\u00f6r\u00f6lni. P\u00e9ld\u00e1ul N oldalt t\u00f6r\u00f6l, majd egy id\u0151re alszik. Azt\u00e1n \u00fajra megjelenik \u00e9s t\u00f6r\u00f6l m\u00e9g n\u00e9h\u00e1ny oldalt. <\/p>\n
<\/p>\n
Ez egy rendk\u00edv\u00fcl egyszer\u0171 t\u00f6rt\u00e9net. Olyan ez, mint egy medenc\u00e9vel, ahol az egyik cs\u0151b\u0151l folyik be a v\u00edz, a m\u00e1sik cs\u0151b\u0151l pedig t\u00e1vozik. A checkpoint meg\u00e9rkezett, \u00e9s ha csak kev\u00e9s piszkos oldalt k\u00fcld\u00f6tt el t\u00f6rl\u00e9sre, akkor fokozatosan a kernel bufferb\u0151l a pgflush \u00fcgyesen elsziv\u00e1rog bel\u0151le. <\/p>\n
<\/p>\n
Ha ezek a piszkos oldalak tov\u00e1bbra is felhalmoz\u00f3dnak, akkor el\u00e9rhetik a 20%-ot, \u00e9s ekkor az oper\u00e1ci\u00f3s rendszer priorit\u00e1sa az, hogy a lemezekre \u00edrja ezeket, mert ha megszakad az \u00e1ramell\u00e1t\u00e1s, minden rosszul fog v\u00e9gz\u0151dni. Ezen adatok elvesztes\u00e9g\u00e9r\u0151l van sz\u00f3, p\u00e9ld\u00e1ul. <\/p>\n
<\/p>\n
Mi a tr\u00fckk? A tr\u00fckk abban rejlik, hogy ezek a param\u00e9terek a mai vil\u00e1gban 20 \u00e9s 10 % az eg\u00e9sz g\u00e9p mem\u00f3ria mennyis\u00e9g\u00e9b\u0151l, teljes m\u00e9rt\u00e9kben megd\u00f6bbent\u0151 a b\u00e1rmely t\u00e1rol\u00f3rendszer \u00e1tviteli kapacit\u00e1sa szempontj\u00e1b\u00f3l.<\/strong> <\/p>\n<\/p>\n
K\u00e9pzelje el, hogy 128 GB RAM-ja van. 12,8 GB jut el a t\u00e1rol\u00f3rendszer\u00e9hez. \u00c9s b\u00e1rmilyen gyors\u00edt\u00f3t\u00e1r is van ott, b\u00e1rmilyen t\u00f6mb, nem fogj\u00e1k elviselni azt az mennyis\u00e9get. <\/p>\n
<\/p>\n
<\/p>\n
Ez\u00e9rt mi azt aj\u00e1nljuk, hogy ezek a sz\u00e1mok az \u00f6n RAID vez\u00e9rl\u0151j\u00e9nek lehet\u0151s\u00e9gei szerint legyenek be\u00e1ll\u00edtva.<\/strong> Itt r\u00f6gt\u00f6n egy aj\u00e1nl\u00e1som van egy olyan vez\u00e9rl\u0151h\u00f6z, amelyn\u00e9l 512 MB a gyors\u00edt\u00f3t\u00e1r. <\/p>\n<\/p>\n
Mindez nagyon egyszer\u0171en sz\u00e1m\u00edthat\u00f3. A vm.dirty_background-ot byte-ban lehet be\u00e1ll\u00edtani. Ezek a be\u00e1ll\u00edt\u00e1sok fel\u00fcl\u00edrj\u00e1k az el\u0151z\u0151 kett\u0151t. Vagy alap\u00e9rtelmezett ar\u00e1ny, vagy azok, amelyek byte-ban vannak, ha akt\u00edvak, akkor csak azok fognak m\u0171k\u00f6dni. De mivel \u00e9n DBA tan\u00e1csad\u00f3 vagyok \u00e9s k\u00fcl\u00f6nf\u00e9le \u00fcgyfelekkel dolgozom, pr\u00f3b\u00e1lok el\u0151vigy\u00e1zatos lenni, \u00e9s ez\u00e9rt, ha byte-ban, akkor csak byte-ban. Senki nem garant\u00e1lta, hogy egy kedves admin nem ad hozz\u00e1 mem\u00f3ri\u00e1t a szerverhez, nem ind\u00edtja \u00fajra, \u00e9s a sz\u00e1m ugyanaz marad. Csak ezeket a sz\u00e1mokat \u00fagy kalkul\u00e1lja, hogy biztos legyen benne, hogy minden belef\u00e9r. <\/p>\n
<\/p>\n
Mi t\u00f6rt\u00e9nik, ha nem f\u00e9r bele? \u00cdrtam, hogy b\u00e1rmely flushing hat\u00e9konyan meg\u00e1ll, de val\u00f3j\u00e1ban ez egy k\u00f6zhely. Az oper\u00e1ci\u00f3s rendszernek nagy probl\u00e9m\u00e1ja van \u2013 sok piszkos oldala van, ez\u00e9rt hat\u00e9konyan az \u00fcgyfelei \u00e1ltal gener\u00e1lt IO \u00e1ll meg, teh\u00e1t amikor egy sql lek\u00e9rdez\u00e9st k\u00fcld az alkalmaz\u00e1s, v\u00e1rakozik. B\u00e1rmilyen bemenet-kimenet e fel\u00e9 \u2013 a legnagyobb priorit\u00e1ssal, mert az adatb\u00e1zis foglalt checkpointokkal. \u00c9s hogy mikor fejezi be, az teljesen bizonytalan. \u00c9s amikor el\u00e9rte a nem h\u00e1tt\u00e9r, nem h\u00e1tt\u00e9r flushing-ot, ami azt jelenti, hogy minden IO ezzel van elfoglalva. \u00c9s am\u00edg be nem fejez\u0151dik, nem tud semmit csin\u00e1lni. <\/p>\n
<\/p>\n
Itt van m\u00e9g k\u00e9t fontos szempont, amelyek t\u00fall\u00e9pnek ezen a jelent\u00e9sen. Ezeknek a be\u00e1ll\u00edt\u00e1soknak meg kell felelni\u00fck a postgresql.conf be\u00e1ll\u00edt\u00e1sainak, teh\u00e1t a checkpointok be\u00e1ll\u00edt\u00e1sainak. \u00c9s a t\u00e1rol\u00f3rendszere megfelel\u0151en legyen be\u00e1ll\u00edtva. Ha RAID cache van, akkor ahhoz akkumul\u00e1tor is kell.<\/strong> Az emberek akkumul\u00e1tor n\u00e9lk\u00fcli, j\u00f3 cache-el rendelkez\u0151 RAID-et v\u00e1s\u00e1rolnak. Ha SSD van RAID-ben, akkor azokat szerver SSD-k\u00e9nt kell haszn\u00e1lni, \u00e9s kondenz\u00e1torokkal kell rendelkezni\u00fck.<\/strong> Itt egy r\u00e9szletes ellen\u0151rz\u0151lista tal\u00e1lhat\u00f3. Ezen a linken van a jelent\u00e9sem arr\u00f3l, hogyan kell be\u00e1ll\u00edtani a PostgreSQL lemez teljes\u00edtm\u00e9ny\u00e9t. Az \u00f6sszes ellen\u0151rz\u0151lista ott tal\u00e1lhat\u00f3. <\/p>\n<\/p>\n
<\/p>\n
Mi az, ami m\u00e9g jobban megnehez\u00edtheti az \u00e9letet? K\u00e9t viszonylag \u00faj param\u00e9ter. Ezek k\u00fcl\u00f6nb\u00f6z\u0151 alkalmaz\u00e1sokban alap\u00e9rtelmez\u00e9s szerint be vannak kapcsolva. Ha helytelen\u00fcl vannak be\u00e1ll\u00edtva, akkor legal\u00e1bb annyira megnehez\u00edthetik az \u00e9letet. <\/p>\n
<\/p>\n
<\/p>\n
K\u00e9t viszonylag \u00faj dolog van. Ezek m\u00e1r a harmadik kernelben megjelentek. Ezek a sched_migration_cost nano- m\u00e1sodpercben \u00e9s a sched_autogroup_enabled, ami alap\u00e9rtelmez\u00e9s szerint 1. <\/p>\n
<\/p>\n
\u00c9s hogyan rontj\u00e1k el az \u00e9letet? Mi az a sched_migration_cost? A Linux \u00fctemez\u0151 k\u00e9pes a folyamatokat egyik CPU-r\u00f3l a m\u00e1sikra migr\u00e1lni. A PostgreSQL, amely v\u00e9grehajtja a lek\u00e9rdez\u00e9seket, sz\u00e1m\u00e1ra a m\u00e1sik CPU-ra val\u00f3 migr\u00e1ci\u00f3 teljesen \u00e9rthetetlen. Egy adatb\u00e1zis sz\u00e1m\u00e1ra ez nagyon rossz.<\/strong> Ez\u00e9rt \u00e9sszer\u0171 politik\u00e1nak tekinthet\u0151, hogy a migration_cost-ot egy nagy \u00e9rt\u00e9kre \u00e1ll\u00edtjuk, legal\u00e1bb n\u00e9h\u00e1ny ezer nano- m\u00e1sodpercre.<\/strong> <\/p>\n<\/p>\n
Mit jelent ez az \u00fctemez\u0151 sz\u00e1m\u00e1ra? Azt fogja sz\u00e1m\u00edtani, hogy ez id\u0151 alatt ez a folyamat m\u00e9g mindig akt\u00edv. Teh\u00e1t, ha van egy hossz\u00fa tranzakci\u00f3, amely valami hossz\u00fa ideig tart, az \u00fctemez\u0151 ezt meg fogja \u00e9rteni. Azt fogja hinni, hogy am\u00edg ez az id\u0151tartam le nem j\u00e1r, addig ezt a folyamatot nem sz\u00fcks\u00e9ges migr\u00e1lni. Ha a folyamat k\u00f6zben valamit csin\u00e1l, akkor nem fog migr\u00e1lni, nyugodtan befejezi a munk\u00e1j\u00e1t azon a CPU-n, amelyet kijel\u00f6ltek neki. Az eredm\u00e9ny pedig kiv\u00e1l\u00f3. <\/p>\n
<\/p>\n
A m\u00e1sik pont az autogroup. Van egy j\u00f3 \u00f6tlet specifikus munkaterhel\u00e9sekhez, amelyek nem vonatkoznak a modern adatb\u00e1zisokra \u2013 a folyamatok csoportos\u00edt\u00e1sa aszerint, hogy melyik virtu\u00e1lis termin\u00e1lr\u00f3l ind\u00edtott\u00e1k \u0151ket. Ez hasznos bizonyos feladatokhoz. Gyakorlatilag a PostgreSQL egy t\u00f6bbprocesszoros rendszer preforkkal, amely egy termin\u00e1lb\u00f3l indul. \u00d6nnek van egy lock writer, checkpoint, \u00e9s minden kliens k\u00e9r\u00e9s egy \u00fctemez\u0151re, egy CPU-ra csoportosul. Ott fognak bar\u00e1ts\u00e1gosan v\u00e1rakozni, am\u00edg felszabadul, hogy akad\u00e1lyozz\u00e1k egym\u00e1st, \u00e9s hogy tov\u00e1bb foglalj\u00e1k azt. Ez a t\u00f6rt\u00e9net teljesen felesleges ilyen terhel\u00e9s eset\u00e9n, ez\u00e9rt ezt ki kell kapcsolni.<\/strong><\/p>\n<\/p>\n
<\/p>\n
A koll\u00e9g\u00e1m, Alekszej Leszovszkij, tesztelt egy egyszer\u0171 pgbench-t, ahol t\u00edzszeres\u00e9re n\u00f6velte a migration_cost-ot \u00e9s kikapcsolta az autogroupot. A gyenge hardveren a k\u00fcl\u00f6nbs\u00e9g k\u00f6zel 10% volt.<\/strong>. Van egy megbesz\u00e9l\u00e9s a PostgreSQL levelez\u0151list\u00e1j\u00e1n, ahol az emberek bemutatj\u00e1k az eredm\u00e9nyeket, hogy ilyen m\u00f3dos\u00edt\u00e1sok hogyan befoly\u00e1solt\u00e1k a lek\u00e9rdez\u00e9s sebess\u00e9g\u00e9t. 50%-kal.<\/strong>. Ilyen t\u00f6rt\u00e9netekb\u0151l el\u00e9g sok van.<\/p>\n<\/p>\n
<\/p>\n
V\u00e9g\u00fcl a teljes\u00edtm\u00e9nymegtakar\u00edt\u00e1si politik\u00e1r\u00f3l. J\u00f3, hogy most a Linux haszn\u00e1lhat\u00f3 laptopon. Azt mondj\u00e1k, j\u00f3l fogja fogyasztani az akkut. De v\u00e1ratlanul kider\u00fcl, hogy ez a szerveren is el\u0151fordulhat. <\/p>\n
<\/p>\n
S\u0151t, ha b\u00e9rel szervereket egy hostingt\u00f3l, akkor a \u201ekedves\u201d hosztol\u00f3 c\u00e9gek,<\/a> nem t\u00f6r\u0151dnek azzal, hogy jobb teljes\u00edtm\u00e9nye legyen. Az \u0151 feladatuk, hogy a hardver\u00fck maxim\u00e1lisan hat\u00e9konyan hasznosuljon. Ez\u00e9rt alap\u00e9rtelmez\u00e9s szerint bekapcsolhatj\u00e1k az energia megtakar\u00edt\u00f3 m\u00f3dot az oper\u00e1ci\u00f3s rendszerben.<\/p>\n<\/p>\n
Ha olyan szervert haszn\u00e1l, amelynek intenz\u00edv terhel\u00e9se van az adatb\u00e1zissal, akkor a v\u00e1laszt\u00e1sa az acpi_cpufreq + performance. M\u00e9g az ondemand is m\u00e1r probl\u00e9m\u00e1kat okoz.<\/strong> <\/p>\n<\/p>\n
Az Intel_pstate m\u00e1r egy kicsit m\u00e1sik meghajt\u00f3. Jelenleg ezt r\u00e9szes\u00edtik el\u0151nyben, mivel \u00fajabb \u00e9s jobban m\u0171k\u00f6dik.<\/p>\n
<\/p>\n
\u00cdgy a governor csak teljes\u00edtm\u00e9ny. Az ondemand, powersave \u00e9s minden egy\u00e9b \u2013 nem \u00f6nnek val\u00f3. <\/p>\n
<\/p>\n
Az explain analyze PostgreSQL eredm\u00e9nyei n\u00e9h\u00e1ny nagys\u00e1grenddel elt\u00e9rhetnek, ha bekapcsolja a powersave-t, mert a CPU teljesen kisz\u00e1m\u00edthatatlan m\u00f3don \u00fctemez\u0151dik az adatb\u00e1zis alatt.<\/p>\n
<\/p>\n
Ezek a dolgok alap\u00e9rtelmez\u00e9s szerint be lehetnek kapcsolva. Figyelmesen n\u00e9zze meg \u2013 nem kapcsolt\u00e1k-e be alap\u00e9rtelmezettk\u00e9nt. Ez val\u00f3ban nagy probl\u00e9ma lehet. <\/p>\n
<\/p>\n
<\/p>\n
A v\u00e9g\u00e9n szeretn\u00e9m megk\u00f6sz\u00f6nni a DBA csapatunknak, a PosgreSQL-Consultingnak, k\u00fcl\u00f6n\u00f6sen Makszim Boguknak \u00e9s Alekszej Leszovszkijnak, akik nap mint nap tapasztalatokat szereznek ezen a ter\u00fcleten. Az \u00fcgyfeleink sz\u00e1m\u00e1ra igyeksz\u00fcnk mindent megtenni, hogy a lehet\u0151 legjobban m\u0171k\u00f6dj\u00f6n sz\u00e1mukra. Ez olyan, mint a l\u00e9gi k\u00f6zleked\u00e9s biztons\u00e1gi el\u0151\u00edr\u00e1sai. Minden le van \u00edrva a legrosszabb tapasztalatok alapj\u00e1n. Minden egyes csavar egy probl\u00e9m\u00e1s eset sor\u00e1n ker\u00fclt el\u0151. \u00d6r\u00f6mmel osztom meg ezeket veletek.<\/p>\n
<\/p>\n
K\u00e9rd\u00e9sek:<\/p>\n
<\/p>\n
K\u00f6sz\u00f6n\u00f6m! Ha p\u00e9ld\u00e1ul egy c\u00e9g szeretne megtakar\u00edtani \u00e9s egy szerveren helyezn\u00e9 el az adatb\u00e1zist \u00e9s az alkalmaz\u00e1s logik\u00e1t, vagy ha a c\u00e9g a mikroszolg\u00e1ltat\u00e1s-architekt\u00far\u00e1k divatos tendenci\u00e1j\u00e1t k\u00f6veti, ahol a PostgreSQL kont\u00e9nerben fut. Mi az \u00f6tlet? A sysctl glob\u00e1lisan hat minden magra. Nem hallottam arr\u00f3l, hogy a sysctl virtualiz\u00e1lva lenne, hogy k\u00fcl\u00f6n-k\u00fcl\u00f6n m\u0171k\u00f6dj\u00f6n a kont\u00e9neren bel\u00fcl. Csak cgroup van, \u00e9s ott csak r\u00e9szleges ellen\u0151rz\u00e9s van. Hogyan \u00e9lhet\u00fcnk ezzel? Vagy ha teljes\u00edtm\u00e9nyre v\u00e1gyik, akkor futtassa a PostgreSQL-t egy k\u00fcl\u00f6n fizikai szerveren \u00e9s optimaliz\u00e1lja azt?<\/em><\/p>\n<\/p>\n
H\u00e1romf\u00e9lek\u00e9ppen v\u00e1laszoltunk a k\u00e9rd\u00e9s\u00e9re. Ha nem egy olyan fizikai szerverr\u0151l van sz\u00f3, amelyet optimaliz\u00e1lni lehet, akkor nyugodjon meg, ezek a be\u00e1ll\u00edt\u00e1sok n\u00e9lk\u00fcli m\u0171k\u00f6d\u00e9s is j\u00f3l fog alakulni. Ha olyan terhel\u00e9s ad\u00f3dik, amely megk\u00f6veteli ezeket a be\u00e1ll\u00edt\u00e1sokat, akkor hamarabb eljut egy fizikai szerverhez, mint ezekhez a be\u00e1ll\u00edt\u00e1sokhoz.<\/p>\n
<\/p>\n
Mi a probl\u00e9ma? Ha ez egy virtu\u00e1lis g\u00e9p, akkor val\u00f3sz\u00edn\u0171leg sok probl\u00e9m\u00e1ja lesz, p\u00e9ld\u00e1ul a legt\u00f6bb virtu\u00e1lis g\u00e9p \u00e1ltal\u00e1ban inkonzisztens lemezk\u00e9sleked\u00e9ssel k\u00fczd. M\u00e9g ha a lemez\u00e1tvitel j\u00f3 is, egy hib\u00e1s bevitel-kimenet tranzakci\u00f3, amely nem sokat befoly\u00e1sol az \u00e1tlagos \u00e1tvitel sebess\u00e9g\u00e9n, er\u0151sen megviselheti az adatb\u00e1zist, k\u00fcl\u00f6n\u00f6sen egy checkpoint vagy WAL \u00edr\u00e1s k\u00f6zben. Ezt \u00e9szre fogja venni, miel\u0151tt m\u00e9g belefutna a probl\u00e9m\u00e1kba. <\/p>\n
<\/p>\n
Ha az NGINX ugyanazon a szerveren fut, akkor ugyanez a probl\u00e9ma fogja \u00e9rni. Harcolni fog a k\u00f6z\u00f6s mem\u00f3ri\u00e1\u00e9rt. \u00c9s nem fog eljutni azokhoz a probl\u00e9m\u00e1khoz, amelyeket itt le\u00edrtunk.<\/p>\n
<\/p>\n
De a m\u00e1sik oldalr\u00f3l n\u00e9zve, ezek k\u00f6z\u00fcl n\u00e9h\u00e1ny param\u00e9ter \u00edgy is relev\u00e1ns lesz sz\u00e1modra. P\u00e9ld\u00e1ul a sysctl seg\u00edts\u00e9g\u00e9vel \u00e1ll\u00edtsd be a dirty_ratio-t, hogy ne legyen olyan eszeveszett \u2013 ez minden esetben seg\u00edt. \u00cdgy vagy \u00fagy, kapcsolatban leszel a lemezzel. \u00c9s ez nem a megfelel\u0151 sch\u00e9ma szerint fog zajlani. Ezek egy\u00e1ltal\u00e1n nem az alap\u00e9rtelmezett param\u00e9terek, amelyeket bemutattam. \u00c9s egy\u00e9bk\u00e9nt ezeket jobb megv\u00e1ltoztatni. <\/p>\n
<\/p>\n
A NUMA-val probl\u00e9m\u00e1k mer\u00fclhetnek fel. A VmWare p\u00e9ld\u00e1ul j\u00f3l m\u0171k\u00f6dik NUMA-val, pontosan ellenkez\u0151 be\u00e1ll\u00edt\u00e1sokkal. Itt v\u00e1lasztani kell \u2013 f\u00e9m szerver vagy nem f\u00e9m szerver. <\/p>\n
<\/p>\n
K\u00e9rd\u00e9sem van az Amazon AWS-hez kapcsol\u00f3d\u00f3an. Van ott el\u0151re be\u00e1ll\u00edtott image. Az egyik Amazon RDS n\u00e9vre hallgat. Vannak ott valamilyen testreszabott be\u00e1ll\u00edt\u00e1sok az oper\u00e1ci\u00f3s rendszer\u00fckh\u00f6z?<\/em><\/p>\n<\/p>\n
Vannak be\u00e1ll\u00edt\u00e1sok, de ezek m\u00e1s be\u00e1ll\u00edt\u00e1sok. Itt az oper\u00e1ci\u00f3s rendszert \u00fagy \u00e1ll\u00edtjuk be, ahogy az adatb\u00e1zis haszn\u00e1lni fogja ezt az eg\u00e9sz dolgot. Ott vannak param\u00e9terek, amelyek meghat\u00e1rozz\u00e1k, hov\u00e1 menj\u00fcnk most, egyfajta shaping. Teh\u00e1t annyi er\u0151forr\u00e1sra van sz\u00fcks\u00e9g\u00fcnk, \u00e9s ezeket most ki fogjuk haszn\u00e1lni. Ezt k\u00f6vet\u0151en az Amazon RDS ezekhez az er\u0151forr\u00e1sokhoz kapcsol\u00f3dik, \u00e9s ott a teljes\u00edtm\u00e9ny cs\u00f6kken. Vannak k\u00fcl\u00f6nb\u00f6z\u0151 t\u00f6rt\u00e9netek, ahogy az emberek elkezdik ezt manipul\u00e1lni. N\u00e9ha m\u00e9g sikeresen is. De ennek nincs k\u00f6ze az oper\u00e1ci\u00f3s rendszer be\u00e1ll\u00edt\u00e1saihoz. Ez gyakorlatilag a felh\u0151 hackel\u00e9se. Ez egy m\u00e1sik t\u00f6rt\u00e9net.<\/p>\n
<\/p>\n
Mi\u00e9rt nem hat\u00e9konyak a Transparent huge pages a Huge TLB-vel \u00f6sszehasonl\u00edtva?<\/em><\/p>\n<\/p>\n
Nem hat\u00e9konyak. Ezt sokf\u00e9lek\u00e9ppen el lehet magyar\u00e1zni. De a t\u00e9ny az, hogy egyszer\u0171en nem adnak hat\u00e1st. Mi a helyzet a PostgreSQL-lel? Indul\u00e1skor nagy mennyis\u00e9g\u0171 megosztott mem\u00f3ri\u00e1t allok\u00e1l. Az, hogy a Transparent vagy nem transparent \u2013 teljesen l\u00e9nyegtelen. Az a t\u00e9ny, hogy a kezd\u00e9skor allok\u00e1l\u00f3dnak, mindent megmagyar\u00e1z. Ha nagyon sok mem\u00f3ria van \u00e9s \u00fajra kell strukt\u00far\u00e1lni a shared_memory szegmenst, akkor a Transparent huge pages relev\u00e1ns lesz. A PostgreSQL eset\u00e9ben egyszer\u0171en indul\u00e1skor hatalmas r\u00e9szt allok\u00e1l, \u00e9s ennyi, nem t\u00f6rt\u00e9nik ott semmi k\u00fcl\u00f6n\u00f6s. Persze haszn\u00e1lhat\u00f3, de van es\u00e9ly arra, hogy megmarad a curruption shared_memory, amikor \u00fajraallok\u00e1l valamit. A PostgreSQL viszont err\u0151l nem tud.<\/p>\n
Forr\u00e1s: 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