2026 Аренда Mac Mini 7×24: матрица Valkey (совместим с Redis) — окно перезаписи AOF, фрагментация памяти и водоразделы диска APFS

Время чтения: 8 мин

Valkey — открытый движок, совместимый с протоколом Redis, но на одном томе APFS он ведёт себя как «тяжёлый сосед»: дочерний процесс при BGREWRITEAOF, рост appendonly.aof и временные копии при перезаписи упираются в абсолютный запас гигабайт, а не только в «красивый» процент свободного места. Для 7×24 на арендованной Mac Mini полезно зафиксировать числа в таблице и повесить их на мониторинг до первой ночи с полным батчем.

Ниже — сводная матрица, затем отдельные блоки по персистентности, maxmemory, бэкапу и сосуществованию долгих задач с кэшем, плюс готовые пороги и команды. База по классическому стеку AOF/RDB — в матрице Redis; водоразделы APFS — в FAQ по диску; очереди и ретраи рядом с брокером — в матрице Sidekiq и Redis. Оформить узел можно через публичную страницу аренды там, где доступно без обязательного входа.

Матрица решений 7×24

Столбцы — типичный профиль нагрузки на одной машине. Числа согласуйте с разделом порогов и с фактическим размером AOF после недели продакшена.

Тема Преимущественно кэш Смешанный режим (воркеры рядом) Жёсткая долговечность / малый SSD
Перезапись AOF appendfsync everysec, автоматический rewrite, ночной сдвиг пиков Ручной BGREWRITEAOF не ближе 15 минут к BGSAVE и тяжёлому I/O батча Чаще ручное окно; поднимайте auto-aof-rewrite-min-size, чтобы реже форкаться на узком диске
Фрагментация RSS Цель: mem_fragmentation_ratio стабильно < 1,3 > 1,5 несколько часов — разбор; > 1,8 — план activedefrag в тихое окно activedefrag только с лимитом CPU и после снимка метрик
maxmemory Ориентир ~65% RAM под кэш, allkeys-lru 55–60% под Valkey, по очередям — noeviction или volatile-lru noeviction для критичных ключей + явные ошибки на клиенте
Диск APFS Жёлтая зона: < 20% свободно Перед rewrite: жёлтая также при < 5 ГиБ абсолютного запаса Красная: < 10% или < 2 ГиБ — стоп новой записи, отложить rewrite

Стратегия персистентности

Включайте appendonly yes там, где нужна история команд между перезапусками. Пара auto-aof-rewrite-percentage (часто стартуют с 100) и auto-aof-rewrite-min-size (например 64mb) задаёт частоту автоматических перезаписей: при быстром росте лога сначала увеличьте min-size, чтобы не ловить серию fork подряд. appendfsync always сужает окно потери при жёстком отключении питания, но бьёт по задержкам и конкурирует с fsync других сервисов на том же томе; для смешанных нагрузок разумный старт — everysec, а «аудиторский» режим оставьте узким контуром ключей или отдельным инстансом.

Перед ручным BGREWRITEAOF выполните INFO persistence и убедитесь, что aof_rewrite_in_progress:0. Планируйте операцию в коридор низкой нагрузки и не накладывайте её на массовый экспорт, индексацию или копирование всего каталога данных средствами вроде rsync без контроля полосы — они делят с Valkey одну и ту же очередь I/O APFS.

maxmemory и вытеснение

Задайте maxmemory так, чтобы после него оставались память под ОС, стек воркеров и сетевые буферы: на практике это часто 55–65% физической RAM для одного инстанса на «смешанной» Mac Mini. Политика allkeys-lru подходит для восстанавливаемого кэша; volatile-lru — когда вытеснять имеет смысл только ключи с TTL; noeviction — когда «тихое» удаление недопустимо и приложение должно получить ошибку записи и сигнал для бэкпрешсура.

Алерты вешайте на used_memory относительно maxmemory: предупреждение около 80%, критично около 95%, синхронно с политикой вытеснения и лимитами на стороне продюсеров. Так вы увидите переполнение раньше, чем начнёт страдать latency чтения из-за борьбы за CPU с фоновыми задачами ОС.

maxmemory-policy Когда уместна
allkeys-lruКэш, данные легко перечитать
volatile-lruВытеснение только среди ключей с TTL
noevictionОчереди, блокировки, финансовые идемпотентные ключи

Окно резервного копирования

Копирование живых файлов AOF и одновременная перезапись ведут к двойной нагрузке на диск и к риску «подглядывания» неатомарного состояния. Фиксируйте расписание: минимум 15 минут зазора между стартом BGREWRITEAOF, снимком RDB (если включён) и внешним копированием каталога данных. Минимальный стандарт хранения — две локальные генерации плюс удалённая копия; раз в квартал поднимайте копию на тестовом томе и сверяйте выборочные ключи и DBSIZE, а не только факт наличия архива.

  1. Перед копией: INFO persistence — нет активного rewrite/save.
  2. Условие «можно копировать»: свободно ≥ 20% тома и ≥ 5 ГиБ абсолютно.
  3. После: проверка целостности на отдельном пути или инстансе, спот-чеки GET по контрольным ключам.

Долгие задачи и кэш на одном узле

Один процессорный узел Apple Silicon тянет и ночной батч, и горячий кэш, пока вы жёстко разводите роли: разные номера БД, префиксы ключей и отдельные лимиты для продюсеров. Большие промежуточные массивы и файлы этапов ETL не держите в Valkey — выносите на локальный каталог с ротацией или в объектное хранилище; иначе used_memory_rss и AOF растут синхронно, а откат по диску становится дороже каждой ночи.

На жёлтом дисковом пороге включайте дроссель постановки задач в очередь; при приближении maxmemory к 80–85% продюсеры должны уметь остановиться без ручного вмешательства — это дешевле, чем аварийный rewrite на заполненном томе. Согласуйте приоритеты с launchd и nice для соседних воркеров, чтобы ночной пик не совпадал с пиком fsync без календарного сдвига.

Исполняемые пороги и команды

Соберите INFO memory и INFO persistence в одну панель; снимайте метрики вне коротких всплесков записи, чтобы не путать фрагментацию с эффектом недавнего fork.

  • mem_fragmentation_ratio: > 1,5 три последовательных замера с интервалом 5–10 минут — жёлтый алерт; > 1,8 устойчиво — красный, планируйте activedefrag или перенос горячих данных.
  • used_memory vs maxmemory: предупреждение на 80%, критично на 95%.
  • activedefrag (если доступно в вашей сборке): стартовый набор для ночного тюнинга — activedefrag yes, active-defrag-ignore-bytes 100mb, active-defrag-threshold-lower 10, active-defrag-threshold-upper 100; ужимайте CPU лимитами, чтобы не забить соседние воркеры.
  • Диск: жёлтая зона при < 20% свободно или < 5 ГиБ; красная при < 10% или < 2 ГиБ — остановка новой записи и отложенный rewrite.
valkey-cli INFO memory | egrep 'used_memory_human|used_memory_rss_human|mem_fragmentation_ratio'
valkey-cli INFO persistence | egrep 'aof_enabled|aof_rewrite_in_progress|aof_current_size'

На macOS команда может называться redis-cli в зависимости от пакета; замените бинарник, сохранив те же подкоманды INFO.

FAQ

Rewrite оборвался из‑за нехватки места — что делать
Остановите новую запись на время, освободите том (логи, старые артефакты батчей), увеличьте auto-aof-rewrite-min-size, чтобы реже входить в опасный коридор. Не запускайте повторный rewrite, пока не выйдете из красной зоны по абсолютным гигабайтам.
Низкий mem_fragmentation_ratio, но высокая задержка
Проверьте appendfsync, конкуренцию за диск с Time Machine и снимками, сетевые задержки и «горячие» ключи; используйте замедленный лог команд и профилирование клиента параллельно с INFO stats.

Итог и оформление

Устойчивый контур на арендованной Mac Mini складывается из трёх сумм: RAM под maxmemory и соседей, SSD под рост AOF и временное удвоение при rewrite, и календарных окон, где не пересекаются бэкап, BGSAVE и тяжёлый батч. Зафиксировав таблицу и пороги, возьмите конфигурацию с запасом по диску, прогоните ночь с реалистичным объёмом записи и только затем закрепляйте SLA.

Резюме для покупки: начните с узла, где выполняются все три неравенства одновременно — достаточно RAM для maxmemory ~60% плюс воркеры, достаточно SSD для текущего AOF × 2 в худший день и ≥ 5 ГиБ свободного после логов, и отдельные 15-минутные окна между rewrite, снимком и бэкапом. Затем оформите аренду на публичной странице и перенесите пороги в мониторинг до первого продакшен-пика.

Mac Mini для Valkey 7×24

RunMiniApple Silicon с запасом под AOF и долгие воркеры. Главная, тарифы, помощь, оформление аренды без обязательного входа там, где это доступно.

Добавьте в закладки главную и блог перед выбором конфигурации под ночной Valkey.

Valkey 7×24 — оформить