[
https://issues.apache.org/jira/browse/SOLR-17689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932317#comment-17932317
]
Jan Høydahl commented on SOLR-17689:
------------------------------------
Hi. Seems you have configured a non-standard heap setting for Solr, without the
{{-Xms}} option. This is not a recommended production setting, since it may
cause memory fragmentation and pauses during scale up/down. It is highly
recommended to set {{-Xms}} equal to {{-Xmx}} as documented in
[https://solr.apache.org/guide/solr/latest/deployment-guide/jvm-settings.html#choosing-memory-heap-settings]
By default you will see that both are set, and if you tune with {{SOLR_HEAP}}
variable, both are also set to same value.
So in my opinion, we the UI works as it should for both the default and
recommended heap settings, and we should not encourage use of dynamic heap
resizing.
The reason for the behavior is likely that the UI pulls current heap size from
a metric value (which in your case is dynamic) and not from xmx.
I'll not object to a fix that always uses Xmx, but I'll not pursue this myself.
If you want to contribute a Pull Request I can help review.
> Admin UI: Cloud -> Nodes -> Heap works only with fixed heap size
> ----------------------------------------------------------------
>
> Key: SOLR-17689
> URL: https://issues.apache.org/jira/browse/SOLR-17689
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
> Affects Versions: 9.8
> Reporter: Bernd Wahlen
> Priority: Minor
>
> when using fixed heap size e.g.
> -Xms2g
> -Xmx2g
> -XX:+UseZGC
> this metics show useful value (heap percentage).
> Without such configuration
> -Xmx512m
> -XX:+UseZGC
> it shows dangerous (red) e.g. 96%
> Dashboard shows the correct value: 98/102M, 19.9% JVM-Memory of 512M,
> because JVM releases the unusued memory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
