已经碰见了好几次,在Exchange2007的场景中，前端角色所在服务器的w3wp.exe进程总是占用大量内存，以至于触发反压组件，停止了正常的邮件流投递，造成业务中断。
终于下决心查一下到底问题问题出在哪块，虽然Exchange 2007一直在出各种SP和rollUP声称解决了该问题（SP2，或者是SP3 rollup10）。但是打过补丁之后该吃内存的还是吃内存，该报警反压的还是报警反压。
打开任务管理器，查看里面选择列把PID勾上，就可以看到PID为6560的w3wp进程占用了较大量的内存。
然后打开命令行，如果是windows server 2003的话，输入iisapp ，就可以获得所有IIS应用程序池对应的进程PID值，从图中可以看到
PID6560的应用程序池对应的是MSExchangeSyncAppPool。
如果是windows 2008 （IIS7） 及以上，则需要输入%windir%system32inetsrvappcmd.exe list wp来查看对应的应用程序池
打开IIS管理器，定位到该应用程序池，单击右键选择属性，接着对其内存使用进行相应的限制即可。
如图，该服务器物理内存配置不高，所以限制为2GB，以留给IIS本身足够的时间来进行自动回收。
限制完毕之后，反压日志明显减少。
该应用程序进程池对应的是Exchange的ActiveSync组件，仔细想想在Exchange 2007刚发布的年代，有多少人用手机ActiveSync组件去收发邮件，所以产品上出现性能问题也正常，在后面的10和13中这问题就出的不多了。
所以彻底解决问题的方法还是1、升级。2、加内存……
最后附上一个用于排查 Exchange ActiveSync 问题的脚本
http://blogs.technet.com/b/exchange_chs/archive/2012/02/24/exchange-activesync.aspx
这个脚本的用途是通过该Exchange ActiveSync应用程序池的日志，log parser2.0工具以及powershell2.0来分析所有的使用移动设备通过EAS服务连接Exchange服务器的状态。
可以获取到每台设备每天连接了多少次等信息，在这些信息中，如果有每天超过1000次连接的设备，那在产品组看来这就是非正常的高频度连接。同时也可以借由此脚本来发现IIS各时间段的压力和性能指标。