Tridion 我们发布的每个页面都会在服务器上增加大约2MB的内存。这是配置问题吗？

我们发布的每个页面都会在服务器上增加大约2MB的内存。这是配置问题吗

仅供参考，这是SDL Tridion 2011 SP1，带有旧的vbscript代码。

---

请建议。

它会一直增加直到停止响应吗？或者这段记忆会在以后被重新找回

使用VBScript模板不一定是一个问题，但我肯定会尝试确保所有对象都在模板中正确释放（将它们设置为

Nothing

），并且代码检查始终是一个好主意

---

正如Dave所建议的，使用默认模板进行测试总是一个好主意。

不-这不是配置问题

至少，也就是说，假设您看到的是内存泄漏。Tridion在渲染期间缓存各种项目，其中一些缓存行为是可配置的。你是说每次页面渲染内存都会增加吗？它不会再下来了？哪个进程拥有这个内存？是发布者服务，还是COM+代理（dllhost），还是其他什么

仅仅通过配置Tridion是不可能导致内存泄漏的

---

您的事件日志中是否显示了任何可能会对此有所帮助的错误？不要忘记查看应用程序/系统日志以及Tridion日志。

我认为最重要的评论已经发表。这很可能是由于未释放已使用

Set blah=foo

的对象，以及未使用

Set blah=Nothing

释放对象而导致的内存泄漏。但是，如果发布服务器没有持续增长到失败的程度，那么它可能只是发布服务器对模板的良好缓存

对于Tridion的早期版本，我们有一个名为CodePlumber的社区构建的PowerTool（可在上获得），用于查找此类泄漏。正如您清楚地了解VBScript（该工具是使用基于VBScript的经典ASP编写的）一样，可能值得阅读该代码或重新使用该代码来测试模板。您甚至可能希望在将其迁移到新框架时获得一些额外的积分

---

我的最后一个问题是这些模板是否已经从Tridion的早期版本中移除，如果是，是否也观察到了相同的内存增长。如果没有，您可能会看到在发布过程中如何处理旧模板的新问题。

您没有提到内存增加的地方，但最常见的地方是COM+对象

如果是这种情况，解决这个问题的蛮力方法是以内存阈值实现COM+回收。阈值将取决于您从何处开始看到问题，以及服务器上的可用内存，但1GB是一个很好的调整起点

这种回收应该不会影响用户的体验

注意，这实际上并没有解决问题——它只是防止问题导致系统的其余部分崩溃

---

正如其他海报所提到的，修复问题可能意味着跟踪旧VBScript代码中的内存泄漏。

如果没有更多信息，将很难为您提供帮助。这可能是模板代码中的内存泄漏。无论发布哪些项目，都会发生相同的情况吗？如果您使用默认页面模板如何？您是使用100%VBScript模板，还是使用模块化模板和传统模板的组合？很抱歉没有在此处添加更多详细信息，我相信问题不大，但感谢您在回答中提供了许多有用的信息。。