<p>We've been looking at memory for capacity planning and have a Helm-deployed 8GB-limited QuestDB instance running on one of our k8s clusters.</p>
<p>We recently began scraping metrics off of it. I'm trying to get to the bottom of the <code>questdb_memory_mem_used</code> metric, which occasionally sees excursions way beyond the resource limits.</p>
<p><a href="https://i.stack.imgur.com/mL1dn.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/mL1dn.png" alt="Chart displaying Memory Used, with peaks of up to almost 25Gb" /></a></p>
<p>Does anyone have a good handle on what contributes to this metric and what we could be seeing?</p>
<p>For reference the <code>NATIVE_*</code> tagged metrics seem much more sane in the same time period:</p>
<p><a href="https://i.stack.imgur.com/fWyEQ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/fWyEQ.png" alt="List of several QuestDB monitoring metrics, including FAST_MAP at 789MB and FAST_MAP_LONG_LIST at 6.31GB" /></a></p>

Javier Ramirez
<p>According to the <a href="https://questdb.io/docs/third-party-tools/prometheus/" rel="nofollow noreferrer">documented Prometheus metrics</a> exposed by QuestDB, <code>questdb_memory_mem_used</code> includes all native memory allocations which may include virtual memory if it wasn't touched yet.</p>
<p>This metric includes mmapped files, so that's why its value is that big. You might see that metric grow when you access large tables on your instance. <code>DISTINCT</code> and <code>JOIN</code> queries will also affect this metric.</p>
<p>Please note mmapped memory is elastic and mostly virtual. Only free memory is used for the page cache, so it's fine if this metric has a large value.</p>
