65.9K
CodeProject 正在变化。 阅读更多。
Home

BizTalk 2006 R2 - 节流 - Perfmon 参数 - 我的经验

starIconstarIcon
emptyStarIcon
starIcon
emptyStarIconemptyStarIcon

2.05/5 (5投票s)

2008年1月15日

CPOL

4分钟阅读

viewsIcon

25708

BizTalk 2006 R2 - 节流 - Perfmon 参数 - 我的经验

BizTalk 2006 R2 - 节流 - Perfmon 参数 - 我的经验



突发新闻:这些天……“时间杀手博士”花费大量时间来理解和实现最佳节流场景:-)。

让我回到官方语言。几天前,我在我们的 BizTalk 环境中看到了大量的节流。我的热情促使我进一步探索节流机制。让我抓住机会记录一些整理好的内容。

过去几周,我发现我的 BizTalk 环境突然面临异常的节流行为,因此我试图找出 BizTalk 环境中节流状态的根本原因。

该环境在高峰处理时段面临大量的消息传递节流,由于传递节流状态和延迟,我们的整个环境都停滞了。在此事件之后,我开始非常认真地对待这个功能,现在正在深入研究与之相关的许多内容,在本文中,我将分享我的经验以及我在阅读了许多书籍、文章和 MS-KB 后获得的理解。

我们所有的 BizTalk 专业人士都了解入站消息处理以及 BizTalk 内部组件如何负责入站消息管理。简而言之,如果我想解释“入站消息”这个词,那么我可以这样说:“指向消息框的消息”是入站消息,在 BizTalk 中,消息框是任何环境或实现的“心脏”。我们遇到了消息发布率不均衡的问题,我注意到在我们的环境中,与传出消息(这里传出意味着订阅消息框,我们谈论的是传递)相比,传入消息率非常高,结果是内存中消息的数量在增加。BizTalk 识别到了,我们的环境进入了节流状态,但节流仍然未能使系统稳定并使其恢复到稳定状态。由于消息量非常大且传出速率较低,大量消息正在等待处理。我们看到处理过程中有近 300-700 秒的延迟。最终,噩梦成真了 :-0,并且“无服务天数 1”计数器需要重置。我想传达的是,在设置任何主机时,都需要为节流设置优化的配置参数。我将“必须”建议为高峰时段处理的关键接口设置一组配置良好且经过计划的主机。我不想让我的文章变成实现设计,但我想回到节流场景。



在本文中,我想重点介绍 perfmon 计数器、一些重要的比率和节流状态。

让我们先深入研究一些状态计数器,状态计数器显示了您在监控环境下当前情况的状态。BizTalk 2006/R2 提供了非常有用的 perfmon 状态计数器。

一些高级(*)计数器,如高数据库会话、高数据库大小、高进程中消息计数、高消息传递速率、高进程内存、高系统内存、高线程计数,所有这些计数器都通过显示 0 或 1 的值来表示状态,其中 1 表示相应的关注区域已超过配置的或警告级别。这些显示了非常丰富的信息,应该在您的 Biztalk 环境中进行监控。

进程中消息计数(In-process message count)和活动实例计数(Active instance count)是两个消息队列计数器,它们显示了已传递到 XLANG 引擎或出站消息引擎但尚未处理的内存中消息的数量,以及分别指代 EPM 或 XLANG 引擎的内存中处于活动状态的实例。

专门的消息传递计数器,如消息传递延迟(毫秒)(Message delivery delay (ms))、消息传递传入速率(Message delivery incoming rate)、消息传递传出速率(Message delivery outgoing rate)、消息传递节流状态(Message delivery throttling state)、消息传递节流状态持续时间(Message delivery throttling state duration)、消息传递节流用户覆盖(Message delivery throttling user override)。在高峰处理期间,应定期监控所有这些 perfmon 计数器,以了解您环境的行为和即将出现的模式,从而理解并防止故障。

消息传递延迟(毫秒):对每个消息发布批次施加的当前延迟(毫秒)(如果消息发布被节流并且批次未被豁免节流,则适用)。

消息发布传入速率:在给定的采样间隔内,每秒发送到数据库进行发布的平均消息数量。

消息发布传出速率:在给定的采样间隔内,实际发布到数据库的平均消息数量(每秒)。

消息发布节流状态
  • 0:未节流
  • 2:由于消息发布速率不平衡(输入速率超过输出速率)而节流
  • 4:由于进程内存压力而节流
  • 5:由于系统内存压力而节流
  • 6:由于数据库增长而节流
  • 8:由于会话计数过高而节流
  • 9:由于线程计数过高而节流
  • 11:由于发布上的用户覆盖而节流
消息发布节流状态持续时间:系统进入此状态以来经过的秒数。如果主机正在节流,则表示已节流多长时间;如果未节流,则表示自应用节流以来经过了多长时间。

我想在图表中展示一些 perfmon 数据和计数器的基本示例。



我将在我接下来的文章中探讨消息发布节流状态。

感谢您在文章中“忍受”我。您的宝贵反馈和建议欢迎发送至 nilayparikh@gmail.com

同一博客上发布的其他相关文章。
1. BizTalk Server 2006 / R2 节流机制

© . All rights reserved.