← На главную

NixOS на VPS: 96 МБ в простое и сборка при 512 МБ RAM

01.11.2026 14:52 · hackernews

Автор шаблона TierHive показал, как уменьшить потребление памяти NixOS 26.05 на небольшом KVM VPS. Исходная конфигурация с cloud-init работала на 1 ГБ RAM, использовала в простое 288 МБ и держала загруженными 89 модулей ядра. Обычная пересборка того же выпуска требовала 896 МБ, а при 768 МБ nix-build завершался OOM. После настройки система простаивала на 96 МБ с 54 модулями, а обновление канала и полная пересборка проходили при 512 МБ RAM с пиком 371 МБ. Замеры сделаны на собственных запусках автора через несколько минут после второй загрузки.

Заметную часть экономии дали параметры ядра. Отключение профилирования аллокаций вернуло около 6 МБ, KFENCE — 2 МБ, а отключение KSM, TPM, audit и нескольких фоновых механизмов сократило число потоков. Самым крупным одиночным эффектом стало transparent_hugepage=never: на машине с 2 ГБ освободилось 52 МБ, а при 896 МБ доступной памяти стало на 103 МБ больше. Автор оговаривает, что для производственных систем у отключения THP могут быть другие соображения.

Для виртуальной машины он занёс в чёрный список драйверы отсутствующего оборудования: звука, GPU, Wi-Fi, USB, физических сетевых карт, SCSI и ATA. Initrd оставлен только с virtio_pci, virtio_blk и ext4, а дерево модулей автоматически сокращается при каждой пересборке. На диске оно уменьшилось со 162 до 45 МБ. Также отключены systemd-resolved и systemd-oomd, синхронизация времени выполняется разовым busybox ntpd, а sshd запускается через socket activation только при подключении.

Пересборка при 512 МБ стала возможной благодаря zram с zstd, более ранней работе kswapd и настройке Boehm GC у Nix. Во время сборки zram занимал до 116 МБ физической памяти. Сокращение closure убрало документацию, шрифты, LVM и вспомогательные инструменты: размер снизился с 963 до 910 МБ, сжатого образа — с 607 до 477 МБ.

Главное оставшееся ограничение — переход между выпусками. При 512 МБ первая попытка перейти с 26.05 на unstable закончилась OOM, хотя старая генерация продолжила работать; повторный запуск после загрузки зависимостей завершился успешно. Автор рекомендует на такое обновление временно выделять больше RAM.

Читать оригинал →