github-actions[bot] commented on code in PR #63916:
URL: https://github.com/apache/doris/pull/63916#discussion_r3332233840
##########
fe/fe-core/src/main/java/org/apache/doris/monitor/jvm/JvmInfo.java:
##########
@@ -80,6 +82,24 @@ public class JvmInfo {
}
String[] inputArguments = runtimeMXBean.getInputArguments()
.toArray(new String[runtimeMXBean.getInputArguments().size()]);
+
+ if (directMemoryMax == 0) {
+ for (String arg : inputArguments) {
+ if (arg.startsWith("-XX:MaxDirectMemorySize=")) {
+ try {
+ directMemoryMax =
ByteSizeValue.simpleParseBytesSizeValue(
+
arg.substring("-XX:MaxDirectMemorySize=".length()),
+ "MaxDirectMemorySize");
Review Comment:
This still leaves `directMemoryMax` as `0` in the default FE Java 17
configuration. `conf/fe.conf`/`bin/start_fe.sh` do not set
`-XX:MaxDirectMemorySize` or open `java.base/jdk.internal.misc`, so
`sun.misc.VM` is unavailable, `jdk.internal.misc.VM.maxDirectMemory()` cannot
be made accessible, and this new fallback finds no input argument. The newly
added `jvm_buffer_pool_max_bytes{name="direct"}` metric then reports `0` even
though HotSpot's unset `MaxDirectMemorySize` limit defaults to the max heap
size. That makes the new metric misleading for normal deployments and breaks
direct-memory pressure alerting based on `used / max`. Please resolve the
default case, for example by falling back to the VM's effective default instead
of publishing zero, or by not emitting the max metric when the limit is
genuinely unknown.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
