Настройка MongoDB WiredTiger, когда база упирается в память и диск
Когда база упирается в память и диск, деградация начинается незаметно: кэш WiredTiger перестаёт вмещать рабочий набор, и всё большая доля чтений уходит мимо него — сначала на быстрый носитель, затем вглубь. Пока запас есть, метрики ровные, но стоит активному набору данных превысить доступный кэш, как вытеснение данных на диск перестаёт успевать за потоком изменений. База не падает — она замедляется, и это самый неприятный класс сбоя: формально всё живо, фактически сервис не держит нагрузку.
Первым проявляется рост задержки ответа базы: запросы встают в очередь на изменённых страницах, которую не успевают сбрасывать фоновые потоки. Задержка растёт нелинейно — при небольшом превышении рабочего набора над кэшем отклик ухудшается в разы, а не на проценты. Дальше срабатывает обратная связь: приложение копит соединения и агрессивнее перечитывает одни и те же данные, давление на кэш ещё выше.
Следом расходятся реплики. Вторичные узлы повторяют поток операций первичного, и как только тот перестаёт успевать за нагрузкой, отставание реплик нарастает на глазах. Чтение с реплик начинает отдавать устаревшие данные, а отчётность и фоновые задачи — работать по неполной картине. По сути один упёршийся в память узел тянет за собой весь кластер.
Простое «добавим памяти» проблему не снимает: без согласования размера кэша с рабочим набором, компрессии блоков, политики вытеснения и периодичности контрольных точек тот же предел наступит снова. Именно поэтому настройка MongoDB WiredTiger — это работа с параметрами и мониторингом, а не одной правкой конфигурации, и дальше разбираем, как это закрывается: от диагностики по внутренним счётчикам движка до выбора схемы сжатия под профиль данных.
Что меняется после подбора параметров кэша и сжатия
Подбор параметров — это не разовая правка конфигурации, а проверка гипотез по метрикам. Смотрим на три среза: сколько рабочего набора остаётся в памяти, какой объём коллекция занимает на диске и как ведёт себя вторичный узел под нагрузкой. Ниже — сдвиги, по которым видно, что настройка MongoDB WiredTiger дала результат, а не совпала с разовым всплеском трафика.
| Что измеряем | До подбора | После подбора |
|---|---|---|
| Эффект настройки кэша | рабочий набор вытесняется на диск в часы пик | горячие данные держатся в памяти, промахи выходят на плато |
| Сжатие коллекций | объём на диске близок к логическому | записывается в разы меньше, постоянная допись не раздувает файлы |
| Дисковый ввод-вывод | пики на каждом всплеске нагрузки | ровный фон, очередь запросов к диску короче |
| Задержка репликации | растёт до десятков секунд под нагрузкой | держится в узком стабильном коридоре |
| Время восстановления | подъём узла после сбоя затягивается | узел входит в строй заметно быстрее |
Что держим на дашборде
Доля попаданий в кэш, глубина очереди запросов к диску, лаг вторичных узлов, коэффициент сжатия по каждой коллекции и время подъёма узла после перезапуска. Снимаем эти значения до и после правок и храним графиками: без базовой линии через месяц уже никто не докажет, что стало лучше.
Какие отказы перестают возникать
Уходит вытеснение страниц на диск в часы пик — именно оно даёт ступенчатый рост задержек, который не лечится масштабированием. Выравнивается лаг реплик, поэтому чтение со вторичных узлов перестаёт отдавать устаревшие данные. Перезапуск и восстановление укладываются в предсказуемое окно, а коллекции с постоянной дописью больше не съедают диск.
Сравнение подходов: сжатие, кэш и раскладка коллекций
Решение о сжатии и раскладке принимается от профиля нагрузки, а не по умолчанию: доля чтения, размер рабочего набора, срок востребованности данных. WiredTiger позволяет задать сжатие отдельно для коллекции и отдельно для индексов, поэтому один и тот же сервер может держать горячие данные с быстрым кодеком, а архив — с плотным. Ошибка в выборе бьёт по задержке чтения сильнее, чем экономит место: плотное сжатие экономит диск, но добавляет работу процессору на каждом чтении.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Сжатие по умолчанию, быстрый кодек | Рабочий набор не помещается в память, преобладает запись | Выигрыш по объёму умеренный, ускорения чтения нет |
| Плотный кодек на отдельные коллекции | Архивные и редко читаемые коллекции, важен объём на диске | Процессорная нагрузка выше, чтение медленнее |
| Горячие коллекции в отдельной базе с увеличенным кэшем | Две-три коллекции дают основную долю запросов | Память конечна: чем больше «горячих», тем раньше вытеснение |
| Вынос архивных данных | Данные старше срока востребованности, отчётность редкая | Нужны правила переноса и единая точка доступа для отчётов |
| Гибридный вариант | Крупная система с разным профилем по коллекциям | Требует мониторинга и периодического пересмотра настроек |
Крайности ломаются предсказуемо. Если сжать максимально всё, сервер упирается в процессор, а задержка чтения растёт на ровном месте. Если держать в кэше весь рабочий набор, физический предел памяти возвращает вытеснение и промахи — просто позже и незаметнее.
Гибридный вариант разводит коллекции по назначению: горячие остаются с быстрым кодеком и увеличенным кэшем, архив уезжает в отдельную раскладку с плотным сжатием, отчётность читает вынесенные данные. Настройки при этом пересматриваются по метрикам, а не выставляются один раз.
Порядок работ: от профиля нагрузки до передачи под контроль
Работы идут от замера реальной нагрузки: один и тот же набор параметров WiredTiger на разных профилях даёт противоположный результат — где-то выигрыш по задержке, где-то просадку по пропускной способности. Порядок ниже построен так, чтобы каждое изменение опиралось на предыдущий замер и не ломало уже достигнутое.
- Аудит и профиль нагрузки. Снимаем статистику операций чтения и записи, долю попаданий в кэш, длительность медленных запросов, пиковые окна. На выходе — модель нагрузки, от которой считаем остальное.
- Схема хранения и индексы. Разбираем структуру документов, состав и размер индексов, фрагментацию, размещение данных и журнала на дисках. Лишние индексы убираем, недостающие добавляем: до правки параметров это даёт больше, чем сама настройка.
- Подбор параметров. Считаем размер кэша под рабочий набор и доступную память, выбираем алгоритм и уровень сжатия для коллекций и индексов, настраиваем журнал и периодичность контрольных точек. Каждое значение обосновано замером, а не справочником.
- Проверка под нагрузкой. Воспроизводим профиль на стенде и сравниваем задержки, пропускную способность и потребление памяти до и после. Отдельно смотрим поведение при переполнении кэша и на пике — там настройки проявляют себя.
- Наблюдаемость и пороги. Выводим ключевые метрики, задаём пороги и оповещения по ним, чтобы деградация становилась видна до жалоб пользователей.
- Передача сопровождения. Отдаём конфигурации, описание схемы, карту метрик и порядок отката, разбираем с вашей командой типовые ситуации.
Что остаётся у вас: конфигурации, схемы и регламенты
Комплект передаём рабочими артефактами, а не папкой файлов: конфигурации лежат в системе контроля версий рядом с кодом, схемы — в виде диаграмм, регламенты — в виде пошаговых инструкций с командами. По каждому пункту понятна точка входа: с чего начать при инциденте и кто отвечает на вашей стороне.
- Конфигурация кластера. Параметры WiredTiger: размер кэша под рабочий набор, сжатие коллекций и журнала, интервалы контрольных точек; значения параметризованы по окружениям, секреты вынесены отдельно.
- Схема размещения данных. Что шардируется и по каким ключам, что остаётся на репликах, где граница горячих и архивных коллекций, какие индексы обязаны существовать.
- Политики доступа. Роли по принципу минимально необходимых прав, отдельные учётные записи для приложений, репликации и мониторинга, порядок ротации.
- Регламент мониторинга. Метрики и пороги, готовые запросы для разбора роста задержек, отставания реплик и заполнения диска, порядок эскалации.
- Документация по эксплуатации. Подъём узла с нуля, плановое переключение, восстановление из копии — с оценкой времени каждого шага.
- План резервного копирования. Расписание, глубина хранения, обязательная проверка восстановления на тестовом контуре.
- Ориентиры производительности. Профили нагрузки и эталонные значения до и после изменений — видно, где норма, а где деградация.
Кейс: рост хранилища замедлился, отказы под нагрузкой ушли
Что было до изменений
Кластер MongoDB обслуживал каталог товаров: ночной пересчёт, поток событий от приложений и постоянные чтения. За полгода объём данных вырос почти втрое, кэш хранилища оставался на значении по умолчанию и не покрывал рабочий набор — заметная часть чтений уходила на диск. В часы пик это давало отказы под нагрузкой: время ответа выходило за целевое, часть операций завершалась ошибкой по превышению времени ожидания, реплика отставала от мастер-узла.
Что сделали
Пересчитали размер кэша под фактический рабочий набор, включили блочное сжатие коллекций и настроили интервалы контрольных точек, чтобы запись шла ровными порциями, а не всплесками. Тяжёлые аналитические выборки убрали с основного узла. Параллельно подняли мониторинг по четырём показателям: рост хранилища, время ответа, доля чтений с диска, число отказов.
Метрики до и после
- рост хранилища — плюс 8% в месяц на старте, плюс 1-2% после настройки;
- доля операций чтения с диска — с ~30% до 3%;
- время ответа чтения — сократилось примерно в 2,5 раза;
- отказы под нагрузкой — единичные случаи в сутки, за квартал наблюдений ни одного;
- объём файлов данных — сжатие дало трёхкратное сокращение, резервные копии собираются в разы быстрее.
Отдельно закрепили в мониторинге оповещение о росте рабочего набора: следующее расширение узла планируется заранее, а не по факту сбоя.
Чем WiredTiger отличается от других движков хранения?
WiredTiger — движок хранения базы данных по умолчанию в актуальной ветке: он определяет, как документы ложатся на диск и как читаются обратно. Отличий от движков с блокировками на уровне коллекции три: журнал предзаписи, снимки данных и кэш в памяти. Каждое задаёт свой режим эксплуатации.
Журнал предзаписи работает так: изменение сначала попадает в последовательный журнал и только потом — в файлы данных. Подтверждения группируются, поэтому несколько операций фиксируются одним обращением к диску. Это даёт понятную точку восстановления после аварийного завершения, но сама запись становится узким местом на нагруженных узлах.
Снимки данных и модель конкурентного доступа — вторая часть. Читатель видит согласованный снимок на момент старта операции и не блокирует писателей: блокировки берутся на уровне документа, а не коллекции. Поэтому аналитическая выборка не тормозит запись, а добавление ядер даёт прирост — пока рабочая выборка помещается в память.
Кэш в памяти правят чаще всего. Его размер определяет, обслуживается ли рабочая выборка без обращений к диску: при малом кэше растут чтения с диска и хвосты задержек, при слишком большом — страницы вытесняет операционная система. Влияет и сжатие: данные и индексы хранятся сжатыми, объём файлов и ввода-вывода падает, но растёт нагрузка на процессор.
Для эксплуатации это значит: следить за загрузкой кэша, очередью записей в журнал и отставанием реплик, а длинные транзакции ограничивать, чтобы снимки не разрастались.
Технические сомнения: память, сжатие, индексы, отказы
Сомнения перед изменением настроек обычно одни и те же: какой размер кэша выбрать, что реально даёт сжатие индексов, как отличить переполнение кэша от обычной загрузки и допустимо ли править параметры при работающем приложении. Ниже — короткие ответы по практике эксплуатации и официальной документации MongoDB.
Сколько памяти отдавать под кэш?
Ориентир — не общий объём памяти, а рабочий набор: индексы и горячая часть коллекций. Пока он помещается в кэш, чтения идут из памяти; когда перестаёт — растут обращения к диску, и это первый признак, что память распределена неверно.
Сжатие индексов не замедлит выборки?
Префиксное сжатие уменьшает размер индекса на диске и ту часть, что держится в памяти; распаковка ложится на процессор, но обычно дешевле чтения лишних страниц. Переключаем в окно низкой нагрузки и следим за временем отклика.
Как отличить загруженный кэш от переполненного?
Смотрим на наблюдаемость базы данных: доля изменённых страниц, ожидание вытеснения, промахи кэша, задержки записи. Если изменённые страницы держатся у верхней границы, а приложение ждёт на записи — вытеснение стало узким местом. Решение принимаем по динамике за часы, а не по одиночному всплеску.
Можно ли менять параметры при работающем приложении?
Часть настроек применяется без перезапуска, часть требует остановки с выверенным порядком действий. Перед изменением проверяем применимость на лету, фиксируем исходные значения и готовим план отката — тогда правка на живой базе не превращается в простой.
Обсудим задачу: что нужно от вас для старта
Чтобы оценка работ по базе опиралась на факты, а не на догадки, нам хватает короткого набора вводных. Аудит хранилища начинается с конфигурации WiredTiger, снимка метрик и профиля нагрузки — по ним видно, где узкое место и что менять первым.
- Текущие параметры: размер кэша WiredTiger, выбранный режим сжатия коллекций и индексов, настройки журнала предзаписи.
- Соотношение объёмов: сколько занимает набор данных и индексы относительно доступной памяти — это сразу показывает, упираемся мы в кэш или в диск.
- Снимок метрик за характерный период: доля вытеснения страниц из кэша, очереди на запись, задержки чтения, рост числа обращений к диску.
- Профиль нагрузки: пиковые часы, ночные пакетные задания, тяжёлые выборки, поведение репликации.
- Схема данных: какие коллекции растут быстрее остальных, где неиспользуемые или дублирующие индексы.
- Топология и ограничения: один узел или набор реплик, есть ли шардирование, какое окно допустимо для обслуживания и какие требования к отказу.
- История попыток: что уже меняли в настройках, какой был эффект и на что жалуются пользователи.
На выходе вы получаете план работ с этапами, приоритетами и точкой возврата к исходной конфигурации, а также предложение по сопровождению базы данных — регулярный контроль метрик и корректировку параметров по мере роста. Опишите задачу и приложите то, что есть из списка: вернёмся с оценкой и планом.
