dependency-track is taking 25% of CPU with no projects

[somera]

Current Behavior

I run dependecy-tack for the first time.

docker run -d \
    --network=host \
    -m 8192m -p 7070:8080 \
    --name dependency-track \
    -v /data-files/data/docker/dependency-track:/data \
    dependencytrack/bundled

The initial process was successful. After 2-3 hours I didn't see any changes in the log. But dependecy-tack is using 25% of CPU usage on my NUC. There are no projects and nothing special is configured. Why so much CPU usage?

At 14:17 I restarted dependency-track.

Without dependency-track the CPU usage is ~2-3%.

Steps to Reproduce

Just start the Docker Container.

Expected Behavior

Less CPU usage when no projects was added.

Dependency-Track Version

4.9.1

Dependency-Track Distribution

Container Image

Database Server

H2

Database Server Version

No response

Browser

Google Chrome

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this defect was already reported

[nscuro]

Indeed DT should not use as much CPU when idle. I just launched an empty 4.9.1 instance on my workstation, attached VisualVM, and will let it run like this for a few hours. I suspect that H2's internal maintenance plays a factor here, but we'll see.

[somera]

I startet my setup on other NUC and will take a look on this.

[nscuro]

Yeah so even after letting it run for ~15min, I can already tell it's the H2 database's maintenance thread that keeps working. Notice the Total Time (CPU) numbers:

With docker stats I'm seeing similar numbers to what you are reporting:

CONTAINER ID   NAME                           CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O       PIDS
47831309e8a6   dependency-track-apiserver-1   35.13%    3.399GiB / 11.67GiB   29.14%    23.9MB / 880MB   48MB / 30.4GB   76

And at this point in time, DT itself ran idle.

Generally, H2 is good for initial testing, but for everything beyond that you should use a dedicated DB server (preferably PostgreSQL). They are much more efficient and get the job done with fewer resources.

[somera]

Thx for the input. Than I will use my PostgreSQL 16 instance for DT.

If you think there is nothing to do, than this can be closed.

[nscuro]

I have launched a PostgreSQL setup with the same monitoring connected to it. Just want to really confirm that the CPU usage indeed settles in that case. I'll close this issue once that is confirmed.

[nscuro]

CPU is still around ~10%, but I can't see any threads anymore that do actual work on the CPU.

Please feel free to re-open in case you're still getting unusual resource usage with PostgreSQL.

[somera]

Only short question.

I have working PostgreSQL 16 with

password_encryption = scram-sha-256

Is DT support this?

[nscuro]

AFAIK there's no special treatment needed on the client side to work with a DB configured with password_encryption = scram-sha-256. Just provide your database credentials as usual and it should just work.

[somera]

It works. All I had to do was add a suitable line in pg_hba.conf.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.