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

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

Периодично тук-там възникват въпроси относно препоръките на Gluster за конфигуриране на ядрото и дали това е необходимо.

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

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

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

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

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

vm.swappiness

Параметър vm.swappiness определя колко ядрото използва свопинг (swap, подкачване) в сравнение с оперативната памет. В изходния код той също е определен като «tendency to steal mapped memory» (склонност за отнемане на отобразената памет). Високото значение на swappiness означава, че ядрото ще бъде по-склонно да изкарва отместените страници. Ниското значение на swappiness означава обратното: ядро ще изкарва по-малко страници от паметта. С други думи, колкото по-високо е значението vm.swappiness, толкова повече системата ще използва swap.

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

Подробности можете да прочетете тук — lwn.net/Articles/100978

Но отново, тези настройки трябва да се прилагат внимателно и само след тестиране на конкретното приложение. За приложения с висока натовареност, този параметър трябва да бъде зададен на '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). Когато този праг бъде достигнат, всички процеси стават синхронни (блокирани) и не им е разрешено да продължат работа, докато желаната от тях операция за вход-изход не бъде действително завършена и данните не попаднат на диска. При високо натоварване на входа-изхода това причинява проблеми, тъй като кеширането на данни отсъства и всички процеси, изпълняващи вход-изход, се блокират в очакване на вход-изход. Това води до голямо количество блокирани процеси, високо натоварване, нестабилна работа на системата и лоша производителност.

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

«1» > /proc/sys/vm/pagecache

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

«deadline» > /sys/block/sdc/queue/scheduler

Планировчикът на вход-изход (I/O scheduler) е компонент на ядрото на Linux, който обработва опашките за четене и запис. Теоретично е по-добре да се използва «noop» за интелигентен RAID контролер, защото Linux не знае нищо за физическата геометрия на диска, така че е по-ефективно да се позволи на контролера, който добре познава геометрията на диска, да обработва заявките колкото е възможно по-бързо. Но изглежда, че «deadline» увеличава производителността. Повече информация за планировчиците може да се намери в документацията към изходния код на ядрото на Linux: linux/Documentation/block/*osched.txt. И също така наблюдавах увеличаване на пропускателната способност на четенето по време на смесени операции (много операции за запис).

«256» > /sys/block/sdc/queue/nr_requests

Броят на заявките за вход-изход в буфера преди да бъдат предадени на планировчика. Размерът на вътрешната опашка на някои контролери (queue_depth) е по-голям от nr_requests на планировчика за вход-изход, така че планировчикът има ограничени шансове да приоритизира правилно и да извършва обединяване на заявки. За планировчици като deadline и CFQ е по-добре, когато nr_requests е два пъти по-голям от вътрешната опашка на контролера. Обединяването и преаранжирането на заявки помага на планировчика да бъде по-отзивчив при високи натоварвания.

echo «16» > /proc/sys/vm/page-cluster

Параметърът page-cluster управлява броя на страниците, които се записват в своп едновременно. В горния пример стойността се задава на «16» в зависимост от размера на страйпа (stripe size) на RAID от 64 KB. Това няма смисъл при swappiness = 0, но ако сте задали swappiness на 10 или 20, използването на тази стойност ще ви помогне, когато размерът на страйпа на RAID е 64 KB.

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))

За големи файлове можете да разгледате възможността за увеличаване на посочените по-горе размери на лентите.

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