diff options
| author | Harmen Stoppels <harmenstoppels@gmail.com> | 2023-02-17 08:42:41 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-02-17 08:42:41 +0100 |
| commit | 476a29e1b6ab576782fad83ae901aea84fb52d66 (patch) | |
| tree | 47399ba77d989c04403a0aece1625bc7571cf8ee /etc | |
| parent | 603569e321013a1a63a637813c94c2834d0a0023 (diff) | |
| download | spack-476a29e1b6ab576782fad83ae901aea84fb52d66.tar.gz spack-476a29e1b6ab576782fad83ae901aea84fb52d66.tar.bz2 spack-476a29e1b6ab576782fad83ae901aea84fb52d66.tar.xz spack-476a29e1b6ab576782fad83ae901aea84fb52d66.zip | |
Increase db timeout 3s -> 60s (#35517)
When running many concurrent spack install processes that need to write
to the db, Spack regularly times out. This is because writing to the DB
after another process has written to it requires deserialization of the
db, mutating it in memory, and serializing it again, which takes some
time. On top of that, I believe there's a 1 second retry when a write
lock cannot be obtained, so I think this means only 3 processes can
really write to the DB at the same time before timing out.
Diffstat (limited to 'etc')
| -rw-r--r-- | etc/spack/defaults/config.yaml | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/etc/spack/defaults/config.yaml b/etc/spack/defaults/config.yaml index 535187a739..06d6a10909 100644 --- a/etc/spack/defaults/config.yaml +++ b/etc/spack/defaults/config.yaml @@ -181,7 +181,7 @@ config: # when Spack needs to manage its own package metadata and all operations are # expected to complete within the default time limit. The timeout should # therefore generally be left untouched. - db_lock_timeout: 3 + db_lock_timeout: 60 # How long to wait when attempting to modify a package (e.g. to install it). |