{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"A Linux kernel konfigur\u00e1l\u00e1sa a GlusterFS-hez","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A cikk ford\u00edt\u00e1sa a kurzus megkezd\u00e9se el\u0151tt k\u00e9sz\u00fclt \u00abLinux Rendszeradminisztr\u00e1tor. Professzion\u00e1lis\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"A<\/p>\n

Id\u0151nk\u00e9nt felmer\u00fclnek k\u00e9rd\u00e9sek a Gluster kernelbe\u00e1ll\u00edt\u00e1saival kapcsolatban, \u00e9s hogy sz\u00fcks\u00e9g van-e erre.<\/p>\n

Ilyen sz\u00fcks\u00e9glet ritk\u00e1n fordul el\u0151. A legt\u00f6bb terhel\u00e9s mellett a kernel nagyon j\u00f3l m\u0171k\u00f6dik. Azonban van ennek egy m\u00e1sik oldala is. A Linux kernel t\u00f6rt\u00e9nelmileg hajlamos sok mem\u00f3ri\u00e1t felhaszn\u00e1lni, ha lehet\u0151s\u00e9get adunk neki, bele\u00e9rtve a gyors\u00edt\u00f3t\u00e1raz\u00e1st is mint a teljes\u00edtm\u00e9ny n\u00f6vel\u00e9s\u00e9nek f\u0151 m\u00f3dszer\u00e9t.<\/a><\/noindex><\/p>\n

A legt\u00f6bb esetben ez nagyszer\u0171en m\u0171k\u00f6dik, de nagy terhel\u00e9s eset\u00e9n probl\u00e9m\u00e1khoz vezethet. <\/p>\n

Sz\u00e9lesk\u00f6r\u0171 tapasztalatunk van a mem\u00f3ri\u00e1t nagym\u00e9rt\u00e9kben haszn\u00e1l\u00f3 rendszerekkel, mint p\u00e9ld\u00e1ul CAD, EDA \u00e9s hasonl\u00f3k, amelyek lelassultak nagy terhel\u00e9s alatt. N\u00e9ha probl\u00e9m\u00e1kkal tal\u00e1lkoztunk a Glusterrel is. T\u00f6bb napon \u00e1t figyelve a haszn\u00e1lt mem\u00f3ria \u00e9s a disk wait id\u0151t, t\u00falterhel\u00e9st, hatalmas iowait-et, kernel hib\u00e1kat (kernel oops), fagy\u00e1sokat stb. tapasztaltunk. <\/p>\n

Ez a cikk sok k\u00eds\u00e9rlet eredm\u00e9nye a param\u00e9terek be\u00e1ll\u00edt\u00e1s\u00e1ra, amelyeket k\u00fcl\u00f6nb\u00f6z\u0151 helyzetekben v\u00e9geztek. Ezek a param\u00e9terek nemcsak az \u00e1ltal\u00e1nos reakci\u00f3id\u0151t jav\u00edtott\u00e1k, hanem jelent\u0151sen stabiliz\u00e1lt\u00e1k a klaszter m\u0171k\u00f6d\u00e9s\u00e9t is.<\/p>\n

Amikor a mem\u00f3ria be\u00e1ll\u00edt\u00e1s\u00e1r\u00f3l van sz\u00f3, el\u0151sz\u00f6r a virtu\u00e1lis mem\u00f3ria (VM, virtual memory) alrendszer\u00e9re kell figyelni, amelynek rengeteg lehet\u0151s\u00e9ge van, ami z\u0171rzavart okozhat.<\/p>\n

vm.swappiness<\/h4>\n

\nA parameter vm.swappiness<\/code> meghat\u00e1rozza, hogy a kernel mennyire haszn\u00e1lja a swapot a RAM-hoz k\u00e9pest. Az alap\u00e9rtelmezett k\u00f3dban ezt \u00fagy defini\u00e1lj\u00e1k, mint a \u00abtendency to steal mapped memory\u00bb (a lek\u00e9pzett mem\u00f3ria ellop\u00e1s\u00e1nak hajlama). A magas swappiness \u00e9rt\u00e9k azt jelenti, hogy a kernel hajlamosabb a lek\u00e9pzett oldalak ki\u00fcr\u00edt\u00e9s\u00e9re. Az alacsony swappiness \u00e9rt\u00e9k ezzel ellent\u00e9tes: a kernel kevesebb oldalt fog ki\u00fcr\u00edteni a mem\u00f3ri\u00e1b\u00f3l. M\u00e1s szavakkal, min\u00e9l magasabb az \u00e9rt\u00e9k, vm.swappiness<\/code>, ann\u00e1l ink\u00e1bb fogja a rendszer haszn\u00e1lni a swap-ot.<\/p>\n

A nagy m\u00e9rt\u00e9k\u0171 swap haszn\u00e1lata nem k\u00edv\u00e1natos, mivel hatalmas adatblokkok ker\u00fclnek bet\u00f6lt\u00e9sre \u00e9s ki\u00fcr\u00edt\u00e9sre a RAM-ban. Sokan azt \u00e1ll\u00edtj\u00e1k, hogy a swapiness \u00e9rt\u00e9k\u00e9nek magasnak kell lennie, de tapasztalataim szerint a teljes\u00edtm\u00e9ny n\u00f6vel\u00e9s\u00e9hez a \u00ab0\u00bb be\u00e1ll\u00edt\u00e1s vezet.<\/p>\n

B\u0151vebben itt olvashat \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Azonban ezeket a be\u00e1ll\u00edt\u00e1sokat \u00f3vatosan kell alkalmazni, \u00e9s csak a konkr\u00e9t alkalmaz\u00e1s tesztel\u00e9se ut\u00e1n. Nagy terhel\u00e9s\u0171 streamel\u0151 alkalmaz\u00e1sokn\u00e1l ezt a param\u00e9tert '0'-ra kell \u00e1ll\u00edtani. A '0'-ra \u00e1ll\u00edt\u00e1ssal javul a rendszer v\u00e1laszk\u00e9szs\u00e9ge.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nEz a param\u00e9ter szab\u00e1lyozza azt a mem\u00f3ri\u00e1t, amelyet a kernel haszn\u00e1l a k\u00f6nyvt\u00e1r- \u00e9s indexel\u0151 objektumok (dentry \u00e9s inode) gyors\u00edt\u00f3t\u00e1raz\u00e1s\u00e1ra.<\/p>\n

Alap\u00e9rtelmezett \u00e9rt\u00e9kkel, amely 100, a kernel pr\u00f3b\u00e1lja a dentry \u00e9s inode gyors\u00edt\u00f3t\u00e1rat az 'igazs\u00e1goss\u00e1g' szempontj\u00e1b\u00f3l felszabad\u00edtani a pagecache \u00e9s swapcache-hez k\u00e9pest. A vfs_cache_pressure cs\u00f6kkent\u00e9se azt eredm\u00e9nyezi, hogy a kernel meg\u0151rzi a dentry \u00e9s inode gyors\u00edt\u00f3t\u00e1rakat. Ha az \u00e9rt\u00e9k '0', a kernel soha nem fogja tiszt\u00edtani a dentry \u00e9s inode gyors\u00edt\u00f3t\u00e1rat mem\u00f3ria hi\u00e1nya miatt, \u00e9s ez k\u00f6nnyen mem\u00f3riagyarapod\u00e1s-hib\u00e1hoz vezethet. A vfs_cache_pressure 100-n\u00e1l nagyobb m\u00e9rt\u00e9k\u0171 n\u00f6vel\u00e9se azt eredm\u00e9nyezi, hogy a kernel el\u0151nyben r\u00e9szes\u00edti a dentry \u00e9s inode ki\u00fcr\u00edt\u00e9s\u00e9t.<\/p>\n

GlusterFS haszn\u00e1latakor sok felhaszn\u00e1l\u00f3, akik nagy adatmennyis\u00e9ggel \u00e9s sok kis f\u00e1jllal dolgoznak, k\u00f6nnyen jelent\u0151s mennyis\u00e9g\u0171 RAM-ot haszn\u00e1lhatnak a szerveren az inode\/dentry gyors\u00edt\u00f3t\u00e1raz\u00e1s miatt, ami teljes\u00edtm\u00e9nycs\u00f6kken\u00e9shez vezethet, mivel a kernelnek adatstrukt\u00far\u00e1kat kell kezelnie egy 40 GB-os mem\u00f3ri\u00e1val rendelkez\u0151 rendszerben. E param\u00e9ter 100-on t\u00fali be\u00e1ll\u00edt\u00e1sa sok felhaszn\u00e1l\u00f3nak seg\u00edtett igazs\u00e1gosabb gyors\u00edt\u00f3t\u00e1roz\u00e1st el\u00e9rni \u00e9s jav\u00edtani a kernel v\u00e1laszk\u00e9szs\u00e9g\u00e9t.<\/p>\n

vm.dirty_background_ratio \u00e9s vm.dirty_ratio<\/h4>\n

\nAz els\u0151 param\u00e9ter (vm.dirty_background_ratio<\/code>) meghat\u00e1rozza a mem\u00f3ri\u00e1nak azt a sz\u00e1zal\u00e9k\u00e1t, amely szennyezett oldalakkal rendelkezik, amely el\u00e9rve meg kell kezdeni a szennyezett oldalak h\u00e1tt\u00e9rben t\u00f6rt\u00e9n\u0151 le\u00edr\u00e1s\u00e1t a lemezre. Am\u00edg ez a sz\u00e1zal\u00e9k nem \u00e9rhet\u0151 el, az oldalak nem ker\u00fclnek le\u00edr\u00e1sra a lemezre. Amikor a le\u00edr\u00e1s elkezd\u0151dik, az h\u00e1tt\u00e9rben t\u00f6rt\u00e9nik, an\u00e9lk\u00fcl, hogy megszak\u00edtan\u00e1 a fut\u00f3 folyamatokat. <\/p>\n

A m\u00e1sodik param\u00e9ter (vm.dirty_ratio<\/code>) meghat\u00e1rozza azt a mem\u00f3ria sz\u00e1zal\u00e9kot, amelyet a piszkos oldalak foglalhatnak el a k\u00e9nyszer\u00edtett t\u00f6rl\u00e9s (forced flash) megkezd\u00e9se el\u0151tt. Amint ezt a k\u00fcsz\u00f6b\u00f6t el\u00e9rik, az \u00f6sszes folyamat szinkroniz\u00e1ltt\u00e1 v\u00e1lik (blokkol\u00f3dik), \u00e9s nem folytathatj\u00e1k a munk\u00e1t addig, am\u00edg a k\u00e9rd\u00e9ses bemeneti-kimeneti (I\/O) m\u0171velet t\u00e9nylegesen be nem fejez\u0151dik, \u00e9s az adatok el nem ker\u00fclnek a lemezre. Nagy terhel\u00e9s\u0171 I\/O eset\u00e9n ez probl\u00e9m\u00e1t okozhat, mivel az adatok gyors\u00edt\u00f3t\u00e1raz\u00e1sa hi\u00e1nyzik, \u00e9s az \u00f6sszes I\/O m\u0171veletet v\u00e9gz\u0151 folyamat blokkol\u00f3dik, v\u00e1rva a bemeneti-kimeneti m\u0171veletet. Ez sok felf\u00fcggesztett folyamatot, magas terhel\u00e9st, instabil rendszer m\u0171k\u00f6d\u00e9st \u00e9s gyenge teljes\u00edtm\u00e9nyt eredm\u00e9nyez.<\/p>\n

E param\u00e9terek \u00e9rt\u00e9keinek cs\u00f6kkent\u00e9se azt eredm\u00e9nyezi, hogy az adatok gyakrabban ker\u00fclnek lemezre, \u00e9s nem t\u00e1rol\u00f3dnak a RAM-ban. Ez hasznos lehet olyan rendszerek sz\u00e1m\u00e1ra, amelyek nagy mennyis\u00e9g\u0171 mem\u00f3ri\u00e1val rendelkeznek, ahol norm\u00e1lis a 45\u201390 GB-os oldal gyors\u00edt\u00f3t\u00e1raz\u00e1sa a lemezre, ami \u00f3ri\u00e1si v\u00e1rakoz\u00e1si id\u0151t eredm\u00e9nyez a frontend alkalmaz\u00e1sok sz\u00e1m\u00e1ra, cs\u00f6kkentve ezzel az \u00e1ltal\u00e1nos reakci\u00f3id\u0151t \u00e9s interaktivit\u00e1st.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nAz oldal gyors\u00edt\u00f3t\u00e1r (page cache) az a gyors\u00edt\u00f3t\u00e1r, ahol a f\u00e1jlok \u00e9s programok t\u00e9nyleges tartalma tal\u00e1lhat\u00f3, vagyis ezek a f\u00e1jlok vagy blokkeszk\u00f6z\u00f6k t\u00e9nyleges tartalm\u00fa oldala. Ez a gyors\u00edt\u00f3t\u00e1r a lemezr\u0151l t\u00f6rt\u00e9nt olvas\u00e1sok sz\u00e1m\u00e1nak cs\u00f6kkent\u00e9s\u00e9re szolg\u00e1l. Az \u00ab1\u00bb \u00e9rt\u00e9k azt jelenti, hogy a gyors\u00edt\u00f3t\u00e1r 1% RAM-ot haszn\u00e1l, \u00e9s a diszk olvas\u00e1sokb\u00f3l t\u00f6bb fog t\u00f6rt\u00e9nni, mint a RAM-ba. Ezt a param\u00e9tert nem sz\u00fcks\u00e9ges m\u00f3dos\u00edtani, de ha paranoid m\u00f3don szeretn\u00e9d ellen\u0151rizni az oldal gyors\u00edt\u00f3t\u00e1rat, akkor ezt haszn\u00e1lhatod.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nA bemeneti-kimeneti \u00fctemez\u0151 (I\/O scheduler) a Linux kernel egy \u00f6sszetev\u0151je, amely kezeli az \u00edr\u00e1si \u00e9s olvas\u00e1si sorokat. Elm\u00e9letileg okos RAID-vez\u00e9rl\u0151 eset\u00e9n a \u00abnoop\u00bb haszn\u00e1lata a legjobb, mivel a Linux nem ismeri a lemez fizikai geometri\u00e1j\u00e1t, ez\u00e9rt hat\u00e9konyabb, ha a vez\u00e9rl\u0151, amely j\u00f3l ismeri a lemez geometri\u00e1j\u00e1t, a lehet\u0151 leggyorsabban feldolgozza a k\u00e9r\u00e9seket. De \u00fagy t\u0171nik, hogy a \u00abdeadline\u00bb jav\u00edtja a teljes\u00edtm\u00e9nyt. A tervez\u0151kr\u0151l t\u00f6bbet olvashatsz a Linux kernel forr\u00e1sk\u00f3dj\u00e1nak dokument\u00e1ci\u00f3j\u00e1ban: linux\/Documentation\/block\/*osched.txt<\/code>. \u00c9s azt is \u00e9szleltem, hogy a vegyes m\u0171veletek (sok \u00edr\u00e1si m\u0171velet) sor\u00e1n n\u0151tt az olvas\u00e1si sebess\u00e9g.<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nA bemeneti- \u00e9s kimeneti lek\u00e9rdez\u00e9sek sz\u00e1ma a pufferen, miel\u0151tt a tervez\u0151h\u00f6z ker\u00fcln\u00e9nek. N\u00e9h\u00e1ny vez\u00e9rl\u0151 bels\u0151 sor\u00e1nak (queue_depth) m\u00e9rete nagyobb, mint az I\/O tervez\u0151 nr_requests-e, ez\u00e9rt az I\/O tervez\u0151nek kev\u00e9s lehet\u0151s\u00e9ge van arra, hogy helyesen prioriz\u00e1lja \u00e9s v\u00e9grehajtsa a lek\u00e9rdez\u00e9sek egyes\u00edt\u00e9s\u00e9t. Deadline \u00e9s CFQ tervez\u0151k eset\u00e9n el\u0151ny\u00f6sebb, ha a nr_requests k\u00e9tszer akkora, mint a vez\u00e9rl\u0151 bels\u0151 sora. A lek\u00e9rdez\u00e9sek egyes\u00edt\u00e9se \u00e9s \u00e1trendez\u00e9se seg\u00edt a tervez\u0151nek, hogy nagy terhel\u00e9s mellett is reag\u00e1l\u00f3k\u00e9pesebb legyen.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nA page-cluster param\u00e9ter hat\u00e1rozza meg a lapok sz\u00e1m\u00e1t, amelyeket egyszerre \u00edrunk ki a cserehelyre. A fenti p\u00e9lda szerint az \u00e9rt\u00e9k \u00ab16\u00bb-ra van \u00e1ll\u00edtva, amely a RAID 64 KB-os cs\u00edk m\u00e9ret\u00e9nek megfelel\u0151en van be\u00e1ll\u00edtva. Ez nem logikus, ha a swappiness = 0, de ha a swappiness \u00e9rt\u00e9k\u00e9t 10-re vagy 20-ra \u00e1ll\u00edtotta be, akkor ez a be\u00e1ll\u00edt\u00e1s seg\u00edthet, amikor a RAID cs\u00edk m\u00e9rete 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc vagy dev_mapper)<\/h4>\n

\nA legt\u00f6bb RAID-vez\u00e9rl\u0151 alap\u00e9rtelmezett blokk eszk\u00f6zbe\u00e1ll\u00edt\u00e1sa gyakran borzalmas teljes\u00edtm\u00e9nyt eredm\u00e9nyez. A fent eml\u00edtett opci\u00f3 hozz\u00e1ad\u00e1sa 4096 * 512 b\u00e1jt szektorok el\u0151zetes olvas\u00e1si be\u00e1ll\u00edt\u00e1sait alak\u00edtja. Legal\u00e1bbis a folyamatos m\u0171veletek sor\u00e1n n\u00f6veli a sebess\u00e9get, felt\u00f6ltve a lemez be\u00e9p\u00edtett gyors\u00edt\u00f3t\u00e1r\u00e1t az el\u0151zetes olvas\u00e1s sor\u00e1n, ameddig a kernel az I\/O el\u0151k\u00e9sz\u00edt\u00e9s\u00e9vel foglalkozik. Olyan adatok ker\u00fclhetnek a gyors\u00edt\u00f3t\u00e1rba, amelyeket a k\u00f6vetkez\u0151 olvas\u00e1s sor\u00e1n k\u00e9rnek le. T\u00fal sok el\u0151zetes olvas\u00e1s meg\u00f6lheti a v\u00e9letlenszer\u0171 I\/O-t nagy f\u00e1jlok eset\u00e9ben, ha potenci\u00e1lisan hasznos lemezid\u0151t haszn\u00e1l, vagy az adatokat a gyors\u00edt\u00f3t\u00e1ron k\u00edv\u00fcl bet\u00f6lti.<\/p>\n

Az al\u00e1bbiakban n\u00e9h\u00e1ny tov\u00e1bbi javaslatot tal\u00e1l, amelyeket a f\u00e1jlrendszer szintj\u00e9n \u00e9rdemes figyelembe venni. Ezeket azonban m\u00e9g nem tesztelt\u00e9k. Gy\u0151z\u0151dj\u00f6n meg r\u00f3la, hogy a f\u00e1jlrendszere ismeri a cs\u00edk m\u00e9ret\u00e9t \u00e9s a t\u00f6mbben tal\u00e1lhat\u00f3 lemezek sz\u00e1m\u00e1t. P\u00e9ld\u00e1ul, hogy ez egy raid5 t\u00f6mb 64K cs\u00edkm\u00e9rettel, hat lemezb\u0151l (val\u00f3j\u00e1ban \u00f6t, mivel egy lemez a parit\u00e1sra van fenntartva). Ezek a javaslatok elm\u00e9leti felt\u00e9telez\u00e9seken alapulnak, \u00e9s k\u00fcl\u00f6nb\u00f6z\u0151 RAID szak\u00e9rt\u0151k blogjaib\u00f3l \u00e9s cikkeib\u0151l gy\u0171jt\u00f6tt\u00e9k \u0151ket.<\/p>\n

-> ext4 fs, 5 lemez, 64K cs\u00edk, egys\u00e9gek 4K blokkokban\nmkfs -t ext4 -E stride=$((64\/4))\n-> xfs, 5 lemez, 64K cs\u00edk, egys\u00e9gek 512 b\u00e1jtos szektorokban\nmkfs -t xfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nNagy f\u00e1jlok eset\u00e9n \u00e9rdemes megfontolni a fent megadott cs\u00edkok m\u00e9ret\u00e9nek n\u00f6vel\u00e9s\u00e9t.<\/p>\n
FIGYELEM!<\/b> A fent le\u00edrtak rendk\u00edv\u00fcl szubjekt\u00edvek egyes alkalmaz\u00e1st\u00edpusok eset\u00e9ben. Ez a cikk nem garant\u00e1l javul\u00e1sokat an\u00e9lk\u00fcl, hogy a felhaszn\u00e1l\u00f3 el\u0151zetesen teszteln\u00e9 a megfelel\u0151 alkalmaz\u00e1sokat. Csak akkor aj\u00e1nlott alkalmazni, ha sz\u00fcks\u00e9ges a rendszer \u00e1ltal\u00e1nos v\u00e1laszk\u00e9szs\u00e9g\u00e9nek jav\u00edt\u00e1sa vagy ha a megl\u00e9v\u0151 probl\u00e9m\u00e1kat megoldja.<\/p>\n
Tov\u00e1bbi anyagok:<\/h4>\n
<\/p>\n