Коэффициент попадания в кэш 0,00% в GitHub Actions CI

В нашем проекте C ++ нам удалось настроить GitHub Actions, создавая наши источники с помощью ccache.

Он очень хорошо работает в Linux, где благодаря ccache сборка выполняется менее чем за 5 минут.

К сожалению, при сборке на macOS ccache, похоже, не работает, что дает:

cache directory                     /Users/runner/.ccache
primary config                      /Users/runner/.ccache/ccache.conf
secondary config      (readonly)    /usr/local/Cellar/ccache/3.7.11_1/etc/ccache.conf
stats updated                       Sun Aug 23 11:57:31 2020
cache hit (direct)                     0
cache hit (preprocessed)               0
cache miss                          7175
cache hit rate                      0.00 %
cache file missing                     1
cleanups performed                  2976
files in cache                       165
cache size                         422.4 MB
max cache size                     500.0 MB

Проблема с кешем AzerothCore в macOS

Следовательно, сборка macOS занимает около 40 минут.

Поэтому, несмотря на то, что я пытался настроить macOS сборку так же, как ubuntu-*, мне не удалось заставить ccache правильно работать, и я не могу понять, почему.

Как заставить ccache работать и с macOS?


person Francesco Borzi    schedule 23.08.2020    source источник
comment
Начните с регистрации того, какая опция компилятора использовалась при построении кода. ccache откажется кэшировать сборку, если увидит параметр компилятора, который, по его мнению, означает, что сборку нельзя кэшировать.   -  person Sam Varshavchik    schedule 23.08.2020
comment
Вы используете GitHub sha на ключе. Этот sha будет меняться при каждом коммите, который вы делаете, поэтому он всегда будет пропущен, когда вы попытаетесь получить попадание в кеш, которое включает хеш коммита.   -  person Edward Romero    schedule 29.08.2020
comment
Думаю, у @EdwardRomero есть настоящий ответ. Пожалуйста, опубликуйте это как таковое. Также, Github, опубликуйте рецепт для этого распространенного варианта использования. Даже что-то ужасно простое, например, совместное использование одного ccache для всех веток репозитория, вероятно, подойдет для многих проектов и сэкономит GH Actions много циклов.   -  person Brian Cain    schedule 04.05.2021


Ответы (1)


Проблема, скорее всего, в том, что максимальный размер кеша слишком мал. Если результаты (в основном объектные файлы) сборки не соответствуют максимальному размеру кеша, то для следующей сборки не останется никаких полезных результатов, и вы получите только промахи кеша.

выполненных очисток было 2976 до сборки и 3353 после сборки, поэтому 377 автоматическая очистка. Поскольку максимальный размер кеша составлял 500 МБ, каждая очистка удаляла около 500 * (1–0,8) / 16 МБ = 6,25 МБ, и все очистки вместе, таким образом, удаляли около 377 * 6,25 МБ ≈ 2356 МБ данных. Это должно быть примерно равно размеру результатов одной сборки. (0,8 - это limit_multiple по умолчанию, а 16 - количество подкаталогов в кеше.)

Попробуйте существенно увеличить лимит размера кеша. Исходя из приведенных выше расчетов, хороший размер кеш-памяти должен составлять не менее 5 ГБ. Вы также можете или в качестве альтернативы включить сжатие (CCACHE_COMPRESS=1), чтобы в кеше поместилось больше результатов.

person Joel Rosdahl    schedule 30.08.2020