CAS 7.0 memory usage increases with the number of services URLs

[Pascal Rigaux]

Hi,

Since upgrading from 6.6 to 7.0, we had some memory leak like behavior: +500M used memory per week.

After investigation, it only occurs when you have many many different CAS "service" urls (query params are taken into account)
For example https://userphoto.univ.fr/?uid=xxx&v=<random-number>

The culprit is: https://github.com/apereo/cas/blob/master/core/cas-server-core-webflow/src/main/java/org/apereo/cas/config/CasWebflowMonitoringConfiguration.java

A workaround is "management.tracing.enabled=false"

Refs:
- https://apereo.github.io/cas/7.0.x/monitoring/Configuring-Tracing.html
- Micrometer Metrics with high cardinality tags resulting in OOM issue : https://github.com/micrometer-metrics/micrometer/issues/3038


Détails:

for each new 1000 services, it creates the following objects:

+0.0M +1000 io.micrometer.core.instrument.cumulative.CumulativeTimer
+0.0M +1000 io.micrometer.core.instrument.distribution.DistributionStatisticConfig
+0.0M +1000 io.micrometer.core.instrument.distribution.TimeWindowMax
+0.0M +1000 io.micrometer.core.instrument.internal.DefaultLongTaskTimer
+0.0M +1000 java.util.concurrent.ConcurrentLinkedDeque (java...@21.0.5)
+0.0M +1000 [Ljava.util.concurrent.atomic.AtomicLong; (java...@21.0.5)
...
+0.0M +2000 io.micrometer.core.instrument.Tags
+0.0M +2000 java.lang.Double (java...@21.0.5)
+0.1M +2000 [Lio.micrometer.core.instrument.Tag;
+0.1M +2022 java.util.concurrent.ConcurrentHashMap (java...@21.0.5)
+0.0M +2078 java.util.concurrent.ConcurrentLinkedDeque$Node (java...@21.0.5)
+0.1M +3129 java.util.concurrent.ConcurrentHashMap$Node (java...@21.0.5)
+0.2M +4000 io.micrometer.core.instrument.Meter$Id
+0.1M +5000 io.micrometer.core.instrument.ImmutableTag
+0.1M +5000 java.util.concurrent.atomic.AtomicLong (java...@21.0.5)
+0.1M +6187 java.lang.String (java...@21.0.5)
+2.3M +6234 [B (java...@21.0.5)

with ImmutableTag having the following key-value fields: "error"-"none", "flowId"-"login", "url"-"https://..."

(obtained with "jmap -histo" and heap dump + visualvm)


cu