]> git.ipfire.org Git - thirdparty/ccache.git/commit
feat: Improve automatic cache cleanup mechanism
authorJoel Rosdahl <joel@rosdahl.net>
Thu, 5 Jan 2023 18:14:27 +0000 (19:14 +0100)
committerJoel Rosdahl <joel@rosdahl.net>
Tue, 17 Jan 2023 19:25:06 +0000 (20:25 +0100)
commitdefb83cc6641b7356c1426c0ba782ac735748917
tree6a57138d0769ce69d4a7afd899f0a324ad159ce7
parentb7eed47f937155a6c0b62d26739e1b65c4edc1f2
feat: Improve automatic cache cleanup mechanism

The cache cleanup mechanism has worked essentially the same ever since
ccache was initially created in 2002:

- The total number and size of all files in one of the 16 subdirectories
  (AKA level 1) are kept in the stats file in said subdirectory.
- On a cache miss, the new compilation result file is written (based on
  the first digits of the hash) to a subdirectory of one of those 16
  subdirectories, and the stats file is updated accordingly.
- Automatic cleanup is triggered if the size of the level 1 subdirectory
  becomes larger than max_size / 16.
- ccache then lists all files in the subdirectory recursively, stats
  them to check their size and mtime, sorts the file list on mtime and
  deletes the 20% oldest files.

Some problems with the approach described above:

- (A) If several concurrent ccache invocations result in a cache miss
  and write their results to the same subdirectory then all of them will
  start cleaning up the same subdirectory simultaneously, doing
  unnecessary work.
- (B) The ccache invocation that resulted in a cache miss will perform
  cleanup and then exit, which means that an arbitrary ccache process
  that happens to trigger cleanup will take a long time to finish.
- (C) Listing all files in a subdirectory of a large cache can be quite
  slow.
- (D) stat-ing all files in a subdirectory of a large cache can be quite
  slow.
- (E) Deleting many files can be quite slow.
- (F) Since a cleanup by default removes 20% of the files in a
  subdirectory, the actual cache size will (once the cache limit is
  reached) on average hover around 90% of the configured maximum size,
  which can be confusing.

This commit solves or improves on all of the listed problems:

- Before starting automatic cleanup, a global "auto cleanup" lock is
  acquired (non-blocking) so that at most one process is performing
  cleanup at a time. This solves the potential "cache cleanup stampede"
  described in (A).
- Automatic cleanup is now performed in just one of the 256 level 2
  directories. This means that a single cleanup on average will be 16
  times faster than before. This improves on (B), (C), (D) and (E) since
  the cleanup made by a single compilation will not have to access a
  large part of the cache. On the other hand, cleanups will be triggered
  16 times more often, but the cleanup duty will be more evenly spread
  out during a build.
- The total cache size is calculated and compared with the configured
  maximum size before starting automatic cleanup. This, in combination
  with performing cleanup on level 2, means that the actual cache size
  will stay very close to the maximum size instead of about 90%. This
  solves (F).

The limit_multiple configuration option has been removed since it is no
longer used.

Closes #417.
18 files changed:
doc/MANUAL.adoc
src/.clang-tidy
src/Config.cpp
src/Config.hpp
src/core/Statistic.hpp
src/core/Statistics.cpp
src/storage/local/LocalStorage.cpp
src/storage/local/LocalStorage.hpp
src/storage/local/util.cpp
src/storage/local/util.hpp
src/test_lockfile.cpp
src/util/LockFile.hpp
src/util/LongLivedLockFileManager.cpp
src/util/LongLivedLockFileManager.hpp
test/suites/cleanup.bash
unittest/test_Config.cpp
unittest/test_storage_local_util.cpp
unittest/test_util_LockFile.cpp