标签：深入exchange2013 反压 backpressure 反压警告
微软一直宣称Exchange 的传输引擎足够负担非常大量的邮件传输（EXTREMELY large volumes of messages）,但是在现实场景中，很多时候都会出现服务器的物理资源不够无法负担这么大量的出站与入站邮件量，换句话说微软的意思是俺设计的产品的底层逻辑足够健壮性能足够高，你再性能不行就是你硬件瓶颈了（笑）。比如一台MBX服务器可能被某一个源来的大量邮件耗费掉了非常多的可用内存，或者某些关键磁盘分区的空间近乎占满，这种情况下，Exchange就会启动反压机制来确保传输服务能够正常运转并且处理完成已经在队列中的邮件，反压机制会临时停止一些组件功能比如拒绝入站邮件以防止新的邮件进入队列，直到给Exchange造成的压力减轻为止，内存占用恢复正常，或者是磁盘空间恢复正常等等。Exchange才会再次开始启用这些被停止的功能组件。
以下我参考Exchange2013的Technet上的文档汇总了一张表格，表中之处了这些条件满足时可能会触发反压力措施：
条目 | 条件 |
邮件队列数据库所在磁盘的可用硬盘空间 | Exchange监视Queue文件夹所在磁盘分区的磁盘占用率，可以通过以下公式算出该条目高级别占用率的数值 100 * (硬盘全部容量 - 修正常数) /硬盘全部容量 修正常数的值为 500 MB。 然后，向下算出中级别和正常级别的数值：该公式的结果用所用硬盘空间占全部硬盘空间百分比的形式表示。中等级别硬盘使用率比高级别硬盘使用率低 2%。正常级别硬盘使用率比高级别硬盘使用率低 4%。向下四舍五入为最接近的整数。 |
邮件队列数据库事务日志的可用硬盘空间 | Exchange还会监视邮件队列数据库的事务日志文件所在磁盘的可用硬盘空间。同样的，可以通过以下公式计算出高级别的硬盘使用率： 100 * (硬盘全部容量 – 取小(5 GB, 3*DatabaseCheckPointDepthMax)) / 硬盘全部容量 其中DatabaseCheckPointDepthMax位于%ExchangeInstallPath%Bin\EdgeTransport.exe.config里，指代硬盘上允许存在的所有未提交的事务日志的总大小。 计算出高级之后，再向下推出中级与正常的使用率：默认情况下，中等级别硬盘使用率比高级别硬盘使用率低 2%。正常级别硬盘使用率比高级别硬盘使用率低 4%。 |
版本存储桶 | 在可将对邮件队列数据库的更改提交到事务日志之前，会将该更改列表保存在内存中。然后，会将该列表提交给邮件队列数据库自身。这些保存在内存中的未完成邮件队列数据库事务被称为 “版本存储桶”。版本存储桶数目可能会因出乎意料的大量传入邮件、垃圾邮件攻击、邮件队列数据库完整性问题或硬盘性能而增大到不可接受的数目。 三个级别阈值分别为高：200、中：120、正常：80 |
批处理点 | Exchange 开始接收邮件时，这些邮件会按批处理进行分组，然后准备用作版本存储桶。如果传入邮件包含较大的附件，可以将其分为多个批处理。正在处理的这些批处理称为 “批处理点”。未完成的批处理点数目可以超过设置的阈值，尤其是存在出乎意料的大量带有较大附件的传入邮件时。 三个级别阈值分别为：高：4000、中：2000、正常：1000 |
版本存储桶和批处理点的历史记录深度 | Exchange 保留版本存储桶和批处理点资源使用率的历史记录。如果资源使用率在特定数量的轮询间隔内没有下降到正常级别，称为历史记录深度，Exchange 将停止缓送延迟并开始拒绝传入邮件，直到资源使用率恢复正常。默认情况下，版本存储桶和批处理点的历史记录深度分别为 10 个和 300 个轮询间隔。 |
EdgeTransport.exe 进程使用的内存大小 | 总内存75%和1TB取小。 默认情况下，EdgeTransport.exe 文件的中等级别内存使用率为总物理内存的 73%，或为比高级别内存使用率低 2% 的值，选择二者中较小的值。EdgeTransport.exe 文件的正常级别内存使用率为总物理内存的 71%，或为比高级别内存使用率低 4% 的值，选择二者中较小的值。 |
EdgeTransport.exe 进程使用的内存大小的历史记录深度 | Exchange 保留 EdgeTransport.exe 进程的内存使用率的历史记录。如果使用率在特定数量的轮询间隔内没有下降到正常级别，称为历史记录深度，Exchange 将开始拒绝传入邮件，直到资源使用率恢复正常。默认情况下，EdgeTransport.exe 内存使用率的历史记录深度为 30 个轮询间隔。 |
所有进程使用的内存 | 默认情况下，全部进程的高级别内存使用率为总物理内存的 94%。此值并不包括硬盘上页面文件中可用的虚拟内存。 |
提交队列中的邮件数 | 三个级别阈值分别为：高：10000、中：4000、正常：2000 |
提交队列中的邮件数的历史记录深度 | Exchange 保留提交队列使用率的历史记录。如果提交队列使用率在特定数量的轮询间隔内没有下降到正常级别，称为历史记录深度，Exchange 将停止缓送延迟并开始拒绝传入邮件，直到提交队列使用率恢复正常。默认情况下，提交队列的历史记录深度为 300 个轮询间隔。 |
OK，基本上以上都可以概括为几点：可用磁盘空间，传输动作中的未提交到队列邮件数，提交队列中的邮件数量，总共的内存大小。
需要注意的是，启动反压并不代表Exchange就停止了接受入站SMTP连接，但是当一个SMTP连接建立之后，服务器会拒绝对端服务器的MAIL FROM命令，并且返回一个452 4.3.1（系统资源不足）的错误。日志里也会记载15004、15006、15007的MSExchangeTransport源日志条目。15004记录资源级别升高的条目（资源压力已从 Previous Utilization Level 增加到 Current Utilization Level。），15005会记录资源级别降低的条目（资源压力已从 Previous Utilization Level 降低到 Current Utilization Level。）15006和15007分别对应磁盘空间与内存空间。
反压只会作用在MBX服务器和边缘服务器上的传输服务，因为FET服务不会队列任何邮件。
下表汇总了一些MBX服务器上的组件在反压力启用时的行为，
资源等级 | 来自旧版传输服务器的连接 | 来自其他非Exchange服务器的连接 | 来自其他MBX服务器的store driver连接 | 分拣目录和重播目录提交 | 内部邮件流 |
中 | 允许 | 拒绝 | 允许 | 拒绝 | 正常传递 |
高 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | 停止 |
从表中可以看出，在中等级别的负载下，基本的邮件流能够正常运行，因为MBX服务器之间的store driver连接可以运行，但是它们会拒绝来自其他非Exchange的SMTP服务器的连接。随着压力增长到更高级别，该MBX服务器开始拒绝接受连接直到压力减少。表中没有提到的，有一些特定的操作会在特定组件面对压力时被执行，比如如果提交队列面对压力， Exchange 服务器将通过延迟确认传入邮件来开始限制传入连接。Exchange 将通过引入延迟 MAIL FROM 命令的缓送技术来降低入站邮件流的速率。如果提交队列压力情况继续存在，Exchange 将逐渐增加缓送延迟。在提交队列使用率恢复正常后，Exchange 将逐渐开始减少确认延迟并渐渐进入正常操作。默认情况下，Exchange 将在具有提交队列压力时开始将邮件确认延迟 10 秒钟。如果提交队列继续具有压力，延迟会以 5 秒的增量增加，最高为 55 秒。如果仍旧没有减轻压力，则拒绝入站邮件。这个缓送延迟也会作用在版本存储桶与批处理点面对压力之时。
另外在EdgeTransport.exe 进程使用的内存、所有进程使用的内存、提交队列中的邮件数三项任何一项为中等级别时候，都会启动强制垃圾收集。
在所有进程使用的内存、提交队列中的邮件数两项任何一项为高级别的时候，都会启动另外两项措施：邮件冻结、从内存强制刷新DNS缓存。
这里的邮件冻结是指删除内存中缓存的排队邮件的不必要元素的操作。为了提高性能，完成的邮件都缓存在内存中。因为邮件是从邮件队列数据库中直接读取的，所以删除内存中排队邮件的 MIME 内容可减少内存使用量，但会出现较高延迟。
反压力措施触发的默认条件值都存放在EdgeTransport.exe.config配置文件里，这些设置据微软所说都是经过大量实际场景测试（微软的IT场景与Technology
Adoption Program合作伙伴环境）得出的比较理想的值，所以他们会建议不要轻易修改这些值。当然，了解这些默认值，尝试出自己环境里的最优值也不是不可以，如果想要调整它们，请参考这里：EdgeTransport.exe.config 文件中的反压力配置选项：https://technet.microsoft.com/zh-CN/library/bb201658(v=exchg.150).aspx#File
OK，反压力我们就聊到这里。下一章开始又要分几次来跟大家深入探讨下Exchange2013中的邮件路由。
本文出自 “卡斯特梅的雨季” 博客，请务必保留此出处http://sodaxu.blog.51cto.com/8850288/1684080
标签：深入exchange2013 反压 backpressure 反压警告
原文地址：http://sodaxu.blog.51cto.com/8850288/1684080
