Məqalənin tərcüməsi kursun başlaması ərəfəsində hazırlanıb .
Dövri olaraq, burada və orada, Gluster-in nüvənin tənzimlənməsi ilə bağlı tövsiyələri və buna ehtiyac olub-olmaması ilə bağlı suallar yaranır.
Belə bir ehtiyac nadir hallarda yaranır. Əksər iş yüklərində kernel çox yaxşı işləyir. Bir mənfi tərəfi olsa da. Tarixən, Linux nüvəsi, performansı yaxşılaşdırmağın əsas yolu kimi keşləmə də daxil olmaqla, imkan verildiyi təqdirdə çox yaddaş istehlak etməyə hazır olmuşdur.
Əksər hallarda bu yaxşı işləyir, lakin ağır yük altında problemlərə səbəb ola bilər.
Ağır yük altında yavaşlamağa başlayan CAD, EDA və bənzəri kimi yaddaş intensiv sistemləri ilə bağlı çoxlu təcrübəmiz var. Və bəzən Gluster-də problemlərlə qarşılaşırdıq. Yaddaşın istifadəsini və disk gecikməsini bir neçə gün ərzində diqqətlə müşahidə etdikdən sonra onların həddindən artıq yüklənməsi, böyük iowait, nüvə xətaları (kernel oops), donmalar və s.
Bu məqalə müxtəlif vəziyyətlərdə həyata keçirilən bir çox tuning təcrübələrinin nəticəsidir. Bu parametrlər sayəsində nəinki ümumi həssaslıq yaxşılaşdı, həm də klaster əhəmiyyətli dərəcədə sabitləşdi.
Yaddaş tənzimləməsinə gəlincə, ilk növbədə diqqəti cəlb edən virtual yaddaş alt sistemidir (VM, virtual yaddaş), bu sistem sizi çaşdıra biləcək çoxlu seçimlərə malikdir.
vm.swappiness
Parametr vm.swappiness nüvənin RAM ilə müqayisədə nə qədər svopdan (mübadilə, paging) istifadə etdiyini müəyyən edir. O, həmçinin mənbə kodunda "xəritələnmiş yaddaşı oğurlamaq meyli" kimi müəyyən edilmişdir. Yüksək dəyişdirmə o deməkdir ki, kernel xəritələnmiş səhifələri dəyişdirməyə daha çox meylli olacaq. Aşağı mübadilə bunun əksi deməkdir: ləpə yaddaşdan daha az çıxacaq. Başqa sözlə, dəyər nə qədər yüksəkdir vm.swappiness, sistem mübadilədən daha çox istifadə edəcək.
Mübadilədən geniş istifadə arzuolunmazdır, çünki nəhəng məlumat blokları RAM-a yüklənir və boşaldılır. Bir çox insanlar mübadilə dəyərinin böyük olması lazım olduğunu iddia edirlər, lakin mənim təcrübəmə görə, onu "0" olaraq təyin etmək daha yaxşı performansa gətirib çıxarır.
Ətraflı burada oxuya bilərsiniz -
Ancaq yenə də bu parametrlər diqqətlə və yalnız müəyyən bir tətbiqi sınaqdan keçirdikdən sonra tətbiq edilməlidir. Yüksək yüklənmiş axın tətbiqləri üçün bu parametr "0" olaraq təyin edilməlidir. "0" olaraq dəyişdirildikdə sistemin cavab vermə qabiliyyəti yaxşılaşır.
vm.vfs_cache_pressure
Bu parametr qovluq və inode obyektlərinin (dentry və inode) keşləşdirilməsi üçün nüvə tərəfindən istehlak edilən yaddaşa nəzarət edir.
Defolt dəyəri 100 olan kernel dentry və inode keşlərini pagecache və swapcache üçün "ədalətli" əsasda azad etməyə çalışacaq. Vfs_cache_pressure-in azalması nüvənin dentry və inode keşlərini saxlamasına səbəb olur. Dəyər "0" olduqda, nüvə yaddaş təzyiqinə görə heç vaxt dentri və inode keşini təmizləməyəcək və bu, asanlıqla yaddaşdan kənar xəta ilə nəticələnə bilər. vfs_cache_pressure-nin 100-dən yuxarı artması nüvənin diş və inode yuyulmasını prioritetləşdirməsinə səbəb olur.
GlusterFS-dən istifadə edərkən, böyük həcmdə məlumat və çoxlu kiçik faylları olan bir çox istifadəçi inode/dentry keşləmə səbəbindən serverdə əhəmiyyətli miqdarda RAM-dan asanlıqla istifadə edə bilər ki, bu da kernel sistemdə məlumat strukturlarını emal etməli olduğu üçün performansın azalmasına səbəb ola bilər. 40 GB yaddaşla. Bu dəyərin 100-dən yuxarı qurulması bir çox istifadəçiyə daha ədalətli keşləmə və təkmil ləpə reaksiyasına nail olmağa kömək etdi.
vm.dirty_background_ratio və vm.dirty_ratio
Birinci parametr (vm.dirty_background_ratio) çirkli səhifələri olan yaddaşın faizini müəyyən edir, ona çatdıqdan sonra çirkli səhifələri fonda diskə təmizləməyə başlamaq lazımdır. Bu faizə çatana qədər heç bir səhifə diskə köçürülmür. Və sıfırlama başlayanda, işləyən prosesləri dayandırmadan arxa planda işləyir.
İkinci parametr (vm.dirty_ratio) məcburi flaş başlamazdan əvvəl çirkli səhifələrin tuta biləcəyi yaddaşın faizini müəyyən edir. Bu həddə çatdıqdan sonra bütün proseslər sinxronlaşır (bloklanır) və onların tələb etdiyi I/O faktiki tamamlanana və verilənlər diskdə olana qədər davam etməyə icazə verilmir. Ağır I/O ilə bu, problemə səbəb olur, çünki verilənlərin keşləşdirilməsi yoxdur və I/O-nu həyata keçirən bütün proseslər I/O-nu gözləyərkən bloklanır. Bu, çox sayda asılmış proseslərə, yüksək yükə, sistemin qeyri-sabitliyinə və zəif performansa gətirib çıxarır.
Bu parametrlərin azaldılması məlumatların diskə daha tez-tez yuyulmasına və RAM-da saxlanmamasına səbəb olur. Bu, 45-90 GB-lıq səhifə keşlərinin diskə yuyulmasının normal olduğu, yaddaşı ağır olan sistemlərə kömək edə bilər ki, bu da front-end proqramları üçün böyük gecikmə ilə nəticələnir, ümumi cavab vermə qabiliyyətini və interaktivliyi azaldır.
"1" > /proc/sys/vm/pagecache
Səhifə önbelleği faylların və icra olunan proqramların məlumatlarını saxlayan bir keşdir, yəni bunlar faylların və ya blok cihazlarının faktiki məzmunu olan səhifələrdir. Bu keş disk oxunuşlarının sayını azaltmaq üçün istifadə olunur. "1" dəyəri o deməkdir ki, RAM-ın 1%-i keş üçün istifadə olunur və RAM-dan daha çox diskdən oxunacaq. Bu parametri dəyişdirmək lazım deyil, ancaq səhifənin keşini idarə etməkdə paranoyaksınızsa, ondan istifadə edə bilərsiniz.
"son tarix" > /sys/block/sdc/queue/scheduler
I/O planlaşdırıcı oxu və yazma növbələrini idarə edən Linux nüvəsi komponentidir. Nəzəri olaraq, ağıllı RAID nəzarətçisi üçün "noop" istifadə etmək daha yaxşıdır, çünki Linux diskin fiziki həndəsəsi haqqında heç nə bilmir, ona görə də diskin həndəsəsini yaxşı bilən nəzarətçinin sorğunu tez bir zamanda emal etməsinə icazə vermək daha səmərəlidir. mümkündür. Ancaq görünür, "son tarix" performansı artırır. Linux nüvəsinin mənbə kodu sənədlərində planlaşdırıcılar haqqında daha çox oxuya bilərsiniz: linux/Documentation/block/*osched.txt. Həm də qarışıq əməliyyatlar zamanı oxuma qabiliyyətinin artdığını gördüm (bir çox yazı).
"256" > /sys/block/sdc/queue/nr_requests
Planlayıcıya ötürülməzdən əvvəl buferdəki I/O sorğularının sayı. Bəzi nəzarətçilərin daxili növbə ölçüsü (queue_depth) I/O planlaşdırıcısının nr_requests-dən böyükdür, ona görə də I/O planlaşdırıcının sorğuları düzgün prioritetləşdirmək və birləşdirmək şansı azdır. Son tarix və CFQ planlaşdırıcıları üçün nr_requests nəzarətçinin daxili növbəsindən 2 dəfə çox olduqda daha yaxşıdır. Sorğuların birləşdirilməsi və yenidən sıralanması planlaşdırıcıya ağır yük altında daha həssas olmağa kömək edir.
echo "16" > /proc/sys/vm/page-cluster
Səhifə-klaster parametri bir anda dəyişdirməyə yazılan səhifələrin sayını idarə edir. Yuxarıdakı misalda 16 KB RAID zolağı ölçüsünə uyğun olaraq dəyər "64" olaraq təyin edilmişdir. Sappiness = 0 ilə bunun mənası yoxdur, lakin dəyişdirməni 10 və ya 20-yə təyin etsəniz, RAID zolağı ölçüsü 64K olduqda bu dəyərdən istifadə etmək sizə kömək edəcəkdir.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc və ya dev_mapper)
Bir çox RAID nəzarətçiləri üçün standart blok cihaz parametrləri çox vaxt dəhşətli performansla nəticələnir. Yuxarıdakı seçimin əlavə edilməsi 4096 * 512 baytlıq sektorlar üçün qabaqcadan oxunuşu təşkil edir. Ən azı, axın əməliyyatları üçün nüvənin I/O hazırlamaq üçün istifadə etdiyi müddət ərzində çipdəki disk keşini qabaqcadan oxuma ilə doldurmaqla sürət artırılır. Kesh növbəti oxunuşda tələb olunacaq məlumatları ehtiva edə bilər. Həddindən artıq qabaqcadan yükləmə, potensial faydalı disk vaxtını sərf edərsə və ya məlumatları keşdən kənarda yükləyirsə, böyük fayllar üçün təsadüfi I/O-nu öldürə bilər.
Aşağıda fayl sistemi səviyyəsində daha bir neçə tövsiyə var. Lakin onlar hələ sınaqdan keçirilməyib. Fayl sisteminizin zolağın ölçüsünü və massivdəki disklərin sayını bildiyinə əmin olun. Məsələn, bu altı diskdən ibarət 5K zolaqlı raid64 massividir (əslində beş, çünki bir disk paritet üçün istifadə olunur). Bu tövsiyələr nəzəri fərziyyələrə əsaslanır və RAID ekspertləri tərəfindən müxtəlif bloqlardan/məqalələrdən tərtib edilib.
-> 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))Böyük fayllar üçün yuxarıda sadalanan zolaq ölçülərini artırmağı düşünün.
DİQQƏT Yuxarıda təsvir edilən hər şey bəzi tətbiq növləri üçün çox subyektivdir. Bu məqalə əlaqədar proqramların əvvəlcədən istifadəçi sınağı olmadan heç bir təkmilləşdirməyə zəmanət vermir. O, yalnız sistemin ümumi həssaslığını yaxşılaşdırmaq lazımdırsa və ya cari problemləri həll edərsə istifadə edilməlidir.
Əlavə materiallar:
Daha çox oxu
Mənbə: www.habr.com