Переклад статті підготовлений напередодні старту курсу .
Періодично то тут, то там виникають питання щодо рекомендацій 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