🥇Настройка на ядрото Linux за GlusterFS

Преводът на статията беше подготвен в навечерието на началото на курса Администратор LinuxПрофесионален».

Периодично тук и там възникват въпроси относно препоръките на Gluster относно настройката на ядрото и дали има нужда от това.

Тази нужда рядко възниква. При повечето натоварвания ядрото се представя много добре. Има обаче и недостатък. В исторически план ядрото Linux доброволно консумира много памет, ако му се даде възможност, включително за кеширане като основен начин за подобряване на производителността.

В повечето случаи това работи добре, но при голямо натоварване може да доведе до проблеми.

Имаме голям опит със системи с интензивна памет като CAD, EDA и други подобни, които започнаха да се забавят при голямо натоварване. И понякога се натъквахме на проблеми в Gluster. След внимателно наблюдение на използването на паметта и латентността на диска в продължение на много дни, ние получихме тяхното претоварване, огромно iowait, грешки на ядрото (ядрото опа), замръзвания и т.н.

Тази статия е резултат от много експерименти за настройка, извършени в различни ситуации. Благодарение на тези параметри не само общата реакция се е подобрила, но и клъстерът значително се е стабилизирал.

Когато става въпрос за настройка на паметта, първото нещо, което трябва да разгледате, е подсистемата за виртуална памет (VM, виртуална памет), която има голям брой опции, които могат да ви объркат.

vm.swappiness

Параметър vm.swappiness определя колко ядрото използва суап (размяна, пейджинг) в сравнение с RAM. Също така е дефинирано в изходния код като "склонност към кражба на картирана памет". Високият swappiness означава, че ядрото ще бъде по-склонно да разменя картираните страници. Ниската стойност на swappiness означава обратното: ядрото ще страници по-малко от паметта. С други думи, колкото по-висока е стойността vm.swappiness, толкова повече системата ще използва swap.

Масовото използване на суапинг е нежелателно, тъй като огромни блокове от данни се зареждат и разтоварват в RAM. Много хора твърдят, че стойността на swapiness трябва да е голяма, но според моя опит, настройката й на "0" води до по-добра производителност.

Можете да прочетете повече тук - lwn.net/Articles/100978

Но, отново, тези настройки трябва да се прилагат внимателно и само след тестване на конкретно приложение. За силно натоварени стрийминг приложения този параметър трябва да бъде зададен на "0". Когато се промени на "0", отзивчивостта на системата се подобрява.

vm.vfs_cache_pressure

Тази настройка контролира паметта, консумирана от ядрото за кеширане на директория и inode обекти (dentry и inode).

Със стойност по подразбиране 100, ядрото ще се опита да освободи кешовете на dentry и inode на "честна" основа за pagecache и swapcache. Намаляването на vfs_cache_pressure кара ядрото да поддържа dentry и inode кешове. Когато стойността е "0", ядрото никога няма да изтрие dentry и inode кеша поради натиска на паметта и това може лесно да доведе до грешка при недостиг на памет. Увеличаването на vfs_cache_pressure над 100 кара ядрото да приоритизира изчистването на dentry и inode.

Когато използват GlusterFS, много потребители с големи количества данни и много малки файлове могат лесно да използват значително количество RAM на сървъра поради кеширане на inode/dentry, което може да доведе до влошаване на производителността, тъй като ядрото трябва да обработва структури от данни в системата с 40 GB памет. Задаването на тази стойност над 100 помогна на много потребители да постигнат по-справедливо кеширане и подобрена реакция на ядрото.

vm.dirty_background_ratio и vm.dirty_ratio

Първи параметър (vm.dirty_background_ratio) определя процента на паметта със замърсени страници, след достигането на който е необходимо да започне изчистването на замърсените страници на диска във фонов режим. Докато не бъде достигнат този процент, никакви страници не се записват на диска. И когато нулирането започне, то работи във фонов режим, без да прекъсва изпълняваните процеси.

Вторият параметър (vm.dirty_ratio) определя процента на паметта, който може да бъде зает от мръсни страници, преди да започне принудителното флашване. След като този праг бъде достигнат, всички процеси стават синхронни (блокирани) и не им е позволено да продължат, докато I/O, който са поискали, действително е завършен и данните са на диска. При тежък I/O това създава проблем, защото няма кеширане на данни и всички процеси, извършващи I/O, са блокирани в очакване на I/O. Това води до голям брой увиснали процеси, високо натоварване, нестабилност на системата и ниска производителност.

Намаляването на тези настройки кара данните да се изхвърлят на диска по-често и да не се съхраняват в RAM. Това може да помогне на системи с тежък обем на паметта, където е нормално да се изчистват 45-90 GB кешове на страници на диск, което води до огромно забавяне за предните приложения, намалявайки цялостната отзивчивост и интерактивност.

"1" > /proc/sys/vm/pagecache

Кешът за страници е кеш, който съхранява данните от файлове и изпълними програми, тоест това са страници с действителното съдържание на файлове или блокови устройства. Този кеш се използва за намаляване на броя на четенията на диска. Стойност "1" означава, че 1% от RAM се използва за кеша и ще има повече четения от диск, отколкото от RAM. Не е необходимо да променяте тази настройка, но ако сте параноични да контролирате кеша на страницата, можете да я използвате.

"краен срок" > /sys/block/sdc/queue/scheduler

Планировчикът за входно/изходни операции е компонент на ядрото. Linux, който обработва опашки за четене и запис. Теоретично, за интелигентен RAID контролер е по-добре да се използва „noop“, защото Linux Планировчикът не знае нищо за физическата геометрия на диска, така че е по-ефективно да се позволи на контролера, който има добри познания за геометрията на диска, да обработи заявката възможно най-бързо. „Крайният срок“ обаче изглежда подобрява производителността. Повече информация за планировчиците може да бъде намерена в документацията на изходния код на ядрото. Linux: linux/Documentation/block/*osched.txt. Освен това видях увеличение на пропускателната способност на четене по време на смесени операции (много записи).

"256" > /sys/block/sdc/queue/nr_requests

Броят I/O заявки в буфера, преди да бъдат предадени на планировчика. Вътрешният размер на опашката на някои контролери (queue_depth) е по-голям от nr_requests на I/O планировчика, така че I/O планировчикът има малък шанс за правилно приоритизиране и обединяване на заявките. За крайни срокове и програми за планиране на CFQ е по-добре, когато nr_requests е 2 пъти вътрешната опашка на контролера. Обединяването и пренареждането на заявки помага на планировчика да бъде по-отзивчив при голямо натоварване.

echo "16" > /proc/sys/vm/page-cluster

Параметърът page-cluster контролира броя на страниците, които се записват в swap едновременно. В горния пример стойността е зададена на "16" според размера на лентата на RAID от 64 KB. Няма смисъл с swappiness = 0, но ако зададете swappiness на 10 или 20, тогава използването на тази стойност ще ви помогне, когато размерът на лентата на RAID е 64K.

blockdev --setra 4096 /dev/`<`devname`>` (-sdb, hdc или dev_mapper)

Настройките на блоковото устройство по подразбиране за много RAID контролери често водят до ужасна производителност. Добавянето на горната опция настройва предварително четене за 4096 * 512-байтови сектори. Най-малкото, за поточни операции, скоростта се увеличава чрез запълване на дисковия кеш на чипа с предварително четене през периода, използван от ядрото за подготовка на I/O. Кешът може да съдържа данни, които ще бъдат поискани при следващото четене. Твърде много предварително извличане може да убие случаен I/O за големи файлове, ако използва потенциално полезно време на диска или зарежда данни извън кеша.

По-долу са дадени още няколко препоръки на ниво файлова система. Но те все още не са тествани. Уверете се, че вашата файлова система знае размера на лентата и броя на дисковете в масива. Например, че това е 5K stripe raid64 масив от шест диска (всъщност пет, защото един диск се използва за паритет). Тези препоръки се основават на теоретични предположения и са събрани от различни блогове/статии от експерти на 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))

За големи файлове помислете за увеличаване на размерите на ивиците, изброени по-горе.

ВНИМАНИЕ! Всичко описано по-горе е силно субективно за някои видове приложения. Тази статия не гарантира никакви подобрения без предварително потребителско тестване на свързани приложения. Трябва да се използва само ако е необходимо да се подобри цялостната реакция на системата или ако решава текущи проблеми.