[BUG] Win light version - high memory consumption (over 5 GB)

[000al000]

Component

Lite

Performance Monitor Version

2.4.1

SQL Server Version

2016 + 2025

Windows Version

Windows 11

Describe the Bug

Lite version, 4 databases run over a week.
When running consumpion over 5Gb RAM
Database size of collected data 4-6 Mb

Steps to Reproduce

Start Dashboard

Eat RAM to 5 -6 Gb

Expected Behavior

Low memory consumption

Actual Behavior

Error Messages / Log Output

Screenshots

No response

Additional Context

No response

[erikdarlingdata]

Thanks for the report. 5 GB for 4 databases over a week is definitely not expected.

We've identified a couple of potential causes we'll be investigating:

• An unbounded in-memory cache in the delta calculator that grows with every collection cycle and never evicts old entries
• Event handler subscriptions that aren't cleaned up when server tabs are closed

To help us narrow it down, could you share a few details?

1. Task Manager memory - is the memory usage growing steadily over time, or does it spike and stay high?
2. Tab usage - are you leaving 4 server tabs open the whole time, or frequently opening/closing them?
3. Collection interval - are you using the default collection interval or a custom one?
4. Which process - in Task Manager, is it PerformanceMonitor.Lite.exe using the memory, or something else?

If you're comfortable with it, you can also check the DuckDB database size at %LOCALAPPDATA%\PerformanceMonitor\Lite\ to confirm it's small (as you noted, 4-6 MB), which would confirm the leak is in-process memory, not on disk.

[000al000]

I removed all bases from config, but memory consumption still persist

1. Memory usage started from starting of program and spike to 7 Gb, low to 1Gb, and after couple of second rise to 7 Gb
2. No tabs, remove all servers
3. Default
4. yes, PerformanceMonitor.Lite.exe

P.S. after 5 minutes memory low to 70 Mb, and no spikes

[000al000]

DuckDb - 50 Mb

[erikdarlingdata]

Thanks for the details — that narrows it down significantly.

The spike-then-settle pattern (7 GB → 70 MB after 5 minutes) with no servers configured points to a startup data operation, not a leak. The most likely cause is the Parquet archive compaction step, which uses an in-memory DuckDB connection to merge archived files. With a 50 MB database and accumulated archives, this can temporarily buffer several GB.

Could you check how many archived Parquet files you have and their total size?

dir /s "%LOCALAPPDATA%\PerformanceMonitor\Lite\archive"

That will tell us if compaction is the culprit. If you have dozens or hundreds of .parquet files, that's our answer.

We've already shipped fixes for the long-running memory growth in #760 (event handler leaks and unbounded delta cache). The startup spike is a separate issue we're tracking.

[000al000]

archive folder ~800 Mb

Biggest - 202603_query_store_stats, about 230 Mb

[000al000]

I added 4 servers again, and got spikes when running from 1Gb to 5 Gb. Waiting for release with fix with memory growth

[erikdarlingdata]

Thanks for the archive directory info — that confirmed the issue.

Root cause: The parquet archive compaction step uses an in-memory DuckDB connection whose default memory limit is 80% of physical RAM. Your 800 MB of compressed parquet archives (especially the 230 MB query_store_stats file) decompress to several GB in memory during the merge operation, causing the spike you saw.

Fixes shipped (in dev, will be in next release):

1. Compaction memory cap (Cap DuckDB compaction memory at 2 GB (#758) #762) — The in-memory DuckDB connection used for compaction is now limited to 2 GB. DuckDB automatically spills to disk when this limit is hit, so compaction still works correctly but won't consume all your RAM.

2. Long-running memory leaks (Fix Lite memory leaks: delta cache, event handlers, chart helpers (#758) #760) — Event handler subscriptions, chart hover helpers, and an unbounded delta calculator cache were not being cleaned up when server tabs were closed. All three are now properly disposed on tab close.

These changes should address both the startup spike and any gradual memory growth over extended use. Let us know if you still see high memory usage after the next release.

[erikdarlingdata]

Fixed in v2.5.0 — memory leaks in delta cache, event handlers, and chart helpers (#760), plus DuckDB compaction memory capped at 2 GB (#762).