Christian Schwarz 6bc7561290 don't use MGMT_REQUEST_RUNTIME for consumption metrics synthetic size worker ...

The consumption metrics synthetic size worker does logical size calculation.
Logical size calculation currently does synchronous disk IO.
This blocks the MGMT_REQUEST_RUNTIME's executor threads, starving other futures.

While there's work on the way to move the synchronous disk IO into spawn_blocking,
the quickfix here is to use the BACKGROUND_RUNTIME instead of MGMT_REQUEST_RUNTIME.

Actually it's not just a quickfix. We simply shouldn't be blocking MGMT_REQUEST_RUNTIME
executor threads on CPU or sync disk IO.
That work isn't done yet, as many of the mgmt tasks still _do_ disk IO.
But it's not as intensive as the logical size calculations that we're fixing here.

While we're at it, fix disk-usage-based eviction in a similar way.
It wasn't the culprit here, according to prod logs, but it can theoretically be
a little CPU-intensive.

More context, including graphs from Prod:
https://neondb.slack.com/archives/C03F5SM1N02/p1687541681336949

(cherry picked from commit d6e35222ea)

2023-06-23 20:54:07 +02:00

..

benches

refactor: use LayerDesc in layer map (part 1) (#4408)

2023-06-07 18:28:18 +03:00

ctl

pagectl: refactor ctl and support dump kv in delta (#4268)

2023-05-24 19:36:07 +03:00

fixtures

walredo: simple tests and bench updates (#3045)

2023-01-16 18:24:45 +02:00

src

don't use MGMT_REQUEST_RUNTIME for consumption metrics synthetic size worker

2023-06-23 20:54:07 +02:00

Cargo.toml

feat(page_service): read timeouts (#4093)

2023-04-27 17:55:35 +00:00