idRepo filesize慢慢增长到大

时间:2018-02-08 08:35:08

标签: java openam

目前正在与我们使用openAm的客户合作开展项目。然而,我们注意到idRepo文件的大小正在缓慢增长。即使它在一些空间变得越来越有限的地方已经慢慢增长,已经达到了120Gb。我们有一些文档提到,每当idRepo到达如此庞大的文件大小时,您需要调整debugconfig.properties文件中的一些设置,该文件位于我们的文件中:

installationDirectory\OpenAM\apache-tomcat-8.0.20\webapps\OpenAM-12.0.0\WEB-INF\classes directory

提到的文档可在此处找到: (https://docs.bmc.com/docs/display/public/sso90/Debug+log+files

从我能从该页面理解的是我必须添加:

org.forgerock.openam.debug.prefix=debug
org.forgerock.openam.debug.suffix='.'u'.log'
org.forgerock.openam.debug.rotation=1440
org.forgerock.openam.debug.history.files.count=7

到debugconfig.properties文件,我做了。我们还在文档中提到停止并启动了服务器。这发生在2天前,因为写这个。然而,文件大小没有改变。现在这里出现了一些缺乏经验,因为我对openAm知之甚少,并且不知道idRepo是什么。谷歌搜索后,我无法找到这个问题的正确答案。我希望每天都会创建一个日志文件,因为我添加了旋转设置。但是日志文件夹是空的。现在,这正在我们的开发/测试服务器上进行,因此问题不大。但是,如果我们无法在这些服务器上修复它,我们就无法在PRODUCTION服务器上修复它,这将以这种方式慢慢解决崩溃问题。

我的同事不知道这个问题的答案以及有限的文档(或者我对它的理解不足)我希望stackOverflow上的某个人可以给我一个更好的答案和/或解决方案。

如果缺少信息,我很乐意尽可能地添加它。 非常感谢提前!

编辑:12-02-2018 我一直在关注文件大小是否一直在增长,我可以说它不是测试环境(这是我根据答案进行调整的地方) 在其他两个环境中,一个正在生产的文件大小确实在缓慢但肯定地增长。如果我检查测试环境中的属性,它将告诉我最后的修改已完成3 januari 2017.如果我在其他2个环境中的任何一个检查它它将告诉我调整是在第二个我打开的属性(到第二个确切)。 debugproperties文件包含:

org.forgerock.openam.debug.prefix=debug
org.forgerock.openam.debug.suffix='.'u'.log'
org.forgerock.openam.debug.rotation=1440
org.forgerock.openam.debug.history.files.count=7

也在2017年januari进行了调整。这将使我相信使用这些设置将阻止idRepo文件进一步增长,直到此时为止。如果有人能够证明对我来说那将是伟大的(我将在我接受生产之前在接受环境中进行测试)。

再一次,我想感谢你们的快速回复和帮助!如果您需要更多信息,请随时提出!

2 个答案:

答案 0 :(得分:0)

如果在开发环境中发生这种情况,则可能是您已使用消息级别调试日志模式配置OpenAM实例。要检查调试日志级别,您应该转到Configuration - >服务器和站点 - >默认服务器(和/或列表中的每个服务器) - >常规选项卡。

修复应该是将调试级别更改为错误,因为它更简洁,并且不太可能导致磁盘空间问题。

我还应该指出,据我所知,引用的org.forgerock.openam.debug.history.files.count设置实际上并不存在。据我所知,OpenAM永远不会删除翻转的调试日志文件。

答案 1 :(得分:-1)

这是一个猜测,因为我的知识少于OpenAM(即没有),但我将其作为答案包括在内,因为它的评论时间太长了。

我在ForgeRock的Confluence页面找到了一份名为Tune Caches in OpenAM的文件。它提到了一些与上面列出的设置不同的设置。

特别是,我相信你可以通过设置:

来禁用idRepo缓存
com.iplanet.am.sdk.caching.enabled=false
com.sun.identity.sm.cache.enabled=true
com.sun.identity.idm.cache.enabled=false

(这种设置的确切组合不会出现在文档中,但它们显示的其他组合暗示了它。)

还有idRepo缓存的最大大小设置:

  

属性:com.iplanet.am.sdk.cache.maxSize

     

可以使用此属性调整IdRepo缓存的大小。默认情况下,此缓存最多包含10,000个条目。请注意,没有等效的属性来控制SMS缓存的大小。

还有一些设置与基于生存时间的idRepo缓存中的条目到期有关。我将在这里逐字复制该文件的那一部分:

  

属性:com.sun.identity.idm.cache.entry.expire.enabled
  物业:com.sun.identity.idm.cache.entry.default.expire.time

     

这些属性控制IdRepo缓存是否会根据生存时间以及条目在到期之前可能获得的条目到期而使条目到期。默认情况下,enabled属性为False,expire.time为30(后者以分钟表示)。

     

属性:com.sun.identity.sm.cache.ttl.enable
  物业:com.sun.identity.sm.cache.ttl

     

这些属性控制SMS缓存是否会根据生存时间使条目到期,并设置最大生存时间值。默认情况下,这些属性分别为false和30分钟。 TTL值以分钟表示。

     

在繁忙的系统中,通过扩展这些生存时间值可以实现显着的性能提升,但这必须与底层数据的变化率进行平衡。用户数据(IdRepo缓存)通常以比OpenAM配置数据高得多的速率发生变化,因此IdRepo TTL应保持相对较低,而SMS TTL可能要高得多。

还有更多,但我不愿在这里复制它。我怀疑设置最大大小或生存时间可能有助于解决您的问题,甚至可能关闭缓存并重新打开可能会清除旧条目(我不知道,也不知道是否你想要)。

同样,我没有使用OpenAM的经验,只提供给我设法谷歌的东西,希望它可能有所帮助。它确实给了我一些暂停,你提到的设置都是org.forgerock,而这些设置是com.iplanetcom.sun,这让我想知道这个文档是否已过时,但它可能会简要介绍一下OpenAM的发展历史,它始于Sun Microsystems项目。