解决内存占用高的谜团

有时候，我的工作很简单，问题一看就可以解决（当我有幸看到需要看的地方时，就像这个 Varchar 可能会损害你的性能 – 全麦的博客（vimvq1987.1） com））。 有时，这很难。 数不清有多少次我盯着屏幕发呆，决定先小睡一会，煮杯咖啡，或者出去走走（那是骗人的，不过，我不走路），因为我不知道，这毫无进展。 软件诊断工程师的生活就是这样，有时你正在解开“我需要什么来解开这个谜团”的谜团。 通常到处都有更多的点，你的工作是找出哪些点有意义，哪些点没有意义，以及如何连接那些与解决问题相关的点，并讲述一个故事。

今天的故事是关于一位客户抱怨 DXP 上的预定实例在运行查找索引作业后内存仍然很高。 他们有一个自定义作业，旨在优化其语言设置的性能，但其想法是相同的 – 加载内容，序列化并将其发送到服务器端点以进行索引。 这确实是一项内存繁重的工作，尤其是当您有大量需要索引的内容时（基本上，内容数量 x 语言数量 x 内容的复杂性）。 在此类作业期间内存使用量增加是正常的 – 应用程序（或者更确切地说，运行时，取决于您查看它的方式）正在执行该作业 – 内容需要加载到内存中，并且如果有可用的内容内存如果不被用来做一些有用的事情，那将是一种巨大的浪费。 并且应用程序不会立即释放该内存，因为内容已被缓存。 只有当缓存过期或者应用程序有内存压力（即向操作系统请求更多内存并且操作系统拒绝“没有剩余的内存”）时，才会回收内存。 即使缓存过期，应用程序也不会总是压缩内存并将其释放回操作系统（LOH 等）

现在的问题是客户应用程序无限期地保留 25GB 内存。 他们等了24小时，但内存使用率仍然很高。 该应用程序看起来很好，它不会因为内存问题（例如内存不足）而崩溃，但它会给我们的客户带来混乱和担忧。 比赛开始了。

在这种情况下没有意义的一件事是，即使他们有自定义索引作业，它仍然是一项计划作业。 对于计划作业，内容应该具有非常短的滑动过期时间（默认为 1 分钟）。 然而，内存转储中的缓存条目却讲述了不同的故事。 大多数缓存条目都有 12 小时的滑动过期时间。 这确实解释了——至少部分地——为什么记忆力仍然很高。 当滑动时间较长时，缓存在过期前至少被命中一次的机会就更高，从而重置过期时间。 如果您有足够的命中，缓存将有效地永远保留在内存中，直到您主动驱逐它（例如通过编辑内容）

0000753878028910                        0.77kb          0                           12:00:00                    2/16/2024 5:58:43 AM +00:00    EPPageData:601596:en__CatalogContent
0000753878029DC0                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1345603:es-pr__CatalogContent
00007538781C7F48                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1351986:es-pr__CatalogContent
00007538781C8058                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1346230:es-pr__CatalogContent
00007538781C8168                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1351988:es-pr__CatalogContent
00007538786FA8E8                        0.77kb          0                           12:00:00                    2/16/2024 8:14:53 AM +00:00    EPPageData:1049433:no__CatalogContent
00007538786FC598                        0.78kb          0                           12:00:00                    2/16/2024 9:32:28 AM +00:00    EPPageData:1088026:es-pr__CatalogContent
00007538786FD9E0                        0.77kb          0                           12:00:00                    2/16/2024 8:14:53 AM +00:00    EPPageData:1049435:no__CatalogContent
0000753878700770                        0.77kb          0                           12:00:00                    2/16/2024 7:52:53 AM +00:00    EPPageData:1029725:da__CatalogContent
0000753878706528                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1351990:es-pr__CatalogContent
0000753878706638                        0.78kb          0                           12:00:00                    2/16/2024 2:59:39 PM +00:00    EPPageData:1350104:es-pr__CatalogContent
00007538787A2F80                        0.77kb          0                           12:00:00                    2/16/2024 8:14:53 AM +00:00    EPPageData:1049439:no__CatalogContent
00007538787A3FD0                        0.77kb          0                           12:00:00                    2/16/2024 7:52:53 AM +00:00    EPPageData:1029729:da__CatalogContent
00007538787A6B48                        0.77kb          0                           12:00:00                    2/16/2024 7:52:53 AM +00:00    EPPageData:1029731:da__CatalogContent
00007538787A74C0                        0.77kb          0                           12:00:00                    2/16/2024 6:21:34 AM +00:00    EPPageData:690644:en__CatalogContent
00007538787A9CC8                        0.78kb          0                           12:00:00                    2/16/2024 5:43:57 AM +00:00    EPPageData:181410:cs-cz__CatalogContent
00007538787ACDD8                        0.82kb          0                           12:00:00                    2/16/2024 2:17:38 PM +00:00    EPPageData:1343746__CatalogContent
00007538787ACFF8                        0.83kb          0                           12:00:00                    2/16/2024 2:17:25 PM +00:00    EPPageData:1343746:en__CatalogContent
00007538787AE658                        0.77kb          0                           12:00:00                    2/16/2024 2:59:37 PM +00:00    EPPageData:1350160:da__CatalogContent
00007538787AE768                        0.77kb          0                           12:00:00                    2/16/2024 2:59:37 PM +00:00    EPPageData:1350162:da__CatalogContent
00007538787AEA98                        0.39kb          0                           00:00:00                    2/16/2024 2:17:38 PM +00:00    EPiAnc:ContentAssetAware1343745__CatalogContent
00007538787AF058                        0.77kb          0                           12:00:00                    2/16/2024 2:59:37 PM +00:00    EPPageData:1347560:da__CatalogContent
00007538787B29A0                        0.77kb          0                           12:00:00                    2/16/2024 2:17:07 PM +00:00    EPPageData:1329806:da__CatalogContent
00007538787B2E68                        0.77kb          0                           12:00:00                    2/16/2024 2:17:07 PM +00:00    EPPageData:1329808:da__CatalogContent
00007538787B31E8                        0.77kb          0                           12:00:00                    2/16/2024 2:17:07 PM +00:00    EPPageData:1329810:da__CatalogContent

然而，这并不是它应该的样子，因为计划作业加载的内容的滑动过期超时的默认值为 1 分钟，即它被认为是加载一次并完成的项目。 是否错误地设置为 12 小时？ 没有

超时设置为 600.000.000 周期，即 60 秒，这是默认值。

我已经为此烦恼了好一阵子了。 如果缓存条目不是通过计划作业添加的，而是通过不受计划作业限制的其他方式添加的，该怎么办？ 简而言之，我们被客户有关查找索引工作的声明所欺骗。 它只是同一问题的受害者。 它正在重置对缓存条目的最后一次访问，但仅此而已。

是时候多挖一点了。 虽然 Windbg 非常强大，但它不会让您知道将特定内容加载到缓存中的代码在哪里（除非您当场抓住它）。 因此，唯一了解的方法就是环顾四周，检查是否有任何可疑的电话 IContentLoader.GetItems 或者 IContentLoader.GetChildren 。 我的一位同事与客户合作获取了他们的源代码，并进行了另一次深入研究。

对我们来说幸运的是，客户有一个定制的查找索引器，我们在之前的问题中帮助构建了该索引器，并且该索引器显示在搜索中 GetItems。 我突然意识到它可能是罪魁祸首。 工作本身……很好，但是它给出了错误的数据，因此它不断将内容加载到索引。

如果我的假设是正确的，那么这些事情一定是真的：

• 无论索引作业是否运行，应用程序的内存使用量都会增加到 25GB。 并且一直保持在那里，没有太大的波动
• 里面有很多行 tblFindIndexQueue

事实证明这两个都是正确的：有超过 400 万行 tblFindIndexQueue，这是应用程序在 24 小时内的内存消耗

一旦我们弄清楚了内容加载的来源，修复就非常简单了。 我们可以做的一件事是缩短事件驱动索引器加载的内容的缓存时间。 您应该升级到 Find 16.2.0，其中包含 FIND-12436 的修复程序，这对于内存使用来说是一个很好的改进。

故事的寓意：

• 我是一个工作狂。 我绝对不应该在周末工作，但有时我需要这样做，因为那是我头脑最清醒的时候
• 继续寻找。 但一如既往，知道何时放弃和承认失败
• 休息一下。 长款、短裤。 刷新你的思维，从不同的角度来看。
• 滑动缓存过期时间可能非常出乎意料。 如果内容已经在缓存中且具有较长的滑动过期时间，则缓存命中（通过 ISynchronizedObjectInstanceCache.ReadThrough 获取滑动过期时间短的内容不会改变该值，只会刷新上次访问时间，反之亦然）