Carat::BuildPool

Параллельные crystal build масштабируются ~N по wall-clock (один процесс — фактически одно ядро на кодоген), но каждый компилятор держит ~1-2 ГБ RAM, поэтому фиксированная ширина пула, подобранная под одну машину, на другой уходит в OOM. Вместо этого ширина выводится из ТЕКУЩЕГО состояния машины (Sysinfo): ядра ограничивают сверху, MemAvailable / замеренный peak RSS компилятора — снизу:

workers = min(ядра, MemAvailable * 0.7 / peak_rss, 8, |jobs|)

Peak RSS не угадывается, а измеряется: первая сборка греет слот j0 кэша компилятора, пока сэмплируется RSS её процесса (carat + все дети — crystal, cc); слот затем клонируется в пустые слоты воркеров (паттерн из Rakefile egui.cr, обобщённый). Перед выдачей каждого следующего задания гейт перепроверяет MemAvailable и придерживает очередь, когда свободной памяти меньше (peak + запас) — случай «один бинарник тяжелее остальных» замедляет пул, а не валит его. Сборка, всё-таки умершая от OOM (exit 137 / SIGKILL), после осушения пула ретраится один раз последовательно.

Конкурентные компиляторы также гоняются на общем ~/.cache/crystal (tmp-переименования), поэтому каждый воркер получает свой персистентный CRYSTAL_CACHE_DIR: <корень шарда>/.carat/cache/jN — он живёт между запусками, второй и дальнейшие прогоны тёплые. CARAT_JOBS=N отключает адаптивный подбор (бенчмарки, A/B-прогоны).