Пераклад артыкула падрыхтаваны напярэдадні старту курса .
Перыядычна то тут, то там узнікаюць пытанні аб рэкамендацыях Gluster адносна налады ядра і ці ёсць у гэтым неабходнасць.
Такая неабходнасць узнікае рэдка. На большасці нагрузак ядро працуе вельмі добрае. Хоць ёсць і адваротны бок. Гістарычна ядро Linux ахвотна спажывае шмат памяці, калі яму падаць такую магчымасць, у тым ліку і для кэшавання ў якасці асноўнага спосабу падвышэння прадукцыйнасці.
У большасці выпадкаў гэта працуе выдатна, але пры вялікай нагрузцы можа прывесці да праблем.
У нас ёсць вялікі досвед працы з сістэмамі, якія спажываюць шмат памяці, такімі як, CAD, EDA і падобнымі, якія пачыналі тармазіць пры высокай нагрузцы. І часам мы сутыкаліся з праблемамі ў Gluster. Дбайна паназіраўшы не адзін дзень за выкарыстоўванай памяццю і часам чаканні дыскаў мы атрымалі іх перагрузку, велізарныя iowait, памылкі ядра (kernel oops), завісанні і да т.п.
Гэты артыкул з'яўляецца вынікам шматлікіх эксперыментаў па наладзе параметраў, выкананых у розных сітуацыях. Дзякуючы гэтым параметрам не толькі палепшылася спагадлівасць у цэлым, але і значна стабілізавалася праца кластара.
Калі справа даходзіць да налады памяці, то перш за ўсё трэба глядзець на падсістэму віртуальнай памяці (VM, virtual memory), у якой ёсць вялікая колькасць опцый, здольных увесці вас у замяшанне.
vm.swappiness
Параметр vm.swappiness вызначае наколькі ядро выкарыстоўвае свопінг (swap, падпампоўку) у параўнанні з аператыўнай памяццю. У зыходным кодзе ён таксама вызначаны як "tendency to steal mapped memory" (схільнасць да крадзяжу якая адлюстроўваецца памяці). Высокае значэнне swappiness азначае, што ядро будзе больш схільна да выгрузкі адлюстраваных старонак. Нізкае значэнне swappiness азначае адваротнае: ядро будзе менш выгружаць старонкі з памяці. Іншымі словамі, чым вышэй значэнне vm.swappiness, тым больш сістэма будзе выкарыстоўваць swap.
Вялікае выкарыстанне свопінгу непажадана, бо ў аператыўную памяць загружаюцца і выгружаюцца вялізныя блокі дадзеных. Многія сцвярджаюць, што значэнне swapiness павінна быць вялікім, але на маю вопыту, да павелічэння прадукцыйнасці прыводзіць ўстаноўка ў «0».
Падрабязней можна пачытаць тут —
Але, зноў жа, гэтыя налады павінны прымяняцца з асцярожнасцю і толькі пасля тэсціравання канкрэтнага прыкладання. Для высоканагружаных струменевых прыкладанняў гэты параметр варта ўсталёўваць у "0". Пры змене на "0" спагадлівасць сістэмы паляпшаецца.
vm.vfs_cache_pressure
Гэты параметр кантралюе памяць, спажываную ядром для кэшавання аб'ектаў каталогаў і індэксных дэскрыптараў (dentry і inode).
Пры значэнні па змаўчанні ў 100 ядро будзе спрабаваць вызваляць кэш dentry і inode па "справядлівасці" па стаўленні да pagecache і swapcache. Памяншэнне vfs_cache_pressure прыводзіць да таго, што ядро будзе захоўваць кэшы dentry і inode. Калі значэнне роўна "0", ядро ніколі не будзе чысціць кэш dentry і inode з-за недахопу памяці (memory pressure), і гэта можа лёгка прывесці да памылкі out-of-memory. Павелічэнне vfs_cache_pressure больш за 100 прыводзіць да таго, што ядро аддае прыярытэт выгрузцы dentry і inode.
Пры выкарыстанні GlusterFS шмат карыстачоў з вялікімі аб'ёмамі дадзеных і мноствам маленькіх файлаў лёгка могуць выкарыстаць на серверы значная колькасць аператыўнай памяці з-за кэшавання inode/dentry, што можа прывесці да зніжэння прадукцыйнасці, бо ядру даводзіцца апрацоўваць структуры дадзеных у сістэме з 40 ГБ памяці. . Ўстаноўка гэтага параметру больш за 100 дапамагла многім карыстальнікам дабіцца больш справядлівага кэшавання і палепшыць спагадлівасць ядра.
vm.dirty_background_ratio і vm.dirty_ratio
Першы параметр (vm.dirty_background_ratio) вызначае працэнт памяці з бруднымі старонкамі, дасягнуўшы які неабходна пачаць фонавы скід брудных старонак на дыск. Пакуль гэты працэнт не дасягнуты, старонкі не скідаюцца на дыск. А калі скід пачынаецца, ён выконваецца ў фонавым рэжыме, не перарываючы працуючыя працэсы.
Другі параметр (vm.dirty_ratio) вызначае працэнт памяці, які можа быць заняты бруднымі старонкамі да пачатку прымусовага скіду (forced flash). Пры дасягненні гэтага парога ўсе працэсы становяцца сінхроннымі (блакуюцца), і ім не дазваляецца працягваць працу датуль, пакуль запытаная імі аперацыя ўводу-высновы не будзе фактычна завершаная і дадзеныя не апынуцца на дыску. Пры высоканагружаным уводзе-вывадзе гэта выклікае праблему, бо кэшаванне дадзеных адсутнічае, і ўсе працэсы, якія выконваюць увод-вывад, блакуюцца ў чаканні ўводу-высновы. Гэта прыводзіць да вялікай колькасці завіслых працэсаў, высокай нагрузцы, нестабільнай працы сістэмы і дрэннай прадукцыйнасці.
Памяншэнне значэнняў гэтых параметраў прыводзіць да таго, што дадзеныя часцей за скідаюцца на дыск і не захоўваюцца ў АЗП. Гэта можа дапамагчы сістэмам з вялікай колькасцю памяці, для якіх нармальна скідаць на дыск кэш старонак памерам 45-90 ГБ, што прыводзіць да вялізнага часу чакання для фронтэнд-прыкладанняў, зніжаючы агульную спагадлівасць і інтэрактыўнасць.
"1" > /proc/sys/vm/pagecache
Старонкавы кэш (page cache) - гэта кэш, у якім захоўваюцца дадзеныя файлаў і выкананых праграм, гэта значыць гэта старонкі з фактычным змесцівам файлаў ці блокавых прылад. Гэты кэш выкарыстоўваецца для памяншэння колькасці чытанняў з дыска. Значэнне "1" азначае, што для кэша выкарыстоўваецца 1% АЗП і аперацый чытання з дыска будзе больш, чым з АЗП. Змяняць гэты параметр не абавязкова, але калі вы паранаідальна ставіцеся да кантролю над кэшам старонак, то можаце ім скарыстацца.
"deadline" > /sys/block/sdc/queue/scheduler
Планавальнік уводу-высновы (I/O scheduler) - гэта кампанент ядра Linux, які апрацоўвае чэргі чытання і запісы. Тэарэтычна для разумнага RAID-кантролера лепш выкарыстоўваць "noop", таму што Linux нічога не ведае аб фізічнай геаметрыі дыска, таму больш эфектыўна дазволіць кантролеру, добра дасведчанаму геаметрыю дыска, як мага хутчэй апрацаваць запыт. Але падобна, што deadline падвышае прадукцыйнасць. Падрабязней пра планавальнікаў можна прачытаць у дакументацыі да зыходнага кода ядра Linux: linux/Documentation/block/*osched.txt. І таксама я назіраў павелічэнне прапускной здольнасці чытання падчас змешаных аперацый (шмат аперацый запісу).
«256» > /sys/block/sdc/queue/nr_requests
Колькасць запытаў уводу-вываду ў буферы перад тым як яны перадаюцца планавальніку. Памер унутранай чаргі некаторых кантролераў (queue_depth) больш, чым nr_requests планавальніка ўводу-высновы, так што ў планавальніка ўводу-высновы мала шанцаў правільна прыярытэзаваць і выканаць зліццё запытаў. Для планавальнікаў deadline і CFQ лепш, калі nr_requests у 2 разы больш унутранай чаргі кантролера. Аб'яднанне і пераўпарадкаванне запытаў дапамагае планавальніку быць больш спагадным пры вялікай нагрузцы.
echo "16" > /proc/sys/vm/page-cluster
Параметр page-cluster кіруе колькасцю старонак, якія запісваюцца ў своп за адзін раз. У прыведзеным вышэй прыкладзе значэнне ўсталёўваецца роўным "16" у адпаведнасці з памерам страйпа (stripe size) RAID у 64 КБ. Гэта не мае сэнсу пры swappiness = 0, але калі вы ўсталявалі swappiness у 10 ці 20, тое выкарыстанне гэтага значэння дапаможа вам, калі памер страйпа RAID складае 64 КБ.
blockdev -setra 4096 /dev/<devname> (-sdb, hdc ці dev_mapper)
Налады блокавых прылад па змаўчанні для шматлікіх RAID-кантролераў часта прыводзяць да жудаснай прадукцыйнасці. Даданне вышэйпаказанай опцыі, наладжвае папераджальнае чытанне для 4096 * 512-байтных сектараў. Прынамсі, для струменевых аперацый павялічваецца хуткасць, напаўняючы ўбудаваны кэш кружэлкі за рахунак папераджальнага чытання на працягу перыяду, выкарыстоўванага ядром для падрыхтоўкі ўводу-высновы. У кэш могуць змяшчацца дадзеныя, якія будуць запытаны пры наступным чытанні. Занадта вялікае папераджальнае чытанне можа забіць выпадковы ўвод-вывад для вялікіх файлаў, калі ён выкарыстоўвае патэнцыйна карысны час дыска ці загружае дадзеныя за межамі кэша.
Ніжэй прыведзены яшчэ некалькі рэкамендацый на ўзроўні файлавай сістэмы. Але яны яшчэ не былі пратэставаны. Упэўніцеся, што ваша файлавая сістэма ведае памер страйпа і колькасць дыскаў у масіве. Напрыклад, што гэта масіў 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))Для вялікіх файлаў можна разгледзець магчымасць павелічэння паказаных вышэй памераў страйпаў.
УВАГА! Усё, што апісана вышэй вельмі суб'ектыўна для некаторых тыпаў дадаткаў. Гэты артыкул не гарантуе якія-небудзь паляпшэнні без папярэдняга тэсціравання адпаведных прыкладанняў з боку карыстальніка. Яе варта ўжываць толькі ў выпадку неабходнасці паляпшэння агульнай спагадлівасці сістэмы ці, калі яна вырашае бягучыя праблемы.
Дадатковыя матэрыялы:
Чытаць яшчэ
Крыніца: habr.com