Ang pagsasalin ng artikulo ay inihanda sa bisperas ng pagsisimula ng kurso .
Paminsan-minsan, dito at doon, lumilitaw ang mga tanong tungkol sa mga rekomendasyon ni Gluster tungkol sa pag-tune ng kernel at kung may pangangailangan para dito.
Ang ganitong pangangailangan ay bihirang lumitaw. Sa karamihan ng mga workload, ang kernel ay gumaganap nang napakahusay. Bagaman mayroong isang downside. Sa kasaysayan, ang Linux kernel ay handang kumonsumo ng maraming memory kung bibigyan ng pagkakataon, kabilang ang para sa pag-cache bilang pangunahing paraan upang mapabuti ang pagganap.
Sa karamihan ng mga kaso, ito ay gumagana nang maayos, ngunit sa ilalim ng mabigat na pagkarga maaari itong humantong sa mga problema.
Marami kaming karanasan sa mga memory intensive system tulad ng CAD, EDA at iba pa, na nagsimulang bumagal sa ilalim ng mabigat na pagkarga. At kung minsan ay nagkakaproblema kami sa Gluster. Pagkatapos ng maingat na pagmamasid sa paggamit ng memorya at disk latency sa loob ng maraming araw, nakuha namin ang kanilang sobrang karga, malaking iowait, mga error sa kernel (kernel oops), nag-freeze, atbp.
Ang artikulong ito ay resulta ng maraming eksperimento sa pag-tune na isinagawa sa iba't ibang sitwasyon. Salamat sa mga parameter na ito, hindi lamang ang pangkalahatang pagtugon ay bumuti, ngunit ang kumpol ay makabuluhang nagpapatatag din.
Pagdating sa memory tuning, ang unang bagay na titingnan ay ang virtual memory subsystem (VM, virtual memory), na may malaking bilang ng mga opsyon na maaaring malito sa iyo.
vm.swappiness
Parametro vm.swappiness tinutukoy kung gaano ginagamit ng kernel ang swap (swap, paging) kumpara sa RAM. Tinukoy din ito sa source code bilang "tendency to steal mapped memory". Ang mataas na swappiness ay nangangahulugan na ang kernel ay magiging mas hilig na magpalit ng mga nakamapang pahina. Ang isang mababang halaga ng swappiness ay nangangahulugan ng kabaligtaran: ang kernel ay magiging mas kaunti mula sa memorya. Sa madaling salita, mas mataas ang halaga vm.swappiness, mas gagamit ang system ng swap.
Ang isang malaking paggamit ng pagpapalit ay hindi kanais-nais, dahil ang malalaking bloke ng data ay nilo-load at inilabas sa RAM. Maraming tao ang nangangatuwiran na ang halaga ng swapiness ay dapat malaki, ngunit sa aking karanasan, ang pagtatakda nito sa "0" ay humahantong sa mas mahusay na pagganap.
Maaari mong basahin ang higit pa dito -
Ngunit, muli, ang mga setting na ito ay dapat ilapat nang may pag-iingat at pagkatapos lamang ng pagsubok sa isang partikular na aplikasyon. Para sa mga high-load na streaming application, ang parameter na ito ay dapat itakda sa "0". Kapag binago sa "0", bubuti ang pagtugon ng system.
vm.vfs_cache_pressure
Kinokontrol ng setting na ito ang memorya na ginagamit ng kernel para sa pag-cache ng direktoryo at mga inode na bagay (dentry at inode).
Sa isang default na halaga na 100, susubukan ng kernel na palayain ang dentry at inode cache sa isang "patas" na batayan sa pagecache at swapcache. Ang pagbaba ng vfs_cache_pressure ay nagiging sanhi ng kernel na panatilihin ang mga dentry at inode cache. Kapag ang halaga ay "0", ang kernel ay hindi kailanman mag-flush ng dentry at inode cache dahil sa presyon ng memorya, at madali itong humantong sa isang out-of-memory error. Ang pagtaas ng vfs_cache_pressure sa itaas ng 100 ay nagiging sanhi ng kernel na unahin ang dentry at inode flushing.
Kapag gumagamit ng GlusterFS, maraming user na may malaking halaga ng data at maraming maliliit na file ang madaling gumamit ng malaking halaga ng RAM sa server dahil sa inode/dentry caching, na maaaring humantong sa pagkasira ng performance dahil kailangang iproseso ng kernel ang mga istruktura ng data sa isang system na may 40 GB ng memorya. Ang pagtatakda ng halagang ito sa itaas ng 100 ay nakatulong sa maraming user na makamit ang mas patas na pag-cache at pinahusay na pagtugon sa kernel.
vm.dirty_background_ratio at vm.dirty_ratio
Unang parameter (vm.dirty_background_ratio) tinutukoy ang porsyento ng memorya na may maruming mga pahina, pagkatapos maabot kung saan kinakailangan upang simulan ang pag-flush ng mga maruruming pahina sa background sa disk. Hanggang sa maabot ang porsyentong ito, walang mga page na ma-flush sa disk. At kapag nagsimula ang isang pag-reset, tatakbo ito sa background nang hindi nakakaabala sa mga prosesong tumatakbo.
Ang pangalawang parameter (vm.dirty_ratio) ay tumutukoy sa porsyento ng memorya na maaaring sakupin ng mga maruruming pahina bago magsimula ang sapilitang flash. Kapag naabot na ang threshold na ito, ang lahat ng proseso ay magiging kasabay (na-block) at hindi pinapayagang magpatuloy hanggang sa aktwal na nakumpleto ang I/O na kanilang hiniling at ang data ay nasa disk. Sa mabigat na I/O, nagdudulot ito ng problema dahil walang data caching at lahat ng prosesong gumagawa ng I/O ay na-block habang naghihintay ng I/O. Ito ay humahantong sa isang malaking bilang ng mga nakabitin na proseso, mataas na pagkarga, kawalang-tatag ng system at mahinang pagganap.
Ang pagpapababa sa mga setting na ito ay nagiging sanhi ng data na ma-flush sa disk nang mas madalas at hindi nakaimbak sa RAM. Makakatulong ito sa mga system na mabigat sa memorya na okay sa pag-flush ng 45-90 GB na mga cache ng page sa disk, na nagreresulta sa malaking latency para sa mga front-end na application, na binabawasan ang pangkalahatang pagtugon at interaktibidad.
"1" > /proc/sys/vm/pagecache
Ang cache ng page ay isang cache na nag-iimbak ng data ng mga file at mga executable program, ibig sabihin, ito ay mga page na may aktwal na nilalaman ng mga file o mga device na naka-block. Ang cache na ito ay ginagamit upang bawasan ang bilang ng disk reads. Ang halaga ng "1" ay nangangahulugan na 1% ng RAM ang ginagamit para sa cache at magkakaroon ng mas maraming mga nabasa mula sa disk kaysa mula sa RAM. Hindi kinakailangang baguhin ang setting na ito, ngunit kung paranoid ka sa pagkontrol sa cache ng page, magagamit mo ito.
"deadline" > /sys/block/sdc/queue/scheduler
Ang I/O scheduler ay isang Linux kernel component na humahawak ng read and write queues. Sa teorya, mas mahusay na gumamit ng "noop" para sa isang matalinong controller ng RAID, dahil walang alam ang Linux tungkol sa pisikal na geometry ng disk, kaya mas mahusay na hayaan ang controller, na nakakaalam ng geometry ng disk, na iproseso ang kahilingan nang mabilis. maaari. Ngunit mukhang ang "deadline" ay nagpapabuti sa pagganap. Maaari kang magbasa nang higit pa tungkol sa mga scheduler sa dokumentasyon ng source code ng Linux kernel: linux/Documentation/block/*osched.txt. At nakita ko rin ang pagtaas ng read throughput sa panahon ng halo-halong operasyon (maraming write operations).
"256" > /sys/block/sdc/queue/nr_requests
Ang bilang ng mga I/O na kahilingan sa buffer bago sila ipasa sa scheduler. Ang panloob na laki ng pila ng ilang controller (queue_depth) ay mas malaki kaysa sa mga nr_request ng I/O scheduler, kaya maliit ang pagkakataon ng I/O scheduler na maayos na unahin at pagsamahin ang mga kahilingan. Para sa mga deadline at CFQ scheduler, mas maganda kapag ang nr_requests ay 2 beses sa internal queue ng controller. Ang mga kahilingan sa pagsasanib at muling pagsasaayos ay nakakatulong sa scheduler na maging mas tumutugon sa ilalim ng mabigat na pagkarga.
echo "16" > /proc/sys/vm/page-cluster
Kinokontrol ng parameter ng page-cluster ang bilang ng mga page na isinulat sa swap sa isang pagkakataon. Sa halimbawa sa itaas, ang value ay nakatakda sa "16" ayon sa RAID stripe size na 64 KB. Walang saysay ang swappiness = 0, ngunit kung itatakda mo ang swappiness sa 10 o 20, makakatulong sa iyo ang paggamit ng value na ito kapag ang laki ng RAID stripe ay 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc o dev_mapper)
Ang default na mga setting ng block device para sa maraming RAID controllers ay kadalasang nagreresulta sa kahila-hilakbot na pagganap. Ang pagdaragdag sa opsyon sa itaas ay nagse-set up ng read-ahead para sa 4096 * 512-byte na sektor. Hindi bababa sa, para sa mga operasyon ng streaming, ang bilis ay nadaragdagan sa pamamagitan ng pagpuno sa on-chip disk cache ng read-ahead sa panahon na ginamit ng kernel upang ihanda ang I/O. Ang cache ay maaaring maglaman ng data na hihilingin sa susunod na pagbabasa. Masyadong maraming prefetch ay maaaring pumatay ng random na I/O para sa malalaking file kung ito ay gumagamit ng potensyal na kapaki-pakinabang na disk time o naglo-load ng data sa labas ng cache.
Nasa ibaba ang ilan pang rekomendasyon sa antas ng file system. Ngunit hindi pa sila nasusubok. Tiyaking alam ng iyong filesystem ang laki ng stripe at ang bilang ng mga disk sa array. Halimbawa, na ito ay isang 5K stripe raid64 na hanay ng anim na disk (talagang lima, dahil ang isang disk ay ginagamit para sa parity). Ang mga rekomendasyong ito ay batay sa mga teoretikal na pagpapalagay at pinagsama-sama mula sa iba't ibang mga blog/artikulo ng mga eksperto sa RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Para sa malalaking file, isaalang-alang ang pagtaas ng mga sukat ng guhit na nakalista sa itaas.
BABALA! Ang lahat ng inilarawan sa itaas ay lubos na subjective para sa ilang uri ng mga application. Hindi ginagarantiya ng artikulong ito ang anumang mga pagpapabuti nang walang paunang pagsubok ng user sa mga nauugnay na application. Dapat lamang itong gamitin kung kinakailangan upang mapabuti ang pangkalahatang pagtugon ng system, o kung malulutas nito ang mga kasalukuyang problema.
Mga karagdagang materyales:
Magbasa pa
Pinagmulan: www.habr.com