reduce reserved memory and/or having reserved memory a more reasonable upper bound

[lmatz]

https://risingwave-labs.slack.com/archives/C03L8DNMDDW/p1709280838845109

We right now reserved 30% of total memory because we once observed in #13648 that the difference between actual usage (jemalloc_allocated) and process usage (process_resident_memory) is somehow pretty large, ~30%.

but later we also observed that https://risingwave-labs.slack.com/archives/C03L8DNMDDW/p1709284323589129?thread_ts=1709280838.845109&cid=C03L8DNMDDW the difference is not that big.

[lmatz]

We recently encountered users who allocate 150GB+ memory.

The reserved memory would be quite large, 45GB+ memory, and wasteful if the true difference is not that big

[fuyufjh]

How about introduce an option (env var) for setting the memory for memory management?

[lmatz]

Repost from Slack for better visibility https://risingwave-labs.slack.com/archives/C03Q34JHLLC/p1713339502326229:

I think now we have the opportunity to increase the amount of memory that users can use because

1. memtable spilling is done and re-activated
2. The new sequence-based memory eviction mechanism looks very promising as demonstrated by queries in Nexmark/TPCH. perf(memory): use thread-local sequence-based memory eviction policy #16087

I think after introducing the option of configuring both memory control policy (which are already supported in) and the amount of reserved memory,
we can:

1. try several aggressive configs in longevity/performance tests first to check the stability for a period of time.
2. set an aggressive as default in the following new releases

As we observe there are indeterministic (sometimes large sometimes small close to 0) gaps between the Jemalloc estimation and RSS in #13648 and https://risingwave-labs.slack.com/archives/C03L8DNMDDW/p1709284323589129?thread_ts=1709280838.845109&cid=C03L8DNMDDW.

I was wondering if we could replace Jemalloc memory estimation with RSS to guide the memory control policy.

From @fuyufjh:

Jemalloc does not necessarily return the memory to OS immediately after a piece of memory becomes unused in the program. This piece of memory may still be in the memory page pool of Jemalloc. Here we need the released memory must be reflected in statistics.

Later, we discovered that there are two variables in Jemalloc to control the timing of returning the memory page to OS:
https://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms

By setting both opt.dirty_decay_ms and opt.muzzy_decay_ms to 0, Jemalloc would return the memory page immediately.

But whether they really work as expected needs to be tested:

1. whether it really returned the page immediately
2. whether it affects the performance a lot

[lmatz]

As #16992 brought this issue again, I took a look at tikv_jemalloc, and it seems that right now we cannot

set opt.dirty_decay_ms and opt.muzzy_decay_ms to 0,

as https://github.com/tikv/jemallocator/blob/main/jemalloc-ctl/src/opt.rs does not expose these two variables
Not sure if we have to fork one

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄