根据cassandra-env.sh，440g总ram的默认堆内存分配应该是32765m（jvm切换到64位引用之前的最大上限）。那么，当我查询“java-xx:+printcommandlineflags-version”或“java-xx:+printflagsfinal-version”时，为什么显示32210157568字节（30718m）为什么会有2克左右的差异呢。仅供参考：jvm.options文件是默认的&使用dse5.1.3。
zour9fqk1#
java -XX:+PrintFlagsFinal 与Cassandra无关，我不知道你为什么要提到 cassandra-env.sh . 不管怎样，让我来回答问题的主要部分。在jdk 8中，当 -Xmx 则最大堆大小估计为
java -XX:+PrintFlagsFinal
cassandra-env.sh
-Xmx
MaxHeapSize = min(1/4 RAM, max_heap_for_compressed_oops)
在您的例子中，服务器有充足的ram，因此默认堆大小受到基于零的压缩oop支持的最大可能大小的限制，即32gb。堆显然不能从零地址开始（空页由操作系统保留），并且默认的堆对齐是2MB，所以我们必须减去至少2MB。然后，jdk倾向于在 HeapBaseMinAddress ，在linux上等于2GB。这为进程的本机堆的增长提供了一些空间。因此，jvm将默认的最大堆大小减少了 HeapBaseMinAddress .这就是为什么最终计算的堆大小等于
HeapBaseMinAddress
32 GB - 2 MB - 2 GB = 32210157568
如果您放弃对基于零的压缩oop的要求，那么可以设置 -XX:HeapBaseMinAddress=0 . 在这种情况下，计算出的堆大小为
-XX:HeapBaseMinAddress=0
32 GB - 2MB = 32766 MB
1条答案
按热度按时间zour9fqk1#
java -XX:+PrintFlagsFinal与Cassandra无关，我不知道你为什么要提到cassandra-env.sh. 不管怎样，让我来回答问题的主要部分。在jdk 8中，当
-Xmx则最大堆大小估计为在您的例子中，服务器有充足的ram，因此默认堆大小受到基于零的压缩oop支持的最大可能大小的限制，即32gb。
堆显然不能从零地址开始（空页由操作系统保留），并且默认的堆对齐是2MB，所以我们必须减去至少2MB。
然后，jdk倾向于在
HeapBaseMinAddress，在linux上等于2GB。这为进程的本机堆的增长提供了一些空间。因此，jvm将默认的最大堆大小减少了HeapBaseMinAddress.这就是为什么最终计算的堆大小等于
如果您放弃对基于零的压缩oop的要求，那么可以设置
-XX:HeapBaseMinAddress=0. 在这种情况下，计算出的堆大小为