Tom Ridge

One possible cause might be: temporary files (of the order of 5GB or so) are kept around longer than they are needed. Temporary files should be deleted if not needed,...

The previous version of the code had a space overhead of 25 to 30GB. So the current version seems to have an extra 10GB of overhead. However, blocks may be...

A suggestion (from samoht): It may be that the LRU change interacts badly with snapshot import (or even export): e.g. the snapshot code may rely on the dedup provided by...

I think @icristescu interacted with them. I don't think I saw anything further on the slack channels I'm signed up to. I guess if it is a problem they will...

After checking the latest tezos issues, this may be related: https://gitlab.com/tezos/tezos/-/issues/3249 There is an initial report by @vishakh on tezos slack #general on Jun 2. This does not include the...

Just a quick comment: the Kind.of_magic error fails because it reads a "0" byte, and this does not correspond to any of the object tags we use. One way this...

Some initial candidates for increase in max memory usage 1. Size of the sparse map file, which is held in memory (these benchmarks likely use gap_tolerance=0) 2. (? not sure...

A comparison using tree.exe benchmark, comparing main to 3.3.1, shows minor memory usage difference: ``` | | main | 331 | -- | -- | -- | -- main metrics...

The size of the mapping file, at least with this particular test run on main, is only 1.7MB; so this is not a source of significant memory usage.

The following gives the machine setups for the benchmarks from #1959. good-gc runs were using ocaml 4.12.1 whereas the others used 4.14. Also gc.space_overhead for good-gc was 80, whereas it...