【发布时间】：2012-10-04 08:33:04
【问题描述】：
我有一个类似于this 的问题，但希望我已经缩小了一些范围。
我目前正在测试我的 Tridion 2011 安装的发布部分（Conent Manager 和 Content Delivery 在不同的服务器上）。当我尝试一次发布多个页面（在我的情况下为 1000 个）时，进程dllhst3g.exe *32 开始获取大量内存。这是可以理解的，因为有很多工作要做，但它永远不会回报。这导致内容管理器运行缓慢并最终崩溃。
当dllhst3g.exe *32 进程有大约 3.6GB 的内存（我认为这是因为它是一个 32 位进程）时，Tridion Content Manager 抛出了内存不足异常。为了防止这些，我将SDL Tridion Content Manager COM+ 应用程序限制为每个进程任意 500Mb，在达到限制后 15 分钟被强制终止。这暂时停止了内存不足的异常，但如果在 15 分钟窗口内分配的服务器超过 8GB，我仍然存在性能问题和内存不足的可能性。 More about this here
我已经排除了底层的 PageTemplate 代码，因为关联的页面模板没有关联的代码。这些页面是空白的。
在使用核心服务 API 时，这个问题似乎也更加突出。我使用的代码是
using (var client = new Tridion2011CoreService.CoreServiceClient())
{
foreach (var id in ids) // ids is a collection of 500 page ids
{
// publishing to staging and live
var targets = new string[] { "tcm:0-7-65538", "tcm:0-8-65538" };
var publishInstructionData = new PublishInstructionData();
publishInstructionData.ResolveInstruction = new ResolveInstructionData();
publishInstructionData.RenderInstruction = new RenderInstructionData();
var readOptions = new ReadOptions();
client.Publish(new string[] { id }, publishInstructionData, targets, PublishPriority.Normal, readOptions);
}
}
（我意识到我可以通过一次调用来发送所有 ID，但随后我遇到了消息限制错误，据我所知，多次调用和一次调用的结果实际上是相同的）
有什么想法吗？
（如果我遗漏了任何细节，请告诉我，我会相应地更新问题）
忘记添加了。内容管理器安装在具有 4 个 CPU、8GB RAM 和 50GB 磁盘空间的虚拟化 Windows Server 2008 上。 Content Delivery 安装在具有相同规格的单独服务器上。
【问题讨论】：
-
我看到您正在从模板中发布项目。这很容易导致发布队列中有大量项目。会不会是你对出版商的要求太高了？您是否查看过用于渲染的线程数？
-
感谢您的回复。 “从模板内发布项目”是什么意思？每个页面都分配有相同的空白页面模板，即没有代码。该页面没有组件。输出的 html 页面是空白文件。我意识到发布 1000 页可能是一项相当繁重的任务，但我认为 CMS 系统应该能够处理一些事情。我认为主要问题是分配的内存似乎没有被释放。
-
对不起，我看错了你的问题。我以为 CoreService 代码的 sn-p 来自你的模板本身。
-
对了。该代码来自在我的 PC 上运行的调用核心服务 API 的外部 win 表单应用程序
-
您说“据我所知，多次调用和一次调用的结果实际上是相同的”。让我提醒您：如果您在一次调用中传递所有 id，那么您将创建一个包含 1000 个项目的发布事务。就像现在一样，您正在创建 1000 个发布事务，每个事务都有一个项目。由此产生的行为将完全不同。也就是说：我不知道你为什么会内存不足，但我也不认为像你这样限制和杀死进程是一种解决方案。我的建议是停止这样做并使用性能监视器。
标签： tridion tridion-2011