Преводот на статијата е подготвен во пресрет на почетокот на курсот .
Одвреме-навреме, овде-онде се поставуваат прашања за препораките на Глустер во врска со прилагодувањето на кернелот и дали тоа е неопходно.
Оваа потреба се јавува ретко. Јадрото работи многу добро при повеќето оптоварувања. Иако има негативна страна. Историски гледано, кернелот на Линукс лесно троши многу меморија ако му се даде можност, вклучително и за кеширање како основно средство за подобрување на перформансите.
Во повеќето случаи ова функционира одлично, но под големо оптоварување може да предизвика проблеми.
Имаме големо искуство со работа со системи кои трошат многу меморија, како што се CAD, EDA и слично, кои почнаа да се забавуваат при големо оптоварување. И понекогаш наидувавме на проблеми во Глустер. По внимателно следење на користената меморија и времето на чекање на дискот повеќе од еден ден, добивме преоптоварување на дискот, огромно чекање, грешки во јадрото (кернелот упс), замрзнувања итн.
Оваа статија е резултат на многу експерименти за прилагодување на параметрите извршени во различни ситуации. Благодарение на овие параметри, не само што генерално се подобри одговорноста, туку и работата на кластерот беше значително стабилизирана.
Кога станува збор за конфигурирање на меморијата, прво место што треба да се погледне е потсистемот за виртуелна меморија (VM), кој има голем број опции кои можат да ве збунат.
vm.замена
Параметар vm.swappiness одредува колку кернелот користи swap во споредба со RAM меморијата. Исто така, во изворниот код е дефинирано како „тенденција за крадење мапирана меморија“. Високата вредност на замена значи дека кернелот ќе биде повеќе склон кон замена на мапирани страници. Ниската вредност на замена значи спротивно: кернелот помалку ќе менува страници од меморијата. Со други зборови, толку е поголема вредноста vm.swappiness, толку повеќе системот ќе користи swap.
Широката употреба на замена е непожелна, бидејќи огромни блокови на податоци се вчитуваат и растовараат во RAM меморијата. Многу луѓе тврдат дека вредноста на swapiness треба да биде висока, но според моето искуство, поставувањето на „0“ резултира со подобри перформанси.
Можете да прочитате повеќе овде -
Но, повторно, овие поставки треба да се користат со претпазливост и само по тестирање на конкретната апликација. За високо вчитани апликации за стриминг, овој параметар треба да се постави на „0“. Кога ќе се смени во „0“, реагирањето на системот се подобрува.
vm.vfs_cache_pressure
Оваа поставка ја контролира меморијата што ја троши кернелот за кеширање на објекти на директориумот и иноди (дентри и иноди).
Со стандардна вредност од 100, кернелот ќе се обиде да ги ослободи кешовите за заби и иноди на правичен начин во кешот на страницата и кешот за размена. Намалувањето на vfs_cache_pressure предизвикува кернелот да ги зачува кешовите за заби и иноди. Кога вредноста е „0“, кернелот никогаш нема да ги измие кешот на забите и инодата поради притисокот во меморијата, а тоа лесно може да доведе до грешка без меморија. Зголемувањето на vfs_cache_pressure над 100 предизвикува кернелот да им даде приоритет на dentry и inode pageouts.
Кога користите GlusterFS, многу корисници со големи количини на податоци и многу мали датотеки можат лесно да користат значителна количина RAM меморија на серверот поради кеширање на инода/дентрија, што може да доведе до слаби перформанси бидејќи кернелот треба да се справи со структурите на податоци на системот со 40 GB меморија. Поставувањето на овој параметар на повеќе од 100 им помогна на многу корисници да постигнат поправедно кеширање и подобрена реакција на кернелот.
vm.dirty_background_ratio и vm.dirty_ratio
Првиот параметар (vm.dirty_background_ratio) го одредува процентот на меморија со валкани страници, откако ќе се достигне, потребно е да се започне со испирање на валканите страници во позадина на дискот. Сè додека не се достигне овој процент, страниците не се префрлаат на дискот. И кога ќе започне ресетирањето, се работи во заднина без да ги прекинува процесите што се извршуваат.
Втор параметар (vm.dirty_ratio) го одредува процентот на меморија што може да биде окупирана од валкани страници пред да започне принудниот блиц. Штом ќе се достигне овој праг, сите процеси стануваат синхрони (блокирани) и не им е дозволено да продолжат да работат додека операцијата В/И што тие ја побарале не биде навистина завршена и податоците се на дискот. Со големо оптоварување на I/O, ова предизвикува проблем бидејќи нема кеширање на податоци и сите процеси што вршат влез/излез се блокирани чекајќи го I/O. Ова резултира со голем број обесени процеси, големо оптоварување, нестабилност на системот и слаби перформанси.
Намалувањето на вредностите на овие параметри предизвикува почесто исфрлање на податоците на дискот и не складирање во RAM меморијата. Ова може да им помогне на системите кои се тешки за меморија каде што е нормално да се исфрлат кешовите на страници од 45-90 GB на дискот, што резултира со огромна латентност за предните апликации, намалувајќи ја севкупната реакција и интерактивност.
„1“ > /proc/sys/vm/pagecache
Кешот на страници е кеш што складира податоци од датотеки и извршни програми, односно, тоа се страници со вистинската содржина на датотеки или блок уреди. Овој кеш се користи за намалување на бројот на читања на дискот. Вредноста „1“ значи дека кешот користи 1% од RAM меморијата и ќе има повеќе читања од дискот отколку од RAM меморијата. Не е неопходно да се промени оваа поставка, но ако сте параноични за контрола на кешот на страницата, можете да го користите.
„краен рок“ > /sys/block/sdc/queue/scheduler
Распоредувачот за влез/излез е компонента на кернелот Линукс кој се справува со редици за читање и пишување. Во теорија, подобро е да се користи „noop“ за паметен RAID контролер, бидејќи Linux не знае ништо за физичката геометрија на дискот, па затоа е поефикасно да му дозволите на контролорот, кој добро ја познава геометријата на дискот, да го обработи барањето како што е можно побрзо. Но, се чини дека „рокот“ ги подобрува перформансите. Повеќе информации за распоредувачите може да најдете во документацијата за изворниот код на кернелот на Linux: linux/Documentation/block/*osched.txt. И, исто така, забележав зголемување на протокот на читање за време на мешани операции (многу пишувања).
„256“ > /sys/block/sdc/queue/nr_requests
Бројот на I/O барања во баферот пред да бидат испратени до распоредувачот. Големината на внатрешната редица на некои контролори (queue_depth) е поголема од nr_барањата на распоредувачот I/O, така што распоредувачот на I/O има мали шанси правилно да ги приоретизира и спојува барањата. За распоредувачите на рокови и CFQ, подобро е кога nr_requests е 2 пати поголем од внатрешната редица на контролорот. Спојувањето и преуредувањето на барањата му помага на распоредувачот да биде поодговорен при големо оптоварување.
ехо „16“ > /proc/sys/vm/page-cluster
Параметарот page-cluster го контролира бројот на страници кои се напишани на swap истовремено. Во горниот пример, вредноста е поставена на „16“ за да одговара на големината на RAID лентата од 64 KB. Ова нема смисла кога swappiness = 0, но ако поставите swappiness на 10 или 20, тогаш користењето на оваа вредност ќе ви помогне кога големината на RAID лентата е 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc или dev_mapper)
Стандардните блок-поставки на уредот за многу RAID контролери често резултираат со ужасни перформанси. Додавањето на горната опција го конфигурира читањето однапред за секторите од 4096*512 бајти. Барем за операциите за стриминг, брзината се зголемува со пополнување на кешот на дискот на чипот преку читање напред во периодот што јадрото го користи за подготовка на В/И. Кешот може да содржи податоци што ќе бидат побарани при следното читање. Премногу читање напред може да го убие случајниот I/O за големи датотеки ако користи потенцијално корисно време на дискот или вчитува податоци надвор од кешот.
Подолу се дадени уште неколку препораки на ниво на датотечен систем. Но, тие сè уште не се тестирани. Проверете дали вашиот датотечен систем ја знае големината на лентата и бројот на дискови во низата. На пример, дека ова е низа raid5 со големина на лента од 64K од шест дискови (всушност пет, бидејќи еден диск се користи за паритет). Овие препораки се засноваат на теоретски претпоставки и собрани од различни блогови/написи од експерти за 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))За поголеми датотеки, може да размислите за зголемување на горенаведените големини на ленти.
ВНИМАНИЕ Сè што е опишано погоре е крајно субјективно за некои видови апликации. Оваа статија не гарантира никакви подобрувања без претходно тестирање на соодветните апликации од страна на корисникот. Треба да се користи само ако има потреба да се подобри целокупната реакција на системот или ако ги решава тековните проблеми.
Дополнителни материјали:
Прочитај повеќе
Извор: www.habr.com