几天后，我的AEM服务器变得无响应并崩溃。根据{{3}}的这篇文章，在检查https://helpx.adobe.com/experience-manager/kb/check-and-analyze-if-JCR-session-leaks-in-your-AEM-instance.html时，我发现有超过60,000个SessionStatistics对象。我想知道这些代表什么？这些活动会议吗？还是这是曾经在AEM服务器上创建的所有会话的列表？
答案 0 :(得分：1)
我想知道这些代表什么？这些活动会议吗？还是这是曾经在AEM服务器上创建的所有会话的列表？
是的，这些是当前在您的AEM服务器上运行的活动打开会话-自上次启动实例以来创建。您可以从/system/console/vmstat中找到最后一个开始时间，所有会话对象在Last Started时间之后都会有一个时间戳。您会注意到会话名称的时间戳。与此类似。
"communities-user-admin@session-1132@25/10/2018 5:03:26 PM"
您发布的链接已经表明潜在的开放会话修复程序。
建立会话对象的另一个可能原因是由于长期运行的JCR查询效率低下（没有索引的查询，非常广泛的谓词等）。由于内存使用量的增加（如果未在启动脚本中指定mem参数），这可能导致垃圾回收的增加，分析gc.log可能会提供一些见解。如果您很清楚查询是导致会话对象堆积的原因，则可以在启动脚本中使用这些参数来优化正在使用的资源。
-Doak.queryLimitInMemory=1000 -Doak.queryLimitReads=1000 -Dupdate.limit=1000 -Doak.fastQuerySize=true
要找到gc.log的位置，请使用lsof
lsof -p ${JAVA PID} | grep gc.log