缩放 Azure 角色时，实例化 DCOM 对象有时会挂起

Posted 2023-02-16

【中文标题】缩放 Azure 角色时，实例化 DCOM 对象有时会挂起

【英文标题】：Instantiating a DCOM object sometimes hangs when scaling an Azure role

【发布时间】：2012-06-19 09:27:45

【问题描述】：

在我的 Azure 角色启动代码中，我实例化了一个 DCOM 对象以确保它可以被实例化，然后立即释放它，因为此时我并不真正需要它。

我在一个单独的线程中执行此操作，该线程实际上 news 对应的 C# RCW 类和主线程 Thread.Join()s 具有 30 秒超时的线程。如果在Thread.Join() 返回后线程仍在运行，这意味着创建 DCOM 对象需要很长时间，因此调用Thread.Abort() 并重新启动角色。 30 秒应该足够了 - 该对象是轻量级的，并且在实例化时不会做任何耗时的事情。

在我尝试大幅扩展我的服务之前，该代码运行良好。我要求支持取消计算核心配额并尝试扩展到 100（一百）个实例。

现在大多数实例都可以正常启动，但其中一些实例正面临上述情况 - DCOM 对象创建时间过长，因此代码抛出异常导致角色重新启动。

我重复了几次测试。一旦我要求扩大几十个实例，问题就会在一些新启动的实例中重现。由于所有实例都是统一的，我不知道是什么导致了这种行为。

仅在某些情况下 DCOM 对象需要这么长时间的原因可能是什么？

【问题讨论】：

您可能需要分享更多内容，但这听起来确实像是一种竞争条件（或其他类型的计时错误）。您运行的实例越多，您在代码中遇到竞争条件的机会就越大。我不希望它是关于“一些实例”，而是关于“有时我执行这段代码”。

@smarx：看起来这是一般的“一切都很缓慢”的情况 - 我已经添加了一个答案。

【参考方案1】：

到目前为止，我的研究表明，当我扩大大量实例时，某些实例在开始时会相当缓慢，尤其是在 IO 密集型操作方面。我认为这是因为运行 VM 的主机（8 核硬件服务器）正在做一些繁重的事情，因此对 IO 的竞争很激烈。在这些情况下，实例化一个通常需要大约 1 秒的 DCOM 对象可能需要长达 40 秒，而我的超时时间应该会增加。