Keycloak container consumes too much memory in devmode

[mabartos]

• Fixes Keycloak container consumes too much memory in devmode #41813

Overview

The unset container memory limit is the cause of the issue, for sure.

In Keycloak 24, we introduced a different behavior for memory settings as these values are mostly relative to the whole available memory of the node/machine/agent (see here).

In that case, it is required to set the container limit for Keycloak, otherwise expect a rapid increase of memory consumption (see here).

Since Keycloak 25, Argon2 is the new default password hashing algorithm, that requires more memory than the algorithm before.

Therefore, I'd propose to introduce the ability to set the container limit for Keycloak Dev service with some reasonable default value.

I would not amend the JVM options (as in #41833), as they can be changed in the future and the maintainability would be worse.

cc: @sberyozkin @gsmet @fedinskiy

---

Proposed changes

• Provide the config option for container memory limit
• Set 750MiB as the default container limit (should be sufficient for dev service like this --> see here)

Verification

I cannot find an existing test case for new config options.

Memory consumption verification based on the podman stats and created 5 realms.

OLD (limit = node memory = 32GiB):

ID            NAME        CPU %       MEM USAGE / LIMIT  MEM %       NET IO            BLOCK IO           PIDS        CPU TIME      AVG CPU %
901f13e0f8d5  kind_kilby  83.04%      888.8MB / 33.34GB  2.67%       1.78kB / 22.19kB  92.58MB / 4.334MB  120         2m53.976208s  179.75%

NEW (limit = 750MiB):

ID            NAME             CPU %       MEM USAGE / LIMIT  MEM %       NET IO            BLOCK IO           PIDS        CPU TIME      AVG CPU %
185b7a567958  exciting_cannon  0.52%       611.7MB / 786.4MB  77.78%      1.64kB / 21.45kB  82.44MB / 3.654MB  118         1m45.389621s  161.24%

The OLD memory can grow until the container limit, so it should be limited.

@fedinskiy Could you please test this solution in your deployment? Same as you mentioned in the issue description? Thanks!

[sberyozkin]

Thanks for the analysis and the proposed fix, @mabartos.

I'll run it on my laptop a little bit later as well, in addition to @fedinskiy testing it in the constrained memory setup

[gsmet]

750 MB looks like a lot to me for a Dev Service that will probably have very few users stored in it but if that's what is needed, I suppose it will have to do.

[github-actions]

🎊 PR Preview 351b9f9 has been successfully built and deployed to https://quarkus-pr-main-43601-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 4c49feb.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 4c49feb.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[mabartos]

@sberyozkin Thanks for the review! :)

750 MB looks like a lot to me for a Dev Service that will probably have very few users stored in it but if that's what is needed, I suppose it will have to do.

@gsmet We've touched on the discussion several times, mainly here: keycloak/keycloak#26661, keycloak/keycloak#27079

IMHO, for the dev service, the value is reasonable - not lowering it down.

[fedinskiy]

@mabartos this worked on the 8GB RAM machine (where the 999-SNAPSHOT failed) so this patch helped.

[michalvavrik]

@gsmet if you don't plan to carry on discussion and there won't be requests for new reviews, please merge this as I need to adapt my PR #43609 on this before I update it. Thanks

[fedinskiy]

@gsmet is it possible to have this backported to 3.15, or even better to 3.15 and 3.8?

[sberyozkin]

Just for the record, on my laptop the start time is probably the same as it was without this feature, about 15 secs, so no negative impact

[sberyozkin]

@mabartos Thanks for the fix, if it can be of interest, please have a look at some point if we can somehow have Keycloak Devservice starting faster, in the early days, Devservice was starting in about 11 secs or so as far as I recall, on my older laptop, now it is 15 secs or so on a newer laptop. I recall we discussed with Pedro an idea of shipping a custom image but we can't really do it. Please experiment if you can get some time, with some optional JVM options etc

[mabartos]

@mabartos Thanks for the fix, if it can be of interest, please have a look at some point if we can somehow have Keycloak Devservice starting faster, in the early days, Devservice was starting in about 11 secs or so as far as I recall, on my older laptop, now it is 15 secs or so on a newer laptop. I recall we discussed with Pedro an idea of shipping a custom image but we can't really do it. Please experiment if you can get some time, with some optional JVM options etc

@sberyozkin Yes, a custom image would be a way to avoid augmentation. However, I'm aware that we did not have so much time to concentrate on the performance in terms of startup times and memory consumption lately due to other priorities. I'd like to have a look at it for the next releases.

[sberyozkin]

Proposing a backport to 3.15.x which uses Keycloak 25.x