idRepo 文件大小慢慢变大
idRepo filesize slowly growing to large
目前我正在与我们使用 openAm 的客户合作开展一个项目。然而，我们注意到 idRepo 文件的大小正在缓慢增长。尽管它增长缓慢，但在某些 space 变得越来越受限的地方，它已经达到 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 是什么。谷歌搜索后我找不到这个问题的正确答案。自从我添加轮换设置后，我希望每天都会创建一个日志文件。虽然日志文件夹是空的。现在这发生在我们的 develop/test 服务器上，所以问题不大。但是如果我们不能在这些服务器上修复它，我们就不能在生产服务器上修复它，这将以这种方式慢慢地导致崩溃。
我的同事不知道这个问题的答案，而且由于文档有限（或者我不理解）我希望 Whosebug 上的人能给我一个更好的答案 and/or 解决方案。
如果缺少信息，我很乐意在可能的情况下添加。
非常感谢！
编辑：2018 年 2 月 12 日
我一直在关注文件大小是否在增长，我可以声明它不是测试环境（这是我根据答案进行调整的地方）
在其他 2 个环境中，一个是生产环境，文件大小确实在缓慢但肯定地增长。如果我检查测试环境中的属性，它会告诉我最后一次修改是在 2017 年 1 月 3 日完成的。如果我在其他两个环境中的任何一个中检查它，它会告诉我调整是在我打开属性的那一刻完成的（到第二个确切）。 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 年 1 月 3 日进行了调整。这让我相信使用这些设置将阻止 idRepo 文件比目前为止增长得更多。如果有人可以为我验证那会很棒（我将在我开始生产之前在我自己的验收环境中测试它）。
再次感谢你们的快速回复和帮助！如果您需要更多信息，请随时询问！
这是一个猜测，因为我 OpenAM 的知识比你少（即 none），但我将其作为答案包含在内，因为它太长了无法发表评论。
我在 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 缓存也有一个最大大小设置：
Property: com.iplanet.am.sdk.cache.maxSize
The size of the IdRepo cache may be adjusted with this property. By default this cache will contain up to 10,000 entries. Note that there is no equivalent property to control the size of the SMS cache.
还有与根据生存时间使 idRepo 缓存中的条目过期相关的设置。我将在此处逐字复制文档的该部分：
Property: com.sun.identity.idm.cache.entry.expire.enabled
Property: com.sun.identity.idm.cache.entry.default.expire.time
These properties control whether the IdRepo cache will expire entries based on time-to-live and how old entries may get before expiring. By default the enabled property is False and the expire.time is 30 (the latter is expressed in minutes).
Property: com.sun.identity.sm.cache.ttl.enable
Property: com.sun.identity.sm.cache.ttl
These properties control whether the SMS cache will expire entries based on time-to-live and set the maximum time-to-live value. By default these properties are false and 30 minutes respectively. The TTL value is expressed in minutes.
In busy systems significant performance gains can be achieved by extending these time-to-live values but this must be balanced against the change rate of the underlying data. User data (IdRepo cache) typically changes at a much higher rate than OpenAM configuration data so the IdRepo TTL should be kept relatively low while SMS TTL may be much higher.
还有很多，但我犹豫要不要全部复制到这里。我怀疑设置最大大小或生存时间可能有助于解决您的问题，或者甚至可能关闭缓存并再次打开可能会清除旧条目（我不知道，也不知道您是否会想要）。
同样，我没有使用 OpenAM 的经验，因此仅作为我设法 Google 提供的内容，希望它能有所帮助。它确实让我有点停顿，你提到的设置都是 org.forgerock 而这些是 com.iplanet 和 com.sun，这让我想知道这个文档是否过时了，但它可能回顾一下 OpenAM 的发展历史，它的生命始于 Sun Microsystems 项目。
如果这发生在开发环境中，可能是您已将 OpenAM 实例配置为消息级调试日志模式。要检查调试日志级别，您应该转到配置 -> 服务器和站点 -> 默认服务器（and/or 列表中的每个服务器单独） -> 常规选项卡。
修复应该是将调试级别更改为错误，因为它不那么冗长，而且不太可能导致磁盘 space 问题。
我还应该指出，据我所知，引用的 org.forgerock.openam.debug.history.files.count 设置实际上并不存在。据我所知，OpenAM 从未删除滚动的调试日志文件。
目前我正在与我们使用 openAm 的客户合作开展一个项目。然而，我们注意到 idRepo 文件的大小正在缓慢增长。尽管它增长缓慢，但在某些 space 变得越来越受限的地方，它已经达到 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 是什么。谷歌搜索后我找不到这个问题的正确答案。自从我添加轮换设置后，我希望每天都会创建一个日志文件。虽然日志文件夹是空的。现在这发生在我们的 develop/test 服务器上，所以问题不大。但是如果我们不能在这些服务器上修复它，我们就不能在生产服务器上修复它，这将以这种方式慢慢地导致崩溃。
我的同事不知道这个问题的答案，而且由于文档有限（或者我不理解）我希望 Whosebug 上的人能给我一个更好的答案 and/or 解决方案。
如果缺少信息，我很乐意在可能的情况下添加。 非常感谢！
编辑：2018 年 2 月 12 日 我一直在关注文件大小是否在增长，我可以声明它不是测试环境（这是我根据答案进行调整的地方） 在其他 2 个环境中，一个是生产环境，文件大小确实在缓慢但肯定地增长。如果我检查测试环境中的属性，它会告诉我最后一次修改是在 2017 年 1 月 3 日完成的。如果我在其他两个环境中的任何一个中检查它，它会告诉我调整是在我打开属性的那一刻完成的（到第二个确切）。 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 年 1 月 3 日进行了调整。这让我相信使用这些设置将阻止 idRepo 文件比目前为止增长得更多。如果有人可以为我验证那会很棒（我将在我开始生产之前在我自己的验收环境中测试它）。
再次感谢你们的快速回复和帮助！如果您需要更多信息，请随时询问！
这是一个猜测，因为我 OpenAM 的知识比你少（即 none），但我将其作为答案包含在内，因为它太长了无法发表评论。
我在 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 缓存也有一个最大大小设置：
Property: com.iplanet.am.sdk.cache.maxSize
The size of the IdRepo cache may be adjusted with this property. By default this cache will contain up to 10,000 entries. Note that there is no equivalent property to control the size of the SMS cache.
还有与根据生存时间使 idRepo 缓存中的条目过期相关的设置。我将在此处逐字复制文档的该部分：
Property: com.sun.identity.idm.cache.entry.expire.enabled
Property: com.sun.identity.idm.cache.entry.default.expire.timeThese properties control whether the IdRepo cache will expire entries based on time-to-live and how old entries may get before expiring. By default the enabled property is False and the expire.time is 30 (the latter is expressed in minutes).
Property: com.sun.identity.sm.cache.ttl.enable
Property: com.sun.identity.sm.cache.ttlThese properties control whether the SMS cache will expire entries based on time-to-live and set the maximum time-to-live value. By default these properties are false and 30 minutes respectively. The TTL value is expressed in minutes.
In busy systems significant performance gains can be achieved by extending these time-to-live values but this must be balanced against the change rate of the underlying data. User data (IdRepo cache) typically changes at a much higher rate than OpenAM configuration data so the IdRepo TTL should be kept relatively low while SMS TTL may be much higher.
还有很多，但我犹豫要不要全部复制到这里。我怀疑设置最大大小或生存时间可能有助于解决您的问题，或者甚至可能关闭缓存并再次打开可能会清除旧条目（我不知道，也不知道您是否会想要）。
同样，我没有使用 OpenAM 的经验，因此仅作为我设法 Google 提供的内容，希望它能有所帮助。它确实让我有点停顿，你提到的设置都是 org.forgerock 而这些是 com.iplanet 和 com.sun，这让我想知道这个文档是否过时了，但它可能回顾一下 OpenAM 的发展历史，它的生命始于 Sun Microsystems 项目。
如果这发生在开发环境中，可能是您已将 OpenAM 实例配置为消息级调试日志模式。要检查调试日志级别，您应该转到配置 -> 服务器和站点 -> 默认服务器（and/or 列表中的每个服务器单独） -> 常规选项卡。
修复应该是将调试级别更改为错误，因为它不那么冗长，而且不太可能导致磁盘 space 问题。
我还应该指出，据我所知，引用的 org.forgerock.openam.debug.history.files.count 设置实际上并不存在。据我所知，OpenAM 从未删除滚动的调试日志文件。