Преводът на статията беше подготвен в навечерието на началото на курса .
Периодично тук и там възникват въпроси относно препоръките на Gluster относно настройката на ядрото и дали има нужда от това.
Подобна необходимост възниква рядко. При повечето натоварвания ядрото се представя много добре. Въпреки че има и минус. Исторически погледнато, ядрото на Linux е било готово да консумира много памет, ако му е дадена възможност, включително за кеширане като основен начин за подобряване на производителността.
В повечето случаи това работи добре, но при голямо натоварване може да доведе до проблеми.
Имаме голям опит със системи с интензивна памет като CAD, EDA и други подобни, които започнаха да се забавят при голямо натоварване. И понякога се натъквахме на проблеми в Gluster. След внимателно наблюдение на използването на паметта и латентността на диска в продължение на много дни, ние получихме тяхното претоварване, огромно iowait, грешки на ядрото (ядрото опа), замръзвания и т.н.
Тази статия е резултат от много експерименти за настройка, извършени в различни ситуации. Благодарение на тези параметри не само общата реакция се е подобрила, но и клъстерът значително се е стабилизирал.
Когато става въпрос за настройка на паметта, първото нещо, което трябва да разгледате, е подсистемата за виртуална памет (VM, виртуална памет), която има голям брой опции, които могат да ви объркат.
vm.swappiness
Параметър vm.swappiness определя колко ядрото използва суап (размяна, пейджинг) в сравнение с RAM. Също така е дефинирано в изходния код като "склонност към кражба на картирана памет". Високият swappiness означава, че ядрото ще бъде по-склонно да разменя картираните страници. Ниската стойност на swappiness означава обратното: ядрото ще страници по-малко от паметта. С други думи, колкото по-висока е стойността vm.swappiness, толкова повече системата ще използва swap.
Масовото използване на суапинг е нежелателно, тъй като огромни блокове от данни се зареждат и разтоварват в RAM. Много хора твърдят, че стойността на swapiness трябва да е голяма, но според моя опит, настройката й на "0" води до по-добра производителност.
Можете да прочетете повече тук -
Но, отново, тези настройки трябва да се прилагат внимателно и само след тестване на конкретно приложение. За силно натоварени стрийминг приложения този параметър трябва да бъде зададен на "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
I/O Scheduler е компонент на ядрото на Linux, който обработва опашки за четене и запис. На теория е по-добре да използвате "noop" за интелигентен RAID контролер, тъй като 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))За големи файлове помислете за увеличаване на размерите на ивиците, изброени по-горе.
ВНИМАНИЕ! Всичко описано по-горе е силно субективно за някои видове приложения. Тази статия не гарантира никакви подобрения без предварително потребителско тестване на свързани приложения. Трябва да се използва само ако е необходимо да се подобри цялостната реакция на системата или ако решава текущи проблеми.
Допълнителни материали:
Прочетете още
Източник: www.habr.com