liam-baker-sm

Hello, I can reproduce unusually high memory usage under very specific configuration. - GRPC connection between the bazel build and the bazel-remote server. - Compressed transfer ( `--experimental_remote_cache_compression` ) -...

Turning off compression `--experimental_remote_cache_compression` only and running with `--remote_download_toplevel` the server memory use peaks at 5.1GB. I suspect, based on the bazel output, this is the result of "queing up"...

Bazel remote version is 2.4.3 on all servers.

@mostynb The bazel-remote I ran the test against is using uncompressed storage, due to https://github.com/buchgr/bazel-remote/issues/524 The instance points to another bazel-remote using `--http_proxy.url`

Currently we have many bazel 7.0.0 `remote_download_toplevel` builds each day using a bazel-remote cache without problem. `IOException: Connection reset` would suggest the connection was dropped. Do you use HTTP(S) or...

Frequently run builds where `ld` can take over 6GB of ram. At the moment the only work around is to set `--jobs` or allocate less CPU's to the build machines....

Usually it works because Windows will create a NAT for your WSL2, and route through the VPN in Windows (i.e. it comes out of the WSL2 NAT, hits the Windows...

Thanks for that information, mirrored mode looks interesting. Our current fix is to set a registry key to move the NAT to `192.168.240.0/20` This keeps WSL addresses away from our...