{"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\/ro\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configurarea kernel-ului Linux pentru GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Articolul este tradus \u00een cadrul preg\u0103tirii pentru lansarea cursului \u00abAdministrator Linux. Professional\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configurarea<\/p>\n

Occasionally, questions arise regarding Gluster's recommendations on kernel configuration and whether this is necessary.<\/p>\n

Such necessity arises rarely. In most workloads, the kernel performs quite well. However, there is also a downside. Historically, the Linux kernel tends to consume a lot of memory if provided the opportunity, including for caching as a primary means of enhancing performance.<\/a><\/noindex><\/p>\n

In most cases, this works excellently, but under heavy load, it can lead to issues. <\/p>\n

We have extensive experience with memory-intensive systems, such as CAD, EDA, and similar, which started to lag under heavy loads. We occasionally faced issues with Gluster. By closely monitoring memory usage and disk wait times over several days, we encountered overloads, significant iowait, kernel errors (kernel oops), freezes, and so on. <\/p>\n

This article is the result of numerous experiments on parameter tuning conducted in various situations. Thanks to these parameters, not only did overall responsiveness improve, but the stability of the cluster also increased significantly.<\/p>\n

When it comes to memory configuration, the first thing to look at is the virtual memory subsystem (VM), which has a vast number of options that can be bewildering.<\/p>\n

vm.swappiness<\/h4>\n

\nParametru vm.swappiness<\/code> determines how the kernel utilizes swapping relative to physical memory. In the source code, it is also defined as \"tendency to steal mapped memory.\" A high swappiness value means that the kernel is more likely to unload mapped pages. A low swappiness value indicates the opposite: the kernel will unload pages from memory less frequently. In other words, the higher the value vm.swappiness<\/code>, the more the system will use swap.<\/p>\n

Extensive use of swapping is undesirable, as large blocks of data are loaded and unloaded from physical memory. Many argue that the swappiness value should be high, but in my experience, setting it to \"0\" leads to improved performance.<\/p>\n

You can read more about it here \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

\u00cens\u0103, din nou, aceste set\u0103ri trebuie aplicate cu precau\u021bie \u0219i doar dup\u0103 testarea aplica\u021biei specifice. Pentru aplica\u021biile de streaming cu \u00eenc\u0103rcare mare, acest parametru ar trebui setat pe \u201e0\u201d. Schimbarea la \u201e0\u201d \u00eembun\u0103t\u0103\u021be\u0219te capacitatea de r\u0103spuns a sistemului.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nAcest parametru controleaz\u0103 memoria consumat\u0103 de kernel pentru cache-ul obiectelor de catalog \u0219i descriptorii de index (dentry \u0219i inode).<\/p>\n

Cu o valoare implicit\u0103 de 100, kernelul va \u00eencerca s\u0103 elibereze cache-ul dentry \u0219i inode pe \u201ebaza echit\u0103\u021bii\u201d \u00een raport cu pagecache \u0219i swapcache. Reducerea vfs_cache_pressure determin\u0103 kernel-ul s\u0103 p\u0103streze cache-urile dentry \u0219i inode. C\u00e2nd valoarea este \u201e0\u201d, kernelul nu va cur\u0103\u021ba niciodat\u0103 cache-ul dentry \u0219i inode din cauza presiunii de memorie, ceea ce poate duce cu u\u0219urin\u021b\u0103 la o eroare de tip out-of-memory. Cre\u0219terea vfs_cache_pressure peste 100 determin\u0103 kernelul s\u0103 acorde prioritate desc\u0103rc\u0103rii dentry \u0219i inode.<\/p>\n

C\u00e2nd utiliza\u021bi GlusterFS, mul\u021bi utilizatori cu volume mari de date \u0219i multe fi\u0219iere mici pot consuma mult\u0103 memorie RAM pe server din cauza cache-ului inode\/dentry, ceea ce poate duce la o sc\u0103dere a performan\u021bei, deoarece kernel-ul trebuie s\u0103 proceseze structuri de date \u00eentr-un sistem cu 40 GB de memorie. Setarea acestui parametru peste 100 a ajutat mul\u021bi utilizatori s\u0103 ob\u021bin\u0103 o cache mai echitabil\u0103 \u0219i s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 capacitatea de r\u0103spuns a kernelului.<\/p>\n

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

\nPrimul parametru (vm.dirty_background_ratio<\/code>) define\u0219te procentul de memorie cu pagini murdare, atingerea c\u0103ruia trebuie s\u0103 \u00eenceap\u0103 deversarea \u00een fundal a paginilor murdare pe disc. At\u00e2ta timp c\u00e2t acest procent nu este atins, paginile nu sunt deversate pe disc. Iar atunci c\u00e2nd deversarea \u00eencepe, aceasta se desf\u0103\u0219oar\u0103 \u00een fundal, f\u0103r\u0103 a \u00eentrerupe procesele \u00een curs. <\/p>\n

Al doilea parametru (vm.dirty_ratio<\/code>) stabile\u0219te procentul de memorie care poate fi ocupat\u0103 de paginile murdare p\u00e2n\u0103 la \u00eenceputul unui reset for\u021bat (forced flash). Odat\u0103 ce acest prag este atins, toate procesele devin sincrone (blocate) \u0219i nu le este permis s\u0103 continue p\u00e2n\u0103 c\u00e2nd opera\u021bia solicitat\u0103 de intrare-ie\u0219ire nu este efectiv finalizat\u0103 \u0219i datele nu ajung pe disc. \u00cen cazul unor cereri de intrare-ie\u0219ire intense, apare o problem\u0103, deoarece caching-ul datelor este absent \u0219i toate procesele care efectueaz\u0103 intrare-ie\u0219ire sunt blocate a\u0219tept\u00e2nd intrarea-ie\u0219ire. Acest lucru duce la un num\u0103r mare de procese suspendate, o sarcin\u0103 ridicat\u0103, func\u021bionarea instabil\u0103 a sistemului \u0219i o performan\u021b\u0103 slab\u0103.<\/p>\n

Reducerea valorilor acestor parametrii duce la faptul c\u0103 datele sunt scrise pe disc mai frecvent \u0219i nu sunt p\u0103strate \u00een RAM. Acest lucru poate ajuta sistemele cu o cantitate mare de memorie, pentru care este normal s\u0103 scrie pe disc cache-ul paginilor de 45\u201390 GB, ceea ce duce la timpi enormi de a\u0219teptare pentru aplica\u021biile frontend, reduc\u00e2nd r\u0103spunsul general \u0219i interactivitatea.<\/p>\n

\u201e1\u201d > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nCache-ul pe pagini (page cache) este un cache \u00een care sunt stocate datele fi\u0219ierelor \u0219i programelor executabile, adic\u0103 paginile cu con\u021binutul efectiv al fi\u0219ierelor sau dispozitivelor de bloc. Acest cache este utilizat pentru a reduce num\u0103rul de citiri de pe disc. Valorile \u201e1\u201d indic\u0103 faptul c\u0103 pentru cache este folosit 1% din RAM \u0219i c\u0103 vor fi mai multe opera\u021bii de citire de pe disc dec\u00e2t din RAM. Nu este obligatoriu s\u0103 schimbi acest parametru, dar dac\u0103 e\u0219ti foarte preocupat de controlul cache-ului paginilor, po\u021bi s\u0103-l utilizezi.<\/p>\n

\u201edeadline\u201d > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nProgramatorul de intrare-ie\u0219ire (I\/O scheduler) este un component al nucleului Linux care se ocup\u0103 cu cozile de citire \u0219i scriere. Teoretic, pentru un controler RAID inteligent, este mai bine s\u0103 folose\u0219ti \u201enoop\u201d, deoarece Linux nu \u0219tie nimic despre geometria fizic\u0103 a discului, deci este mai eficient s\u0103 permi\u021bi controlerului, care cunoa\u0219te bine geometria discului, s\u0103 proceseze cererea c\u00e2t mai repede posibil. Dar se pare c\u0103 \u201edeadline\u201d \u00eembun\u0103t\u0103\u021be\u0219te performan\u021ba. Po\u021bi citi mai multe despre planificatori \u00een documenta\u021bia codului surs\u0103 al nucleului Linux: linux\/Documentation\/block\/*osched.txt<\/code>. \u0218i am observat, de asemenea, o cre\u0219tere a l\u0103\u021bimii de band\u0103 pentru citiri \u00een timpul opera\u021biunilor mixte (multe opera\u021biuni de scriere).<\/p>\n

\u201e256\u201d > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nNum\u0103rul de cereri de citire-scriere \u00een buffer \u00eenainte de a fi transmise planificatorului. Dimensiunea cozii interne a unor controlere (queue_depth) este mai mare dec\u00e2t nr_requests al planificatorului de citire-scriere, astfel c\u0103 planificatorul de citire-scriere are pu\u021bine \u0219anse de a prioritiza corect \u0219i de a efectua o fuziune a cererilor. Pentru planificatoarele deadline \u0219i CFQ, este mai bine ca nr_requests s\u0103 fie de dou\u0103 ori mai mare dec\u00e2t coada intern\u0103 a controlerului. Fuzionarea \u0219i reorganizarea cererilor ajut\u0103 planificatorul s\u0103 fie mai receptiv la sarcini mari.<\/p>\n

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

\nParametrul page-cluster controleaz\u0103 num\u0103rul de pagini care sunt scrise \u00een swap simultan. \u00cen exemplul de mai sus, valoarea este setat\u0103 la \u201e16\u201d conform dimensiunii stripe-ului (stripe size) RAID de 64 KB. Acest lucru nu are sens c\u00e2nd swappiness = 0, dar dac\u0103 ai setat swappiness la 10 sau 20, utilizarea acestei valori te va ajuta c\u00e2nd dimensiunea stripe-ului RAID este de 64 KB.<\/p>\n

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

\nSet\u0103rile dispozitivelor bloc pe default pentru multe controlere RAID conduc adesea la o performan\u021b\u0103 groaznic\u0103. Ad\u0103ugarea op\u021biunii de mai sus configureaz\u0103 citirea anticipat\u0103 pentru sectoare de 4096 * 512 byte. Cel pu\u021bin pentru opera\u021biuni de streaming, viteza cre\u0219te, umpl\u00e2nd cache-ul intern al discului prin citirea anticipat\u0103 pe perioada utilizat\u0103 de kernel pentru preg\u0103tirea I\/O-ului. \u00cen cache pot fi plasate datele care vor fi solicitate la urm\u0103toarea citire. Citirea anticipat\u0103 prea mare poate distruge I\/O-ul aleator pentru fi\u0219iere mari, dac\u0103 folose\u0219te timpul poten\u021bial util al discului sau \u00eencarc\u0103 date dincolo de cache.<\/p>\n

Iat\u0103 c\u00e2teva recomand\u0103ri suplimentare la nivel de sistem de fi\u0219iere. Dar acestea nu au fost testate \u00eenc\u0103. Asigur\u0103-te c\u0103 sistemul t\u0103u de fi\u0219iere cunoa\u0219te dimensiunea stripe-ului \u0219i num\u0103rul de discuri din raion. De exemplu, c\u0103 acesta este un raion raid5 cu dimensiunea stripe-ului de 64K din \u0219ase discuri (de fapt din cinci, deoarece un disc este utilizat pentru paritate). Aceste recomand\u0103ri se bazeaz\u0103 pe presupuneri teoretice \u0219i sunt adunate din diverse bloguri\/articole ale exper\u021bilor \u00een RAID.<\/p>\n

-> ext4 fs, 5 discuri, 64K stripe, unit\u0103\u021bi \u00een 4K blocuri\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 discuri, 64K stripe, unit\u0103\u021bi \u00een sectoare de 512 byte\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nPentru fi\u0219iere mari, se poate considera posibilitatea de a cre\u0219te dimensiunile stripe-urilor men\u021bionate mai sus.<\/p>\n
ATEN\u021aIE!<\/b> Tot ceea ce a fost descris mai sus este extrem de subiectiv pentru anumite tipuri de aplica\u021bii. Acest articol nu garanteaz\u0103 \u00eembun\u0103t\u0103\u021biri f\u0103r\u0103 testarea prealabil\u0103 a aplica\u021biilor corespunz\u0103toare din partea utilizatorului. Ar trebui aplicat doar \u00een cazul \u00een care este necesar\u0103 \u00eembun\u0103t\u0103\u021birea reac\u021biei generale a sistemului sau dac\u0103 rezolv\u0103 problemele curente.<\/p>\n
Materiale suplimentare:<\/h4>\n
<\/p>\n