Сборку пакетов в Arch ускоряют три настройки: параллельность через MAKEFLAGS, кэш компиляции ccache и перенос каталога сборки в tmpfs через BUILDDIR. Пропиши в /etc/makepkg.conf строку MAKEFLAGS=”-j$(nproc)”, установи ccache и добавь его в ту же строку, а для тяжёлых пакетов задай BUILDDIR=/tmp/makepkg. Вместе эти приёмы заметно сокращают время пересборки AUR-пакетов.
makepkg по умолчанию собирает пакет в один поток. На современном процессоре это выбрасывает почти всю мощность: пока один поток компилирует, остальные ядра простаивают. Решение простое: сказать make, сколько задач запускать одновременно.
Открой /etc/makepkg.conf и найди строку MAKEFLAGS. По умолчанию она закомментирована:
#MAKEFLAGS="-j2"
Замени её на:
MAKEFLAGS="-j$(nproc)"
Команда nproc вернёт число логических ядер процессора, и make запустит столько же параллельных задач. Для восьмиядерного CPU получится -j8, для шестнадцатипоточного -j16. Посмотреть раскладку ядер и потоков можно командой lscpu.
Не хардкодь число: если перенесёшь конфиг на другую машину, -j8 на двухъядерном ноутбуке будет ошибкой, а -j$(nproc) подстроится сам. Переменная MAKEFLAGS передаётся make при каждой сборке, поэтому настройка работает для всех пакетов сразу, и для официальных, и для AUR.
Проверить, что строка применилась, можно так:
grep -E "MAKEFLAGS|BUILDDIR" /etc/makepkg.conf
Файл /etc/makepkg.conf один на всю систему, правки в нём действуют для всех пользователей. Если собираешь пакеты от обычного пользователя, а не от root, настройки всё равно подхватятся.
Параллельность не бесплатна. Каждая параллельная задача компилятора ест память: на тяжёлых пакетах (браузеры, LLVM, ядро) один поток может занять гигабайт и больше. Если при сборке система начинает тормозить, а swap заполняется, снижай:
MAKEFLAGS="-j2"
Два потока почти всегда безопасны даже на слабых машинах. Второй риск, перегрев: на ноутбуке полная загрузка всех ядер поднимает температуру, кулер воет, а при плохом охлаждении возможны троттлинг и зависания. Заметил такое, снижай до -j2 или -j4.
Есть нюанс: пакеты на Meson собираются через ninja, а не через make, и MAKEFLAGS на них не влияет. Пакеты на CMake обычно вызывают make под капотом и параллельность подхватывают.
Во время сборки полезно смотреть на нагрузку. Открой второй терминал и запусти htop: если все ядра загружены, а память не упирается в потолок, параллельность работает как надо. Если ядра простаивают, а диск мигает, узкое место не в CPU, а в диске, и тут поможет tmpfs.
ccache кэширует результат компиляции C и C++. Когда собираешь пакет повторно, компилятор получает из кэша готовый объектный файл вместо того, чтобы перекомпилировать исходник заново. Выигрыш заметен при пересборках: обновил зависимости, пересобрал пакет, а большая часть работы уже сделана.
Как это работает: ccache перехватывает вызов компилятора, считает хэш от препроцессированного исходника и флагов сборки, и если такой хэш уже встречался, отдаёт готовый объектный файл. Компилятор даже не запускается.
Установка:
sudo pacman -S ccache
Дальше нужно, чтобы компилятор вызывался через ccache. В Arch это делается через MAKEFLAGS: добавь ccache перед gcc и g++.
MAKEFLAGS="-j$(nproc) ccache gcc ccache g++"
Теперь makepkg вызывает ccache для каждого файла C и C++. Первая сборка заполнит кэш, повторные возьмут результат из него. Кэш лежит в ~/.cache/ccache, размер по умолчанию ограничен 5 ГБ. Каталог можно поменять переменной CCACHE_DIR, если хочешь вынести кэш на другой диск.
Статистика кэша:
ccache -s
В выводе смотри строки cache hit (попадание) и cache miss (промах). Много попаданий, кэш работает. При переполнении старые записи вытесняются сами, чистить вручную обычно не нужно. Есть и строка files in cache, она показывает число сохранённых объектных файлов. Растёт число, кэш наполняется, и это хороший знак.
Важно: ccache не ускоряет первую сборку с нуля. Он окупается на повторных проходах. И ещё: некоторые PKGBUILD отключают кэш через options=(!ccache), для таких пакетов ccache не работает.
Ещё один момент: ccache чувствителен к флагам компиляции. Изменил CFLAGS в makepkg.conf, хэш поменялся, и кэш начнёт заполняться заново. Это нормально, старые записи со временем вытеснятся.
makepkg собирает пакет в каталоге, который задаёт BUILDDIR. По умолчанию это место на диске, например ~/.cache/yay. Если перенести сборку в tmpfs, файловую систему в оперативной памяти, компилятор читает и пишет исходники без обращения к SSD.
Почему это быстрее: диск отдаёт файлы блоками и ждёт контроллер, память отдаёт их за наносекунды. Для тысяч мелких файлов исходников разница огромна. Особенно заметно на HDD и на слабых SSD, где каждая операция записи стоит дорого.
В Arch /tmp монтируется как tmpfs автоматически через systemd, и /dev/shm тоже tmpfs. Проверь:
findmnt /tmp
Если в выводе есть tmpfs, /tmp уже в памяти. Если нет, используй /dev/shm, он tmpfs всегда. Почему именно /tmp, а не /dev/shm: в Arch /tmp уже tmpfs, отдельно ничего монтировать не нужно. Достаточно создать каталог и указать его в конфиге.
Создай каталог сборки:
mkdir /tmp/makepkg
chmod 1777 /tmp/makepkg
И пропиши в /etc/makepkg.conf:
BUILDDIR=/tmp/makepkg
Теперь makepkg и AUR-хелперы собирают пакеты в памяти. Скорость растёт заметно: чтение и запись исходников перестают упираться в диск.
free -h
Следить за заполнением tmpfs можно командой df -h /tmp. Если каталог сборки почти заполнил tmpfs, сборка упадёт с ошибкой про нехватку места. Тогда либо увеличивай размер tmpfs, либо возвращай BUILDDIR на диск.
Если памяти не хватает, верни BUILDDIR на диск или оставь tmpfs только для лёгких пакетов. Это тоже рабочий вариант.
Три приёма работают вместе. Параллельность ускоряет саму компиляцию, ccache убирает повторную работу, tmpfs убирает задержки диска. Для AUR-пакета это выглядит так: хелпер скачивает исходники, распаковывает их в /tmp/makepkg, компилирует в несколько потоков через ccache, а готовый пакет кладёт в кэш pacman.
Пример: пересобираешь пакет после обновления библиотеки. Хелпер скачивает новую версию исходников, распаковывает в /tmp/makepkg, компилятор идёт через ccache, и файлы, которые не менялись, берутся из кэша. Диск при этом вообще не участвует, только память. На машине с 16 ГБ RAM и больше такая связка работает без оговорок.
Отдельный плюс связки: кэш pacman остаётся на диске, готовые пакеты никуда не деваются. tmpfs ускоряет только промежуточную работу, а результат сборки хранится как обычно.
Проверить, что всё настроено, можно сборкой любого пакета из AUR. В логе makepkg появятся строки ccache в командах компиляции, а каталог сборки будет лежать в /tmp/makepkg.
Если сборка падает с ошибкой, полезно разбить её на шаги и смотреть, где именно ломается. Методика разобрана в статье «Divide and conquer: отладка сборки».
Нет. Это стандартная настройка, которую используют почти все. Единственный риск, нехватка памяти и перегрев на слабых машинах. Заметил тормоза или высокую температуру, снизь до -j2. На машинах с 16 ГБ RAM и больше проблем обычно нет. Если сомневаешься, начни с -j4 и поднимай постепенно.
По умолчанию до 5 ГБ. Текущий размер покажет команда ccache -s. При переполнении старые записи удаляются сами, чистить вручную обычно не нужно. Если кэш лежит на SSD, можно перенести его на HDD через CCACHE_DIR.
Используй /dev/shm, он смонтирован как tmpfs всегда. Либо смонтируй свой tmpfs, например в /mnt/buildtmp, и укажи его в BUILDDIR. Размер задаётся опцией size при монтировании, например size=8G.
Нет. Первая сборка заполняет кэш и идёт обычное время. Выигрыш появляется со второй сборки и дальше. Поэтому ccache имеет смысл ставить сразу, чтобы кэш копился с первых дней.
Обычно нет. ccache сам вытесняет старые записи при переполнении. Если хочешь освободить место, команда ccache -C очистит кэш полностью. После очистки следующая сборка пойдёт с нуля, так что чисти только когда место реально нужно.
Три настройки в /etc/makepkg.conf дают основной выигрыш: MAKEFLAGS=”-j$(nproc)” включает все ядра, ccache убирает повторную компиляцию, а BUILDDIR=/tmp/makepkg переносит сборку в память. Начни с параллельности, это одна строка и мгновенный эффект. Потом добавь ccache, если часто пересобираешь AUR. tmpfs подключай, когда есть свободная RAM. Вместе они превращают долгие сборки в быстрые, а пересборка AUR-пакета перестаёт быть событием на полчаса и занимает минуты.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии