Why is 4GB of heap required?

[rbi]

Question

Why does Dependency Track need 4GB of heap memory as a minimum requirement? What does it do with all that memory?

Background

I just stumbled across Dependency Track for the fist time. It looked good on the screenshots so I thought I quickly start it up via the default docker compose file. There are insane memory limits of min 8GB and max 12GB pre-configured. As I just wanted to take a quick look I lowered the max memory limit to 512 MB which is still really much memory. It fails to start with.

Dependency-Track requires a minimum of 4GB RAM (heap). Cannot continue. To fix, specify -Xmx4G (or higher) when executing Java.

Now I wonder how these high memory requirements are justified. Isn't Dependency Track at its core a UI for managing a dependency database?

[black-snow]

We run it with three gigs and SYSTEM_REQUIREMENT_CHECK_ENABLED: "false". It struggled with two gigs or less.

It's not just an UI (well, the UI is). DT analyzes your SBOMs, extracts components, licenses, evaluates your policies, sends alerts, updates vulnerability DBs, ...
We, too, were a bit shocked by the minimum requirements, though.

[nscuro]

Now I wonder how these high memory requirements are justified.

The reason for the defaults in the docker-compose.yml, and the requirements check on startup, was to prevent users from running into issues due to under-resourced machines. To my understanding, this has been an issue in the past.

As for the reason of the high memory requirement, that is mostly due to an unfortunate default of the ORM that Dependency-Track is using. The ORM, similar to other ORMs in the field, has an L1 and L2 cache to reduce database roundtrips. In the majority of ORMs, the L2 cache is disabled by default. In this one, it's enabled.

I wrote a bit more about it here: stevespringett/Alpine#493, and as of today, you can choose to disable the L2 cache altogether by passing the ALPINE_DATANUCLEUS_CACHE_LEVEL2_TYPE=none environment variable. The reason it's not yet disabled by default is that it's hard to determine the impact of it for the various workloads users are running. If an application was built with caching always enabled, it's hard to spot which areas cause performance degradation when caching is disabled.

If you're monitoring your DT instance, you should see a drastic reduction in PS Old Gen size in the heap usage metric after disabling L2 caching. PS Old Gen holds objects that survived multiple GC runs (which is desired behavior for caches, but bad for memory usage).

That said, in many refactorings and new features I worked on in the recent past, I explicitly disable the L2 cache for the areas I am working on. The most recent area being the import of BOMs, which is quite central to what DT does. I'm also profiling said areas and try to reduce unnecessary memory allocations as much as possible. So feel assured that we're working on addressing the excessive resource requirement step by step.

v5.x of Dependency-Track, which we are already working on, has L2 caching disabled per default.

As I just wanted to take a quick look I lowered the max memory limit to 512 MB which is still really much memory.

512MB will always be a stretch for applications like Dependency-Track, which do a lot of things as @black-snow pointed out. For very small workloads with only a few projects it might be fine, for anything more, you'll need larger heaps.

[rbi]

Thanks for these insights.