Если вы ведёте общий пул удалённых Mac для CI, вы постоянно балансируете параллельные Git- и пакетные pull с дисковым IO, конкуренцией за кеш и нестабильным WAN. В этом FAQ — готовые пороги заполнения диска, глубины очередей, таймауты и потолки backoff, которые можно перенести в runbook, плюс пошаговые сценарии для «зелёного» пула, переполненного диска и слабой сети. Детальная настройка pull — в гайде по ускорению Git и Docker pull; полный список материалов — в разделе блога.

Ёмкость пула и модель параллелизма

Считайте каждый удалённый Mac в пуле сборок отдельным IO-доменом: один быстрый SSD обычно обслуживает workspace, глобальные кеши и иногда слои Docker. CPU может быть простаивающим, пока диск забит — поэтому лимиты параллелизма выводите из наблюдаемой задержки pull, а не из числа ядер.

Базовая модель: разделяйте сетевые загрузки (clone/fetch, реестры) и метаданные (npm install с огромным деревом, резолвер CocoaPods, обновление формул Homebrew). Сетевые джобы можно частично перекрывать; «тяжёлые по метаданным» на одном томе держите редкими.

Сценарий Макс. параллельных сетевых Git-операций / хост Тяжёлые npm / CocoaPods install Заметки
Один общий раннер (один диск workspace) 2–3 1 Безопасный старт; повышайте только если iowait низкий и p95 времени pull не растёт.
Хост пула (NVMe, отдельный том кеша) 4 2 Вынесите /Volumes/cache от workspace — меньше фрагментации и конкуренции.
Пик / релизный день Как в штате Тот же или ниже Лучше очередь джоб, чем рост параллельных install — пики коррелируют с порчей кеша и таймаутами.

Шаги (новый пул): (1) Задайте оркестратору лимит параллельных джоб на хост по строке «один общий раннер». (2) Прогоните 30-минутный soak с типовыми пайплайнами. (3) Если p95 задержки диска и доля сбоев pull стабильны — увеличьте параллелизм Git на один шаг и снова замерьте.

Очереди и блокировки Git / npm

Одних лимитов параллелизма мало: при конкуренции за запись несколько джоб, обновляющих один префикс Homebrew, глобальный кеш npm или CocoaPods, внутри сериализуются и дают «случайные» зависания или ошибки блокировок.

Паттерны:

  • Мьютекс на хосте для изменяющих операций: файловая блокировка (например /var/run/macpull-brew.lock) вокруг brew upgrade или tap в общих образах; джобы только с чтением бутылок могут обходить lock.
  • Кеш npm на джобу: npm_config_cache=$WORKSPACE/.npm-cache для записи; в общий read-only кеш выкладывайте по расписанию отдельным pre-pull.
  • Git: изоляция GIT_OBJECT_DIRECTORY — только если понимаете переиспользование pack; иначе — shallow clone и локальные зеркала-референсы на диске.
Механизм Типичная глубина очереди Таймаут ожидания (fail джобы)
Глобальный mutex Homebrew 1 владелец 15–30 мин (слабая сеть)
Общий кеш npm (запись) 1–2 20–45 мин
Git fetch в локальное зеркало 4–8 10–20 мин (connect + передача)

Пороги диска и разделов кеша

APFS на малых объёмах свободного места плохо переносит крупные последовательные записи (pack-файлы, слои Docker). Используйте ступенчатые пороги на томе workspace + кеш, а не только на корне системы.

Занято % (df) Действие автоматики Действие оператора
≤ 80% Обычное планирование Нет
80–85% Алерт; −1 к параллельным pull; LRU-вытеснение кеша Разбор крупных каталогов (DerivedData, Docker, старые workspace)
85–90% Пауза новых клонов / крупных install; добить текущие джобы Очистка или перенос кешей; расширение тома или новый узел
> 90% Жёсткий стоп новых джоб; дренаж очереди Аварийная очистка; проверка снимков APFS

Дополнительно держите ≥ 15–25 ГБ абсолютно свободно на основном томе данных (срабатывает то правило, что наступит раньше). Раскладку кеша согласуйте с стратегией кеша Git и npm на удалённом Mac CI, чтобы политика вытеснения была предсказуемой.

Слабая сеть: таймауты, повторы и возобновление

Частая причина нестабильности пула — шторм повторов после краткого сбоя реестра: все джобы ретраятся синхронно. Ограничьте агрессивность и включите экспоненциальный backoff с джиттером на уровне оркестратора или обёртки.

Слой Параметр Стартовое значение
Git (HTTP) http.lowSpeedLimit / http.lowSpeedTime 1000 Б/с · 60–120 с
Git (обёртка) kill по времени процесса 45–90 мин полный clone; 15–25 мин fetch
npm fetch-timeout / fetch-retries 300000 мс / 5
curl / универсально --connect-timeout 30–60 с
Повтор оркестратора потолок backoff 30 → 60 → 120 с (+ jitter); 3–5 попыток

Сочетайте таймауты с возобновляемыми сценариями: partial clone (--filter=blob:none) где разрешено, переиспользование кеша npm, pull образов с локальными слоями. Точечные ручки Git/Homebrew/npm — в FAQ по стабильности загрузок.

A
Слабый WAN, своё зеркало рядом: сначала пул на внутреннее зеркало; высокие таймауты оставьте только на последнем участке до апстрима.
B
Корпоративный прокси с обрывами: уменьшите параллельные Git-операции на 1; connect timeout 60 с; единый проход обновления прокси-аутентификации.

Приёмка и метрики мониторинга

Меняйте пороги только если метрики держатся полную рабочую неделю:

  • Доля сбоев pull < 0,5% джоб (сеть + диск).
  • p95 времени этапа «зависимости» в пределах ±20% от базы после изменения параллелизма.
  • Заполнение диска выше 85% менее 5% минут в пике.
  • iowait (или прокси задержки диска в macOS) не растёт неделя к неделе.

Алерты направляйте в тот же канал, что и перезапуски гипервизора или хоста, чтобы он-call связывал всплески дискового IO с изменениями планировщика.

Частые вопросы (FAQ)

Один большой SSD или раздельные тома? Разделение workspace и кеша упрощает вытеснение и снижает риск, что одна джоба заполнит том с ОС. На одном томе задайте более жёсткие пороги.

Почему после короткого падения сети падают все джобы разом? Эффект стада при повторе. Добавьте джиттер к backoff и временно снизьте лимиты параллельного pull, пока ошибки не нормализуются.

Допустим ли NFS для Git workspace? Только с осторожностью — задержка убивает Git и пакетные менеджеры. Для workspace предпочтителен локальный NVMe; NFS — для артефактов преимущественно на чтение.

Где взять помощь по планированию ёмкости? См. центр помощи MacPull (без входа для просмотра); выделенные узлы и регионы — на страницах тарифов и оформления аренды.

Итоги

Здоровый пул сборок на удалённом Mac опирается на диско-центричный параллелизм, явные очереди и блокировки вокруг общих хранилищ пакетов, ступенчатые пороги диска и сдержанные таймауты и повторы в слабой сети. Начните с таблиц из этой статьи, соберите метрики pull и IO за неделю, затем меняйте по одному параметру за раз.

Когда нужна предсказуемая ёмкость Apple Silicon — SSH/VNC, стабильный egress и возможность изолировать кеши — тарифы MacPull на удалённый Mac позволяют масштабировать пул без закупки железа. Откройте центр помощи, сравните тарифы или сразу перейдите к оформлению аренды; продолжить чтение можно в материале об ускорении pull и в блоге — всё это доступно без входа в аккаунт.

Выделенный удалённый Mac для вашего пула сборок

Узлы класса Mac Mini с SSH/VNC — настройте параллелизм и диск под свои пайплайны. Тарифы, покупка и гайды без обязательного логина.

Готовность к пулу
Диск и кеш
CI и pull