河豚·
如题，服务器因无法及时回收内存而卡顿，类似滚雪球一样的效果
如何查看被占用的内存都用来做什么了！
求大佬帮助，有偿解决！
之前的求助帖：https://www.mcbbs.net/thread-1244007-1-1.html



Flowers_花花
本帖最后由 Flowers_花花 于 2021-8-16 01:44 编辑

删除无用的启动参数 留一个-XX:+UseG1GC
还有你的服务器总体内存是多少 不是指的Bat 是服务器
河豚·
Flowers_花花 发表于 2021-8-16 01:42
删除无用的启动参数 留一个-XX:+UseG1GC
还有你的服务器总体内存是多少 不是指的Bat 是服务器
...



目前只保留了两个参数，总内存128Gb



Flowers_花花
河豚· 发表于 2021-8-16 01:56
目前只保留了两个参数，总内存128Gb

bat没啥问题 服务器也没啥问题
问题可能出现在服务端核心/插件
河豚·
Flowers_花花 发表于 2021-8-16 01:57
bat没啥问题 服务器也没啥问题
问题可能出现在服务端核心/插件

有没有什么好的办法查看占用吗，如果排查插件可能要花上好久
ARSpark
本帖最后由 RarityEG 于 2021-8-16 08:59 编辑

只看你的图片是看不出什么来的，Free 5K -> 2K 然后进行一次 GC 本身就是 VM 的正常行为
（可以通过输出 GC 日志来精确排查问题，但那个可以要命，还是算了吧）

首先考虑是 Full GC 被触发的问题，可试着加入一个 -XX:+DisableExplicitGC 观察现象，如果问题没有得到解决，移除该选项，然后尝试下一个方法。

再就是考虑 G1 不适合楼主的情况，G1 虽然大多数情况是默认设置，但这也意味着它有时不是最好的方案，你可以试试以下 GC 参数：
（删除原先的参数，仅保留 -jar）

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=2 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSScavengeBeforeRemark -XX:+CMSClassUnloadingEnabled -Xmx12G -Xms12G -Xmn1536M

其中几个堆的大小和比例我替楼主做了决策，但可能不是最优解，特别是Xmn后的新生代大小，这里的参数我采用了一个比较激进的方案，楼主可以先行尝试，看看问题能否得到缓解，如果不能，可根据情况再调整其中的各个数值，手调 GC 有风险，当心内存溢出或程序崩溃回档，请提前告知玩家

以及我想知道楼主的 JVM 是什么？
河豚·
RarityEG 发表于 2021-8-16 08:48
只看你的图片是看不出什么来的，Free 5K -> 2K 然后进行一次 GC 本身就是 VM 的正常行为
（可以通过输出 GC ...
如果真要尝试，加上 -XX:+PrintGCTimeStamps  -XX:+PrintGCDetails  -verbose:gc  -Xloggc:日志文件保存路径（如c:/你的服务端文件夹/gc.log），等出现卡顿，卡顿结束时立即停止服务端，将 gc.log 上传到诸如 PasteBin 的地方，然后把链接贴过来（但是小心 GC 日志把你控制台给炸翻天）

犹豫并不了解类似的上传方式，上传到pasteBin也无法上传，所以还是冒犯的打个压缩包吧
gc.zip (326.94 KB, 下载次数: 1)

首先考虑是 Full GC 被触发的问题，可试着加入一个 -XX:+DisableExplicitGC 观察现象，如果问题没有得到解决，移除该选项，然后尝试下一个方法。
此处的参数一直运用至今，貌似没任何作用
再就是考虑 G1 不适合楼主的情况，G1 虽然大多数情况是默认设置，但这也意味着它有时不是最好的方案，你可以试试以下 GC 参数：
（删除原先的参数，仅保留 -jar）

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=2 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSScavengeBeforeRemark -XX:+CMSClassUnloadingEnabled -Xmx12G -Xms12G -Xmn1536M
参数确实让内存回收的正常一些，但还是会像滚雪球一样越来越少
至于JVM我还没有安装

如果可以球大佬留个联系方式，亲自看看后台！


ARSpark
本帖最后由 RarityEG 于 2021-8-16 21:08 编辑
河豚· 发表于 2021-8-16 20:50
犹豫并不了解类似的上传方式，上传到pasteBin也无法上传，所以还是冒犯的打个压缩包吧

那一长串参数，再加上最上面的 -XX:+PrintGCTimeStamps  -XX:+PrintGCDetails  -verbose:gc  -Xloggc:日志文件保存路径 呢？
（既然 CMS 能缓解问题，肯定要看这个参数的 GC 日志（
附：通过原来 G1 的日志

[Eden: 24.0M(612.0M)->0.0B(612.0M) Survivors: 0.0B->0.0B Heap: 12.0G(12.0G)->12.0G(12.0G)]

[Eden: 476.0M(612.0M)->0.0B(612.0M) Survivors: 0.0B->0.0B Heap: 12.0G(12.0G)->11.9G(12.0G)]


可以看出 Old 的 GC 作用很小，然后触发了 Full GC

17817.161: [Full GC (Allocation Failure)  11G->11G(12G), 19.9006423 secs]
   [Eden: 0.0B(612.0M)->0.0B(612.0M) Survivors: 0.0B->0.0B Heap: 12.0G(12.0G)->12.0G(12.0G)], [Metaspace: 280169K->280169K(1300480K)]
[Times: user=31.47 sys=0.00, real=19.90 secs]

（结果造成卡顿，问题是这个 Full GC 也没起作用Heap: 12.0G(12.0G)->12.0G(12.0G)然后后来的空间一直不释放，造成一直 Full GC

（我也怀疑可能是哪个软件导致很多对象一直不释放


（Hotspot 64……建议换 OpenJ9，不过 J9 的 GC 日志更要命

河豚·
RarityEG 发表于 2021-8-16 20:53
那一长串参数，再加上最上面的 -XX:+PrintGCTimeStamps  -XX:+PrintGCDetails  -verbose:gc  -Xloggc:日志 ...
那一长串参数，再加上最上面的 -XX:+PrintGCTimeStamps  -XX:+PrintGCDetails  -verbose:gc  -Xloggc:日志文件保存路径 呢？


gc.zip (181.32 KB, 下载次数: 1)
加入参数后的gc.log，下面是参数不知是否正确

@echo off&setlocal enabledelayedexpansion       
set a=-1
:start
set /a a+=1
title 重启次数:%a% [生存一区]
set /a s=3+1
for /l %%i in (1,1,!s!) do (
set /a s-=1
ping -n %s% 127.1>nul
echo 倒计时开始！ !s!)
java -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=2 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSScavengeBeforeRemark -XX:+CMSClassUnloadingEnabled -Xmx12G -Xms12G -Xmn1536M -XX:+PrintGCTimeStamps  -XX:+PrintGCDetails  -verbose:gc -jar CatServer-92b87c7-universal.jar nogui
goto start
pause