Tarjamahan tina artikel ieu disiapkeun dina wengi mimiti kursus .
Ti waktos ka waktos, di ditu di dieu timbul patarosan ngeunaan saran Gluster ngeunaan kustomisasi kernel sareng naha perlu.
Kabutuhan ieu jarang timbul. Inti ngalaksanakeun saé pisan dina kalolobaan beban kerja. Sanajan aya downside a. Dina sajarahna, kernel Linux gampang meakeun seueur mémori upami dibéré kasempetan, kalebet pikeun cache salaku cara utama pikeun ningkatkeun kinerja.
Dina kalolobaan kasus ieu jalan hébat, tapi dina beban beurat bisa ngabalukarkeun masalah.
Simkuring gaduh pangalaman éksténsif gawé bareng sistem nu meakeun loba memori, kayaning CAD, EDA jeung sajabana, nu mimiti ngalambatkeun turun dina beban tinggi. Sarta kadangkala urang encountered masalah di Gluster. Saatos ngawaskeun sacara saksama mémori anu dianggo sareng waktos ngantosan disk langkung ti sadinten, kami ngagaduhan beban disk, iowait ageung, kasalahan kernel (kernel oops), beku, jsb.
Tulisan ieu mangrupikeun hasil tina seueur percobaan tuning parameter anu dilakukeun dina sababaraha kaayaan. Hatur nuhun kana parameter ieu, teu ukur responsiveness sacara umum ningkat, tapi ogé operasi kluster ieu nyata stabilized.
Lamun datang ka ngonpigurasikeun memori, tempat kahiji katingal subsistem memori virtual (VM), nu boga angka nu gede ngarupakeun pilihan nu bisa ngalieurkeun anjeun.
vm.swappiness
parameter vm.swappiness nangtukeun sabaraha kernel ngagunakeun swap dibandingkeun RAM. Éta ogé ditetepkeun dina kode sumber salaku "kacenderungan pikeun maok mémori anu dipetakeun." A nilai swappiness tinggi hartina kernel bakal leuwih rawan swapping kaca dipetakeun. A nilai swappiness low hartina sabalikna: kernel bakal swap kaca kaluar memori kirang. Dina basa sejen, nu leuwih luhur nilai vm.swappiness, beuki sistem bakal ngagunakeun swap.
Pamakéan éksténsif swap henteu pikaresepeun, sabab blok data ageung dimuat sareng dibongkar kana RAM. Seueur jalma ngabantah yén nilai swapiness kedahna luhur, tapi dina pangalaman kuring, netepkeun ka "0" ngahasilkeun prestasi anu langkung saé.
Anjeun tiasa maca deui di dieu -
Tapi deui, setélan ieu kedah dianggo kalayan ati-ati sareng ngan ukur saatos nguji aplikasi khusus. Pikeun aplikasi streaming anu sarat pisan, parameter ieu kedah disetel ka "0". Lamun dirobah jadi "0", responsif sistem ngaronjatkeun.
vm.vfs_cache_pressure
Setélan ieu ngadalikeun mémori anu dikonsumsi ku kernel pikeun cache objék diréktori sareng inode (dentry sareng inode).
Kalayan nilai standar 100, kernel bakal nyobian ngosongkeun cache dentri sareng inode sacara adil kana pagecache sareng swapcache. Turunna vfs_cache_pressure ngabalukarkeun kernel pikeun ngawétkeun dentry jeung inode caches. Lamun nilaina "0", kernel moal pernah siram dentry na inode cache alatan tekanan memori, sarta ieu bisa kalayan gampang ngakibatkeun kasalahan kaluar-of-memori. Ngaronjatkeun vfs_cache_pressure di luhur 100 ngabalukarkeun kernel méré prioritas pikeun dentri sareng inode pageouts.
Nalika nganggo GlusterFS, seueur pangguna anu gaduh data anu ageung sareng seueur file alit tiasa kalayan gampang ngagunakeun jumlah RAM anu signifikan dina server kusabab cache inode/dentry, anu tiasa nyababkeun kinerja anu goréng sabab kernel kedah nanganan struktur data dina sistem. kalawan 40 GB memori. Nyetél parameter ieu langkung ageung ti 100 parantos ngabantosan seueur pangguna pikeun ngahontal cache anu langkung adil sareng ningkatkeun responsif kernel.
vm.dirty_background_ratio sareng vm.dirty_ratio
Parameter kahiji (vm.dirty_background_ratio) Nangtukeun persentase mémori sareng halaman kotor, nalika ngahontal éta perlu pikeun ngamimitian nyiram latar tukang halaman kotor kana disk. Nepi ka persentase ieu ngahontal, kaca teu flushed kana disk. Sareng nalika reset dimimitian, éta jalan di latar tukang tanpa ngaganggu prosés jalan.
Parameter kadua (vm.dirty_ratio) nangtukeun persentase memori nu bisa ditempatan ku kaca kotor saméméh flash kapaksa dimimitian. Sakali ambang ieu ngahontal, sadaya prosés jadi sinkron (diblokir) jeung teu diwenangkeun pikeun nuluykeun ngajalankeun dugi operasi I / O aranjeunna dipénta sabenerna réngsé sarta data aya dina disk. Kalayan beban I / O anu luhur, ieu nyababkeun masalah sabab henteu aya cache data sareng sadaya prosés anu ngalakukeun I / O diblokir ngantosan I / O. Ieu ngakibatkeun sajumlah ageung prosés ngagantung, beban tinggi, instability sistem sareng kinerja anu goréng.
Nurunkeun nilai parameter ieu ngabalukarkeun data jadi flushed kana disk leuwih sering jeung teu disimpen dina RAM. Ieu tiasa ngabantosan sistem anu beurat-memori dimana éta normal pikeun ngosongkeun cache halaman 45-90GB kana disk, nyababkeun latency ageung pikeun aplikasi hareup-tungtung, ngirangan responsif sareng interaktivitas sadayana.
"1"> /proc/sys/vm/pagecache
Cache halaman mangrupikeun cache anu nyimpen data tina file sareng program anu tiasa dieksekusi, nyaéta, ieu mangrupikeun halaman kalayan eusi file atanapi alat anu saleresna. Cache ieu dianggo pikeun ngirangan jumlah disk anu dibaca. A nilai "1" hartina cache ngagunakeun 1% RAM jeung bakal aya leuwih dibaca ti disk ti RAM. Teu perlu ngarobah setelan ieu, tapi lamun paranoid ngadalikeun kaca cache, Anjeun bisa make eta.
"deadline"> /sys/block/sdc/queue/scheduler
I/O scheduler mangrupakeun komponén tina kernel Linux Ubuntu nu handles maca jeung nulis antrian. Dina tiori, éta hadé ngagunakeun "noop" pikeun controller RAID pinter, sabab Linux Ubuntu weruh nanaon ngeunaan géométri fisik disk, jadi leuwih efisien mun ngantep controller, nu weruh géométri disk ogé, ngolah pamundut sakumaha gancang-gancang. Tapi sigana "deadline" ningkatkeun kinerja. Inpo nu langkung lengkep ihwal schedulers tiasa dipendakan dina dokuméntasi pikeun kode sumber kernel Linux: linux/Documentation/block/*osched.txt. Sareng kuring ogé ningali kanaékan throughput dibaca salami operasi campuran (seueur tulisan).
"256"> /sys/block/sdc/queue/nr_requests
Jumlah requests I / O dina panyangga saméméh maranéhna dikirim ka scheduler nu. Ukuran antrian internal sababaraha Controllers (queue_depth) leuwih badag batan nr_requests scheduler I / O, jadi scheduler I / O boga kasempetan saeutik pikeun bener prioritizing na merging requests. Pikeun deadlines na CFQ schedulers, éta hadé lamun nr_requests 2 kali leuwih badag batan antrian internal controller urang. Ngagabung sareng nyusun ulang patarosan ngabantosan jadwal janten langkung responsif dina beban beurat.
gema "16"> /proc/sys/vm/page-cluster
Parameter halaman-cluster ngadalikeun jumlah kaca anu ditulis ka swap dina hiji waktu. Dina conto di luhur, nilai disetel ka "16" pikeun cocog ukuran belang RAID 64 KB. Ieu henteu masuk akal nalika swappiness = 0, tapi upami anjeun nyetél swappiness ka 10 atanapi 20, maka nganggo nilai ieu bakal ngabantosan anjeun nalika ukuran belang RAID 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc atanapi dev_mapper)
Setélan alat blok standar pikeun seueur pangendali RAID sering nyababkeun prestasi anu parah. Nambahkeun pilihan di luhur ngonpigurasikeun maca payun pikeun séktor 4096 * 512 bait. Sahenteuna pikeun operasi streaming, laju ngaronjat ku ngeusian cache disk on-chip via read-hareup salila periode kernel ngagunakeun pikeun nyiapkeun I / O. Cache tiasa nahan data anu bakal dipénta nalika maca salajengna. Loba teuing maca-hareup bisa maéhan I / O acak pikeun file badag lamun ngagunakeun nepi waktos disk berpotensi mangpaat atawa beban data di luar cache nu.
Di handap ieu aya sababaraha saran deui dina tingkat sistem file. Tapi aranjeunna henteu acan diuji. Pastikeun sistem file anjeun terang ukuran belang sareng jumlah disk dina array. Contona, yén ieu téh raid5 Asép Sunandar Sunarya kalawan ukuran belang 64K genep disk (sabenerna lima, sabab hiji disk dipaké pikeun parity). Rekomendasi ieu dumasar kana asumsi téoritis sareng dikumpulkeun tina sagala rupa blog/artikel ku para ahli 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))Pikeun file anu langkung ageung, anjeun tiasa mertimbangkeun ningkatkeun ukuran belang di luhur.
PERHATOSAN! Sagalana ditétélakeun di luhur pisan subjektif pikeun sababaraha jenis aplikasi. Tulisan ieu henteu ngajamin perbaikan naon waé tanpa nguji heula aplikasi masing-masing ku pangguna. Sakuduna ngan dipaké lamun aya anu peryogi pikeun ngaronjatkeun responsif sistem sakabéh atawa lamun solves masalah ayeuna.
Bahan tambahan:
Maca deui
sumber: www.habr.com