具有可突发 RAM 的虚拟服务器上的 Java 堆空间 Xmx Xms
我们在具有 1GB 保证 RAM 和 4GB 可突发 RAM 的虚拟服务器上运行依赖于 Java 的 Minecraft 服务器。
我们运行 Debian 6.0 (Squeeze) Minimal（64 位），并带有带有 php/mySQL 的 lighttpd Web 服务器以及实际的 Minecraft 服务器。目前，我们已将所有内容设置为保持在 1GB 保证 RAM 之内，但似乎我们没有以这种方式利用可突发 RAM，也不知道应该如何（以及是否？） 这样做。
目前我们的服务器加载了以下字符串：
/opt/java/jre/bin/java -Xmx880M -Xms880M
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalPacing
-XX:ParallelGCThreads=2
-XX:+AggressiveOpts
-jar craftbukkit.jar nogui
我们为我的世界分配了 880M（我们认为？），其余的为系统、网络服务器等保留。我们如何优化此设置？将这个初始启动分配超过 1GB 并充分分配到我们的可突发 RAM 中是否有意义？ Java或系统有没有办法自己处理这个问题，比如在高峰需要时分配超过880M，最大4GB？由于无法保证可突发 RAM，如果在需要时不可用，会发生什么情况？谢谢！
We run a Minecraft server that relies on Java on a vServer that has 1GB guaranteed RAM and 4GB burstable RAM.
We run Debian 6.0 (Squeeze) Minimal (64Bit) with a lighttpd webserver with php/mySQL alongside the actual Minecraft server. We currently have everything set up to stay within our 1GB guaranteed RAM, but it seems as if we are not taking advantage of the burstable RAM this way, nor do we know how (and if?) we should do so.
We currently have our server loading with the following string:
/opt/java/jre/bin/java -Xmx880M -Xms880M
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalPacing
-XX:ParallelGCThreads=2
-XX:+AggressiveOpts
-jar craftbukkit.jar nogui
We allocate 880M for minecraft (we think?), the rest is reserved for the system, webserver etc. How could we optimize this setup? Does it make sense to allocate this inital startup over the 1GB and well into our burstable RAM? Is there a way for Java or the system to handle this themselves, as in allocating more than 880M when it's needed at peak times, with a max of 4GB? Since the burstable RAM isn't guaranteed, what will happen if it's not available when it would need it? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于。您应该首先分析该进程的内存使用情况。 添加
将
-verbose:gc:file=gc_results.out到命令行。您可以使用 HPjmeter 等工具打开生成的 gc 数据文件。您应该根据平均/峰值内存使用情况调整堆。没有一种政策适合所有的“最佳”政策。首先，检查您平均在垃圾收集上花费了多少时间。一个好的经验法则是< 7%。您多久触发一次 Full GC？您的堆中是否充满了长期存在的对象，或者是否被大量短期存在的对象轰炸？这些问题应该推动您的决策。
It depends. You should first profile the memory usage of this process. Add
-verbose:gc:file=gc_results.outto your command line. You can open the resulting gc datafile with a tool like HPjmeter. You should tune the heap based on average/peak memory usage. There is no one size fits all policy thats 'optimal'. As a start, inspect how much time you're spending in garbage collection on average. A good rule of thumb is < 7%. How often are you triggering a Full GC? Is your heap full of long living objects, or is it being bombarded with lots of short lived objects? These questions should drive your decision making.
服务器将大部分时间花费在分配的最大 RAM 上。我对“可突发”RAM 的理解是——不要指望它，但如果你短暂需要它，它可能不会崩溃。在这种情况下，您不希望 JVM 挂在可突发的 RAM 上。您指定的配置似乎是正确的。
A server will spend most of its time taking the maximum RAM allotted. My understanding of "burstable" RAM is--don't count on it, but if you briefly require it it might not crash. In this case, you don't want your JVM hanging on to burstable RAM. The configuration you've specified seems about right.