Все об Arch Linux

Arch Linux будет тем, что вы из него сделаете!

Как ускорить сборку: ccache, параллельность, tmpfs

Сборку пакетов в 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, настройки всё равно подхватятся.

Когда снижать до -j2

Параллельность не бесплатна. Каждая параллельная задача компилятора ест память: на тяжёлых пакетах (браузеры, LLVM, ядро) один поток может занять гигабайт и больше. Если при сборке система начинает тормозить, а swap заполняется, снижай:

MAKEFLAGS="-j2"

Два потока почти всегда безопасны даже на слабых машинах. Второй риск, перегрев: на ноутбуке полная загрузка всех ядер поднимает температуру, кулер воет, а при плохом охлаждении возможны троттлинг и зависания. Заметил такое, снижай до -j2 или -j4.

Есть нюанс: пакеты на Meson собираются через ninja, а не через make, и MAKEFLAGS на них не влияет. Пакеты на CMake обычно вызывают make под капотом и параллельность подхватывают.

Во время сборки полезно смотреть на нагрузку. Открой второй терминал и запусти htop: если все ядра загружены, а память не упирается в потолок, параллельность работает как надо. Если ядра простаивают, а диск мигает, узкое место не в CPU, а в диске, и тут поможет tmpfs.

Что даёт ccache и как его подключить

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 особенно полезен

  • Пересборка AUR-пакета после обновления крупной библиотеки: большая часть кода не меняется, и кэш отдаёт готовые объектники. Сценарий разобран в статье «Обновление AUR после крупных библиотек».
  • Чистая пересборка: удалил каталог сборки, а кэш остался.
  • Сборка ядра: несколько итераций конфигурации, и каждая пересборка быстрее. Пошаговый процесс, от конфигурации до установки, описан в статье «Сборка своего ядра: 5 шагов».
  • Частые пересборки одного и того же пакета: например, ты правишь PKGBUILD или патчишь исходник, и каждый раз собираешь заново. Неизменные файлы берутся из кэша, меняются только те, что ты тронул.

Важно: ccache не ускоряет первую сборку с нуля. Он окупается на повторных проходах. И ещё: некоторые PKGBUILD отключают кэш через options=(!ccache), для таких пакетов ccache не работает.

Ещё один момент: ccache чувствителен к флагам компиляции. Изменил CFLAGS в makepkg.conf, хэш поменялся, и кэш начнёт заполняться заново. Это нормально, старые записи со временем вытеснятся.

Как собирать в tmpfs через BUILDDIR

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-хелперы собирают пакеты в памяти. Скорость растёт заметно: чтение и запись исходников перестают упираться в диск.

Минусы tmpfs

  • Исходники теряются при перезагрузке. Каталог /tmp/makepkg пустеет, следующая сборка начнётся с загрузки исходников заново. Для AUR-хелперов это не проблема: они сами скачивают и распаковывают.
  • Нужна свободная память. Сборка тяжёлого пакета может занять несколько гигабайт. Если RAM мало, tmpfs начнёт вытеснять содержимое в swap, и выигрыш пропадёт. Смотри свободную память:
free -h
  • /dev/shm по умолчанию ограничен половиной RAM. Для очень больших сборок можно смонтировать отдельный tmpfs с нужным размером, например 8 ГБ, и указать его в BUILDDIR. Такой tmpfs переживёт и сборку ядра, и сборку браузера.

Следить за заполнением tmpfs можно командой df -h /tmp. Если каталог сборки почти заполнил tmpfs, сборка упадёт с ошибкой про нехватку места. Тогда либо увеличивай размер tmpfs, либо возвращай BUILDDIR на диск.

Если памяти не хватает, верни BUILDDIR на диск или оставь tmpfs только для лёгких пакетов. Это тоже рабочий вариант.

Как сочетать ccache и tmpfs для AUR

Три приёма работают вместе. Параллельность ускоряет саму компиляцию, ccache убирает повторную работу, tmpfs убирает задержки диска. Для AUR-пакета это выглядит так: хелпер скачивает исходники, распаковывает их в /tmp/makepkg, компилирует в несколько потоков через ccache, а готовый пакет кладёт в кэш pacman.

Пример: пересобираешь пакет после обновления библиотеки. Хелпер скачивает новую версию исходников, распаковывает в /tmp/makepkg, компилятор идёт через ccache, и файлы, которые не менялись, берутся из кэша. Диск при этом вообще не участвует, только память. На машине с 16 ГБ RAM и больше такая связка работает без оговорок.

Отдельный плюс связки: кэш pacman остаётся на диске, готовые пакеты никуда не деваются. tmpfs ускоряет только промежуточную работу, а результат сборки хранится как обычно.

Проверить, что всё настроено, можно сборкой любого пакета из AUR. В логе makepkg появятся строки ccache в командах компиляции, а каталог сборки будет лежать в /tmp/makepkg.

Если сборка падает с ошибкой, полезно разбить её на шаги и смотреть, где именно ломается. Методика разобрана в статье «Divide and conquer: отладка сборки».

Частые вопросы

Не сломает ли -j$(nproc) систему?

Нет. Это стандартная настройка, которую используют почти все. Единственный риск, нехватка памяти и перегрев на слабых машинах. Заметил тормоза или высокую температуру, снизь до -j2. На машинах с 16 ГБ RAM и больше проблем обычно нет. Если сомневаешься, начни с -j4 и поднимай постепенно.

Сколько места занимает кэш ccache?

По умолчанию до 5 ГБ. Текущий размер покажет команда ccache -s. При переполнении старые записи удаляются сами, чистить вручную обычно не нужно. Если кэш лежит на SSD, можно перенести его на HDD через CCACHE_DIR.

Что делать, если /tmp не tmpfs?

Используй /dev/shm, он смонтирован как tmpfs всегда. Либо смонтируй свой tmpfs, например в /mnt/buildtmp, и укажи его в BUILDDIR. Размер задаётся опцией size при монтировании, например size=8G.

Поможет ли ccache при первой сборке?

Нет. Первая сборка заполняет кэш и идёт обычное время. Выигрыш появляется со второй сборки и дальше. Поэтому ccache имеет смысл ставить сразу, чтобы кэш копился с первых дней.

Нужно ли чистить кэш ccache вручную?

Обычно нет. ccache сам вытесняет старые записи при переполнении. Если хочешь освободить место, команда ccache -C очистит кэш полностью. После очистки следующая сборка пойдёт с нуля, так что чисти только когда место реально нужно.

Полезные ресурсы

Заключение

Три настройки в /etc/makepkg.conf дают основной выигрыш: MAKEFLAGS=”-j$(nproc)” включает все ядра, ccache убирает повторную компиляцию, а BUILDDIR=/tmp/makepkg переносит сборку в память. Начни с параллельности, это одна строка и мгновенный эффект. Потом добавь ccache, если часто пересобираешь AUR. tmpfs подключай, когда есть свободная RAM. Вместе они превращают долгие сборки в быстрые, а пересборка AUR-пакета перестаёт быть событием на полчаса и занимает минуты.



Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.

Читайте также

Комментарии

Загрузка…

Откроется GitHub: создайте новый issue с вашим комментарием (кнопка «Submit new issue»). После отправки обновите эту страницу — комментарий появится ниже.

Telegram Max