Exchange反压保护机制导致内部邮件传送延迟

简介:

症状描述

用户反映发给公司内部的邮件,对方间歇性出现延迟20-30分钟接收的问题。登录Exchange集线器传输服务器后会发现有如下的日志警报: 
image 
1

 

原因分析

1. 该故障由Exchange一个名为“反压”的保护机制所引起。

2. 反压是 Microsoft Exchange 传输服务的一种系统资源监视功能。在运行 Microsoft Exchange Server 2007/2010集线器传输服务器角色或边缘传输服务器角色的上通常会使用这一功能。它将对重要的系统资源(如可用硬盘驱动器空间和可用内存)进行监视。如果系统资源使用率超出了指定限制,Exchange 服务器会停止接受新的连接和邮件。这样,便可防止过多地使用系统资源,并使 Exchange 服务器可以传送现有邮件。当系统资源使用率恢复到正常级别后,Exchange 服务器就可以接受新的连接和邮件。

3. 从事件日志可以看出是因为“版本存储桶”的数目增大到“”级别,从而导致以任何方式提交邮件。 
如果集线器传输服务器上的资源使用率级别为中等:

接受来自其他集线器传输服务器的传入简单邮件传输协议 (SMTP) 连接。
拒绝来自其他邮件服务器的传入 SMTP 连接。
存储驱动器继续接受来自邮箱服务器的邮件。
分拣目录和重播目录将停止处理邮件。

   如果集线器传输服务器上的资源使用率级别为高:
拒绝来自其他集线器传输服务器的传入 SMTP 连接。
拒绝来自其他邮件服务器的传入 SMTP 连接。
存储驱动器停止接受来自邮箱服务器的邮件。 

分拣目录和重播目录将停止处理邮件。

解决方案

方案1(增大触发阈值,推荐)

1. 分别登录Exchange集线器传输服务器和边缘传输服务器,备份Exchange安装目录D:\Program Files\Microsoft\Exchange Server\Bin下的EdgeTransport.exe.config文件

2. 打开EdgeTransport.exe.config文件,找到</appSettings>,在上面添加如下记录,增大版本存储桶”数目阈值,如图2所示: 
image 
2
 
<add key="VersionBucketsHighThreshold" value="3000" />  
(将“高”级别阈值设置为3000 
<add key="VersionBucketsMediumThreshold" value="2000" />(将“中”级别阈值设置为2000 
<add key="VersionBucketsNormalThreshold" value="1000" />(将“正常”级别阈值设置为1000

3. 修改完毕后重启一下“Microsoft Exchange传输”服务即可。

 

方案2(禁用“反压”功能,不推荐)

1. 分别登录Exchange集线器传输服务器和边缘传输服务器,备份Exchange安装目录D:\Program Files\Microsoft\Exchange Server\Bin下的EdgeTransport.exe.config文件

2. 打开EdgeTransport.exe.config文件,查找“EnableResourceMonitoring”字段,将: 
<add key="EnableResourceMonitoring" value="true" /> 
修改为: 
<add key="EnableResourceMonitoring" value="false" /> 
如图3所示 
image 
3

3. 修改完毕后重启一下“Microsoft Exchange传输”服务即可。



本文转自 jiating227 51CTO博客,原文链接:http://blog.51cto.com/jiating/745772

相关文章
|
1月前
|
消息中间件 监控 Java
RocketMQ 同步发送、异步发送和单向发送,如何选择?
本文详细分析了 RocketMQ 中同步发送、异步发送和单向发送三种消息发送方式的原理、优缺点及适用场景。同步发送可靠性高但延迟较大,适合订单系统等场景;异步发送非阻塞且延迟低,适用于实时数据处理等场景;单向发送高效但可靠性低,适用于日志收集等场景。文章还提供了示例代码和核心源码分析,帮助读者更好地理解每种发送方式的特点。
230 4
|
21天前
|
缓存 负载均衡 监控
解决邮件延迟问题
【10月更文挑战第21天】
|
2月前
|
网络协议 程序员 UED
如何确保单聊消息100%送达?揭秘消息可靠传输的核心机制!
哈喽,大家好!我是技术好朋友小米,今天聊聊单聊消息的可靠传输。通过TCP的超时、重传、确认机制,结合去重和离线消息优化,我们可以设计出高效、可靠的消息传输系统。希望今天的分享能给大家带来帮助!如果有问题,欢迎留言交流。
46 0
如何确保单聊消息100%送达?揭秘消息可靠传输的核心机制!
|
5月前
|
消息中间件 Serverless 网络性能优化
消息队列 MQ产品使用合集之客户端和服务器之间的保活心跳检测间隔是怎么设置的
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
6月前
|
监控 安全 持续交付
【专栏】Webhook是服务器主动发送事件通知的机制,打破传统客户端轮询模式,实现数据实时高效传递。
【4月更文挑战第29天】Webhook是服务器主动发送事件通知的机制,打破传统客户端轮询模式,实现数据实时高效传递。常用于持续集成部署、第三方服务集成、实时数据同步和监控告警。具有实时性、高效性和灵活性优势,但也面临安全风险和调试挑战。理解并善用Webhook能提升系统性能,广泛应用于现代软件开发和集成。
434 0
|
消息中间件 存储 缓存
RabbitMQ (HelloWord 消息应答 持久化 不公平分发 预取值)2
RabbitMQ (HelloWord 消息应答 持久化 不公平分发 预取值)2
70 0
|
消息中间件
RabbitMQ (HelloWord 消息应答 持久化 不公平分发 预取值)1
RabbitMQ (HelloWord 消息应答 持久化 不公平分发 预取值)1
69 0
|
消息中间件 存储 Kafka
MQ 学习日志(六) 保证消息的可靠性传输
消息的可靠性传输 简述
117 0
|
消息中间件 Java 数据库
RabbitMQ:第二章:Spring整合RabbitMQ(简单模式,广播模式,路由模式,通配符模式,消息可靠性投递,防止消息丢失,TTL,死信队列,延迟队列,消息积压,消息幂等性)
RabbitMQ:第二章:Spring整合RabbitMQ(简单模式,广播模式,路由模式,通配符模式,消息可靠性投递,防止消息丢失,TTL,死信队列,延迟队列,消息积压,消息幂等性)
384 0
RabbitMQ:第二章:Spring整合RabbitMQ(简单模式,广播模式,路由模式,通配符模式,消息可靠性投递,防止消息丢失,TTL,死信队列,延迟队列,消息积压,消息幂等性)
|
消息中间件 负载均衡 Java
延迟消息|学习笔记
快速学习延迟消息
135 0
延迟消息|学习笔记