App container uses 2.45 GiB against a 1 GB heap — expected?
Self-hosted v1.2026.006, docker-compose, one small VPS. Not a crash — a resource question, but the numbers surprised me enough that it might be a real finding.
The instance is tiny: 1 site, 212 topics, 742 posts, 19 users, a 26 MB Postgres database and a 1.7 MB search index. Eight days uptime. PLAY_HEAP_MEMORY_MB is 1024 in docker-compose.override.yml, set the way "How to add more Talkyard server RAM" describes, and the process really is running -Xms1024m -Xmx1024m. docker stats:
app (Play / JVM) 2.45 GiB PLAY_HEAP_MEMORY_MB=1024
search (ElasticSearch) 1.12 GiB -Xms512m -Xmx512m, limit 1.6G
rdb (PostgreSQL) 115 MiB
web (nginx) 33 MiB
egressp 11 MiB
cache (Redis) 11 MiB
rendr 0.6 MiB
---------
~3.7 GiB
The app container is what I'd like to understand: the configured heap is 1 GB, the container sits at 2.45 GiB, and it isn't page cache —
VmRSS 2596616 kB
RssAnon 2562844 kB
RssFile 33772 kB
— so roughly 1.4 GB of anonymous, non-heap allocation. More than the heap itself. Metaspace, code cache, thread stacks, direct buffers, malloc arenas, whatever server-side rendering takes natively, presumably.
Two questions:
- Is 2.5x the configured heap the expected shape for this container, or does that look wrong? I ask partly because the hosting guidance here is 2 GB minimum and 4 GB recommended, and on these numbers the app server alone eats most of a 2 GB box before ElasticSearch starts.
- If some of it is reclaimable with flags —
MALLOC_ARENA_MAX,-XX:MaxMetaspaceSize, a smaller thread pool — would you consider defaulting them for small installs? That would help every self-hoster on the current build, with no porting work.
I have the box and the forum is small enough to restart freely, so I'm glad to run any flag combination you want measured and post the numbers here.
(The ElasticSearch line in that table I've taken to -247, where it fits the existing discussion.)
This post crafted with assistance from Claude AI
Linked from: