2026 Удалённый Mac в шести регионах: диск заполнен? Расширение 1 ТБ/2 ТБ vs очистка кэша vs вторая машина—FinOps-матрица «выбери одно»

Около 11 мин чтения · MACCOME

Итог: если на выделенном удалённом Mac (M4 / M4 Pro) в Сингапуре, Японии, Корее, Гонконге, US East или US West снова «диск почти полон, а сборки медленнее», эта статья даёт решение для подписи. Выберите между расширением 1 ТБ/2 ТБ, управлением кэшем и второй пиковой машиной через матрицу «выбери одно», runbook из 6 шагов и три порога уровня воды, затем привяжите выбор к дневной, месячной или квартальной аренде. Мы не повторяем задержку региона или полный POC; продолжаем после приёмки стабильности перед продом: тратить на диск или менять использование узла.

Шесть типичных ошибок при заполненном диске удалённого Mac

  1. Путать восстанавливаемый раздувание со структурным дефицитом. DerivedData, старые runtime Simulator, слои Docker и кэши Gradle часто дают 40–70 % освобождаемого места. Только если после еженедельной очистки свободное место снова падает ниже 15 % за семь дней, открывайте обсуждение расширения или второй машины.
  2. Смотреть только проценты df без атрибуции каталогов. Снимки APFS, локальные снимки Time Machine и «другие пользователи» красят корень в красный; Xcode чаще тормозит из‑за линейного роста одного каталога. Нужен слоистый du, а не слепой rm -rf.
  3. Считать больший диск панацеей при насыщенных очередях CPU/памяти. Если iostat долго показывает загрузку диска <40 %, а сборки медленные, узкое место — параллелизм или память линкера. M4 Pro или вторая машина эффективнее 2 ТБ.
  4. Monorepo + несколько Simulator на baseline 256 ГБ. Partial clone уменьшает fetch, но локальные промежуточные артефакты и образы симулятора копятся по веткам и версиям ОС. Читайте чеклист облегчения Monorepo.
  5. Один узел «несёт всё» в шести регионах. Сборка, UI-тесты и загрузка подписи на одном диске заполняют пороги одновременно в пиковую неделю. FinOps runbook мульти-машинного пула делит роли; здесь сначала политика диска на одном узле.
  6. Месячное расширение на двухнедельный спринт или ежедневная очистка на годовой baseline. FinOps: предсказуемый постоянный рост → 1 ТБ/2 ТБ + месячная/квартальная аренда; короткие пики → очистка + вторая машина посуточно. Не фиксируйте годовой tier на 14 дней.

Выделенные удалённые Mac дают чёткую границу физического диска, но граница ≠ автоматическое соответствие workload. На unified memory Apple Silicon давление на диск и RAM часто совпадает по фазе: параллельные Simulator, инкрементальная компиляция Swift и кэши слоёв контейнеров одновременно поднимают IO и RAM. Без решения «выбери одно» команды метаются между «ещё раз очистить» и «ещё одна машина», теряя бюджет аренды и темп релизов.

Гид по стоимости узлов Mac mini в нескольких регионах отвечает на страну и срок аренды; эта статья — на первичный порядок действий при дисковом узком месте на выбранном узле. Дополняет чеклист зеркал CocoaPods/SPM и диска—оптимизация зависимостей снижает ложное «диск полон», но не заменяет управление DerivedData и активами симулятора.

Сигнал Приоритет: управление кэшем Приоритет: 1 ТБ/2 ТБ Приоритет: 2-я машина / Pro
Свободно <15 % через 7 дней после очистки Только если du показывает >30 % восстанавливаемого и стандартная очистка не выполнялась По умолчанию: структурный рост (multi-branch DerivedData) Очередь CPU p95 насыщена в том же окне
Один репо <8 ГБ, 3+ OS Simulator Удалить неиспользуемые runtime и наборы устройств 2+ крупных образа OS постоянно Параллельных UI-test worker >2
Monorepo + affected, еженедельно полон Проверить blobless и пути кэша По умолчанию: промежуточные каталоги не изолированы Сборка и тест должны разделить диск/машину
Пик релиза только 10–14 дней По умолчанию: очистка + экспорт снимка Не фиксировать квартальную аренду на две недели Посуточная/понедельная 2-я машина выгоднее
После 2 ТБ iowait <8 % и всё ещё медленно Диск не главная причина — прекратить расширение Вето: больше не добавлять диск По умолчанию: узкое место вычислений/параллелизма
storage

Механизм: copy-on-write APFS означает, что удаление большого каталога может не сразу вернуть отображаемое свободное место — особенно при локальных снимках. В governance нужна инвентаризация снимков; иначе «удалили 200 ГБ, df вернул 20 ГБ» ведёт к ложному решению о расширении.

Runbook из 6 шагов: от сэмплинга до подписанного выбора

  1. Зафиксировать baseline уровня воды. Общая ёмкость, процент свободного, основные mountpoints; ID узла, версия Xcode, последний commit очистки (версия скрипта).
  2. Слоистый du-сэмплинг (top 12 каталогов). ~/Library/Developer, DerivedData, CoreSimulator, ~/.gradle, ~/Library/Containers и т.д.; CSV для аудита.
  3. Выполнить стандартный пакет очистки. Порядок: DerivedData (текущую scheme можно оставить), неиспользуемые runtime Simulator, dangling-образы Docker, старые Archives (подтверждение release owner).
  4. Перемерить наклон за 24 ч. Если свободное место падает >3 п.п. в день без объяснимого релиза — пометить структурный рост.
  5. Сопоставить с веткой матрицы. Управление кэшем / 1 ТБ·2 ТБ / вторая машина — не «очистка + расширение + машина» без обоснования.
  6. Зафиксировать FinOps-заметку и срок аренды. Структурное → месячная/квартальная + расширение; короткий пик → посуточная/понедельная вторая машина; дата пересмотра в ledger.
bash
# Сэмплинг top-каталогов на удалённом Mac (замените WORK)
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

Три количественных порога для review (константы замените своим baseline)

  • Коэффициент отдачи очистки. Стандартный пакет должен освободить не менее 18 % текущего занятого места; ниже 12 % — рост структурный, матрица расширения/второй машины, а не повторная очистка.
  • Красная линия свободного места. Prod build host: держать ≥20 % свободно; ниже 15 % — запрет полного Archive + параллельных UI-тестов (общие gate-поля с матрицей KPI масштабирования POC).
  • Проверка IO после расширения. В течение 48 ч после 1 ТБ/2 ТБ: медиана busy% <25 % без улучшения времени сборки — на review закрыть опцию «ещё диск», проверить CPU, память и RTT артефактов.

Заключение: не прячьте разделение архитектуры за «ещё один диск»

На удалённых Mac в шести регионах решение по диску — это разделение несжимаемых working set и сжимаемых кэшей. Восстанавливаемое → governance; невосстанавливаемое → расширение или разделение; невосстанавливаемое и вычисления насыщены → стоп диск — это лишь placebo для очереди.

Самостоятельный хостинг Mac или краткоживущие cloud-инстансы делят «диск» и «ops» на два счёта; команды недооценивают снимки, активы симулятора и общие диски. Передача сборок через ноутбук в релизную неделю одновременно бьёт по диску и политике сна. Для команд, которым нужны выделенный Apple Silicon, предсказуемые tier диска и узлы в шести регионах, прикрепление этой матрицы к закупке и выравнивание 1 ТБ/2 ТБ с арендой на Mac-облаке MACCOME обычно дешевле ad-hoc расширений — CI и on-call говорят на одном языке уровня воды.

После фиксации расширения или второй машины перенесите регион и строки аренды в тот же review. Цены и циклы — на продуктовой странице; статьи приёмки стабильности и Monorepo оставьте приложениями, чтобы в релизную неделю обсуждали и ёмкость, и pipeline.

FAQ

После очистки DerivedData диск всё ещё полон—расширять или добавить машину?

Если свободное место снова падает ниже 15 % за семь дней и подкаталоги Developer доминируют в du, оцените 1 ТБ/2 ТБ с месячной арендой. При насыщении очередей CPU/памяти добавьте вторую машину по статье build pool. Tier и цены: тарифы аренды Mac mini.

После расширения до 2 ТБ сборки всё ещё медленные—это диск?

Не обязательно. При idle IO и медленной компиляции вернитесь к приёмке стабильности и архитектурным матрицам. Операционные детали: центр помощи.