Налаштування MongoDB WiredTiger, коли база впирається в пам'ять і диск
Коли база впирається в пам'ять і диск, деградація починається непомітно: кеш WiredTiger перестає вміщати робочий набір, і все більша частка читань проходить повз нього — спочатку на швидкий носій, потім углиб.
Поки є запас, метрики рівні, але щойно активний набір даних перевищить доступний кеш, витіснення даних на диск перестає встигати за потоком змін. База не падає — вона сповільнюється, і це найнеприємніший клас збою: формально все живе, фактично сервіс не витримує навантаження.
Першим проявляється зростання затримки відповіді бази: запити стають у чергу на змінених сторінках, яку не встигають скидати фонові потоки. Затримка зростає нелінійно — за невеликого перевищення робочого набору над кешем відгук погіршується в рази, а не на відсотки.
Далі спрацьовує зворотний зв'язок: застосунок накопичує з'єднання й агресивніше перечитує ті самі дані, тиск на кеш ще вищий.
Слідом розходяться репліки. Вторинні вузли повторюють потік операцій первинного, і щойно той перестає встигати за навантаженням, відставання реплік зростає на очах. Читання з реплік починає віддавати застарілі дані, а звітність і фонові завдання — працювати за неповною картиною. По суті один вузол, що вперся в пам'ять, тягне за собою весь кластер.
Просте «додамо пам'яті» проблему не знімає: без узгодження розміру кеша з робочим набором, компресії блоків, політики витіснення та періодичності контрольних точок та сама межа настане знову.
Саме тому налаштування MongoDB WiredTiger — це робота з параметрами й моніторингом, а не одна правка конфігурації, і далі розбираємо, як це закривається: від діагностики за внутрішніми лічильниками движка до вибору схеми стиснення під профіль даних.
Що змінюється після підбору параметрів кеша й стиснення
Підбір параметрів — це не одноразова правка конфігурації, а перевірка гіпотез за метриками. Дивимося на три зрізи: скільки робочого набору залишається в пам'яті, який обсяг колекція займає на диску і як поводиться вторинний вузол під навантаженням.
Нижче — зрушення, за якими видно, що налаштування MongoDB WiredTiger дало результат, а не збіглося з одноразовим сплеском трафіку.
| Що вимірюємо | До підбору | Після підбору |
|---|---|---|
| Ефект налаштування кеша | робочий набір витісняється на диск у години пік | гарячі дані тримаються в пам'яті, промахи виходять на плато |
| Стиснення колекцій | обсяг на диску близький до логічного | записується в рази менше, постійний допис не роздуває файли |
| Дискове введення-виведення | піки на кожному сплеску навантаження | рівний фон, черга запитів до диска коротша |
| Затримка реплікації | зростає до десятків секунд під навантаженням | тримається у вузькому стабільному коридорі |
| Час відновлення | підйом вузла після збою затягується | вузол входить у стрій помітно швидше |
Що тримаємо на дашборді
Частка влучань у кеш, глибина черги запитів до диска, лаг вторинних вузлів, коефіцієнт стиснення для кожної колекції та час підйому вузла після перезапуску.
Знімаємо ці значення до і після правок і зберігаємо графіками: без базової лінії через місяць уже ніхто не доведе, що стало краще.
Які відмови перестають виникати
Зникає витіснення сторінок на диск у години пік — саме воно дає ступінчасте зростання затримок, яке не лікується масштабуванням. Вирівнюється лаг реплік, тому читання з вторинних вузлів перестає віддавати застарілі дані.
Перезапуск і відновлення вкладаються в передбачуване вікно, а колекції з постійним дописом більше не з'їдають диск.
Порівняння підходів: стиснення, кеш і розкладка колекцій
Рішення про стиснення й розкладку ухвалюється від профілю навантаження, а не за замовчуванням: частка читання, розмір робочого набору, строк затребуваності даних.
WiredTiger дозволяє задати стиснення окремо для колекції й окремо для індексів, тому один і той самий сервер може тримати гарячі дані з швидким кодеком, а архів — з щільним.
Помилка у виборі б'є по затримці читання сильніше, ніж економить місце: щільне стиснення економить диск, але додає роботи процесору на кожному читанні.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Стиснення за замовчуванням, швидкий кодек | Робочий набір не вміщається в пам'ять, переважає запис | Виграш за обсягом помірний, прискорення читання немає |
| Щільний кодек на окремі колекції | Архівні та рідко читані колекції, важливий обсяг на диску | Процесорне навантаження вище, читання повільніше |
| Гарячі колекції в окремій базі зі збільшеним кешем | Дві-три колекції дають основну частку запитів | Пам'ять скінченна: чим більше «гарячих», тим раніше витіснення |
| Винесення архівних даних | Дані старші за строк затребуваності, звітність рідка | Потрібні правила перенесення й єдина точка доступу для звітів |
| Гібридний варіант | Велика система з різним профілем за колекціями | Потребує моніторингу й періодичного перегляду налаштувань |
Крайнощі ламаються передбачувано. Якщо стиснути максимально все, сервер впирається в процесор, а затримка читання зростає на рівному місці. Якщо тримати в кеші весь робочий набір, фізична межа пам'яті повертає витіснення й промахи — просто пізніше й непомітніше.
Гібридний варіант розводить колекції за призначенням: гарячі залишаються з швидким кодеком і збільшеним кешем, архів вирушає в окрему розкладку з щільним стисненням, звітність читає винесені дані. Налаштування при цьому переглядаються за метриками, а не виставляються один раз.
Порядок робіт: від профілю навантаження до передачі під контроль
Роботи йдуть від заміру реального навантаження: один і той самий набір параметрів WiredTiger на різних профілях дає протилежний результат — десь виграш за затримкою, десь просідання за пропускною здатністю.
Порядок нижче побудований так, щоб кожна зміна спиралася на попередній замір і не ламала вже досягнуте.
- Аудит і профіль навантаження. Знімаємо статистику операцій читання й запису, частку влучань у кеш, тривалість повільних запитів, пікові вікна. На виході — модель навантаження, від якої рахуємо решту.
- Схема зберігання та індекси. Розбираємо структуру документів, склад і розмір індексів, фрагментацію, розміщення даних і журналу на дисках. Зайві індекси прибираємо, відсутні додаємо: до правки параметрів це дає більше, ніж саме налаштування.
- Підбір параметрів. Рахуємо розмір кеша під робочий набір і доступну пам'ять, вибираємо алгоритм і рівень стиснення для колекцій та індексів, налаштовуємо журнал і періодичність контрольних точок. Кожне значення обґрунтоване заміром, а не довідником.
- Перевірка під навантаженням. Відтворюємо профіль на стенді й порівнюємо затримки, пропускну здатність і споживання пам'яті до і після. Окремо дивимося поведінку при переповненні кеша й на піку — там налаштування проявляють себе.
- Спостережуваність і пороги. Виводимо ключові метрики, задаємо пороги й оповіщення за ними, щоб деградація ставала видною до скарг користувачів.
- Передача супроводу. Віддаємо конфігурації, опис схеми, карту метрик і порядок відкату, розбираємо з вашою командою типові ситуації.
Що залишається у вас: конфігурації, схеми й регламенти
Комплект передаємо робочими артефактами, а не папкою файлів: конфігурації лежать у системі контролю версій поруч із кодом, схеми — у вигляді діаграм, регламенти — у вигляді покрокових інструкцій із командами.
За кожним пунктом зрозуміла точка входу: з чого почати при інциденті й хто відповідає на вашій стороні.
- Конфігурація кластера. Параметри WiredTiger: розмір кеша під робочий набір, стиснення колекцій і журналу, інтервали контрольних точок; значення параметризовані за середовищами, секрети винесені окремо.
- Схема розміщення даних. Що шардиться і за якими ключами, що залишається на репліках, де межа гарячих і архівних колекцій, які індекси зобов'язані існувати.
- Політики доступу. Ролі за принципом мінімально необхідних прав, окремі облікові записи для застосунків, реплікації й моніторингу, порядок ротації.
- Регламент моніторингу. Метрики й пороги, готові запити для розбору зростання затримок, відставання реплік і заповнення диска, порядок ескалації.
- Документація з експлуатації. Підйом вузла з нуля, планове перемикання, відновлення з копії — з оцінкою часу кожного кроку.
- План резервного копіювання. Розклад, глибина зберігання, обов'язкова перевірка відновлення на тестовому контурі.
- Орієнтири продуктивності. Профілі навантаження й еталонні значення до і після змін — видно, де норма, а де деградація.
Кейс: зростання сховища сповільнилося, відмови під навантаженням зникли
Що було до змін
Кластер MongoDB обслуговував каталог товарів: нічний перерахунок, потік подій від застосунків і постійні читання. За пів року обсяг даних зріс майже втричі, кеш сховища залишався на значенні за замовчуванням і не покривав робочий набір — помітна частина читань ішла на диск.
У години пік це давало відмови під навантаженням: час відповіді виходив за цільовий, частина операцій завершувалася помилкою через перевищення часу очікування, репліка відставала від майстер-вузла.
Що зробили
Перерахували розмір кеша під фактичний робочий набір, увімкнули блокове стиснення колекцій і налаштували інтервали контрольних точок, щоб запис ішов рівними порціями, а не сплесками. Важкі аналітичні вибірки прибрали з основного вузла.
Паралельно підняли моніторинг за чотирма показниками: зростання сховища, час відповіді, частка читань з диска, кількість відмов.
Метрики до і після
- зростання сховища — плюс 8% на місяць на старті, плюс 1-2% після налаштування;
- частка операцій читання з диска — з ~30% до 3%;
- час відповіді читання — скоротився приблизно у 2,5 раза;
- відмови під навантаженням — поодинокі випадки на добу, за квартал спостережень жодного;
- обсяг файлів даних — стиснення дало триразове скорочення, резервні копії збираються в рази швидше.
Окремо закріпили в моніторингу оповіщення про зростання робочого набору: наступне розширення вузла планується заздалегідь, а не за фактом збою.
Чим WiredTiger відрізняється від інших движків зберігання?
WiredTiger — движок зберігання бази даних за замовчуванням в актуальній гілці: він визначає, як документи лягають на диск і як читаються назад. Відмінностей від движків із блокуваннями на рівні колекції три: журнал попереднього запису, знімки даних і кеш у пам'яті. Кожне задає свій режим експлуатації.
Журнал попереднього запису працює так: зміна спочатку потрапляє в послідовний журнал і лише потім — у файли даних. Підтвердження групуються, тому кілька операцій фіксуються одним зверненням до диска.
Це дає зрозумілу точку відновлення після аварійного завершення, але сам запис стає вузьким місцем на навантажених вузлах.
Знімки даних і модель конкурентного доступу — друга частина. Читач бачить узгоджений знімок на момент старту операції й не блокує письменників: блокування беруться на рівні документа, а не колекції.
Тому аналітична вибірка не гальмує запис, а додавання ядер дає приріст — поки робоча вибірка вміщається в пам'ять.
Кеш у пам'яті правлять найчастіше. Його розмір визначає, чи обслуговується робоча вибірка без звернень до диска: при малому кеші зростають читання з диска й хвости затримок, при завеликому — сторінки витісняє операційна система.
Впливає й стиснення: дані та індекси зберігаються стисненими, обсяг файлів і введення-виведення падає, але зростає навантаження на процесор.
Для експлуатації це означає: стежити за завантаженням кеша, чергою записів у журнал і відставанням реплік, а довгі транзакції обмежувати, щоб знімки не розросталися.
Технічні сумніви: пам'ять, стиснення, індекси, відмови
Сумніви перед зміною налаштувань зазвичай ті самі: який розмір кеша вибрати, що реально дає стиснення індексів, як відрізнити переповнення кеша від звичайного завантаження і чи допустимо правити параметри при працюючому застосунку. Нижче — короткі відповіді з практики експлуатації та офіційної документації MongoDB.
Скільки пам'яті віддавати під кеш?
Орієнтир — не загальний обсяг пам'яті, а робочий набір: індекси й гаряча частина колекцій. Поки він вміщається в кеш, читання йдуть із пам'яті; коли перестає — зростають звернення до диска, і це перша ознака, що пам'ять розподілена неправильно.
Стиснення індексів не сповільнить вибірки?
Префіксне стиснення зменшує розмір індексу на диску й ту частину, що тримається в пам'яті; розпакування лягає на процесор, але зазвичай дешевше за читання зайвих сторінок. Перемикаємо у вікно низького навантаження й стежимо за часом відгуку.
Як відрізнити завантажений кеш від переповненого?
Дивимося на спостережуваність бази даних: частка змінених сторінок, очікування витіснення, промахи кеша, затримки запису. Якщо змінені сторінки тримаються біля верхньої межі, а застосунок чекає на запис — витіснення стало вузьким місцем. Рішення ухвалюємо за динамікою за години, а не за одиничним сплеском.
Чи можна змінювати параметри при працюючому застосунку?
Частина налаштувань застосовується без перезапуску, частина потребує зупинки з вивіреним порядком дій. Перед зміною перевіряємо застосовність на льоту, фіксуємо вихідні значення й готуємо план відкату — тоді правка на живій базі не перетворюється на простій.
Обговоримо задачу: що потрібно від вас для старту
Щоб оцінка робіт по базі спиралася на факти, а не на здогади, нам вистачає короткого набору вступних. Аудит сховища починається з конфігурації WiredTiger, знімка метрик і профілю навантаження — за ними видно, де вузьке місце і що змінювати першим.
- Поточні параметри: розмір кеша WiredTiger, вибраний режим стиснення колекцій та індексів, налаштування журналу попереднього запису.
- Співвідношення обсягів: скільки займає набір даних та індекси відносно доступної пам'яті — це одразу показує, впираємося ми в кеш чи в диск.
- Знімок метрик за характерний період: частка витіснення сторінок із кеша, черги на запис, затримки читання, зростання кількості звернень до диска.
- Профіль навантаження: пікові години, нічні пакетні завдання, важкі вибірки, поведінка реплікації.
- Схема даних: які колекції зростають швидше за інші, де невикористовувані або дублюючі індекси.
- Топологія й обмеження: один вузол чи набір реплік, чи є шардування, яке вікно допустиме для обслуговування і які вимоги до відмови.
- Історія спроб: що вже змінювали в налаштуваннях, який був ефект і на що скаржаться користувачі.
На виході ви отримуєте план робіт з етапами, пріоритетами й точкою повернення до вихідної конфігурації, а також пропозицію щодо супроводу бази даних — регулярний контроль метрик і коригування параметрів у міру зростання. Опишіть задачу й додайте те, що є зі списку: повернемося з оцінкою та планом.
