我完全理解你在共享服务器上启用这类日志的顾虑——毕竟既要排查自己应用池莫名停止的问题，又不想给其他共存的应用拖后腿，这确实得仔细权衡清楚。下面我结合实际运维经验给你拆解下开销问题：

• 日志文件大小的可控性
  首先不用太担心日志会无限膨胀，Windows事件日志本身自带轮转管理机制：默认会设置最大文件大小（一般几十到几百MB，可手动调整），当日志达到上限时，会自动覆盖最旧的日志条目，或者自动归档到新文件。
  当然，如果你启用了详细日志字段（比如记录每个请求的所有请求头、POST表单数据），或者你的应用请求量极大，日志生成速度会快一些，但只要不是极端场景，磁盘占用还是在可控范围内的。建议初期先别开最详细的级别，够用就行。

• 对服务器性能的影响
  IIS写入事件日志的操作是异步批量进行的，不会对每个请求做同步阻塞写入，所以正常负载下，对应用的响应时间几乎没有感知。只有当服务器本身CPU或磁盘IO已经濒临满负荷时，额外的日志写入才可能带来轻微影响，但这种情况在共享服务器的正常运维中很少见。
  另外关键的一点：IIS支持站点/应用池级别的日志配置，你完全可以只针对自己的ASP.NET Web Forms应用开启这类日志，而不会影响共享服务器上的其他应用——千万别全局开启所有站点的日志，那才可能给其他租户带来不必要的开销。

• 实操建议

  1. 先临时启用，日志级别设为Warning或Error级别，这样既能捕捉到应用池停止这类异常事件，又不会产生大量冗余日志。
  2. 手动调整日志轮转策略：比如设置单日志文件最大100MB，满了自动覆盖旧日志，或者按天归档，把磁盘占用锁死在可接受的范围。
  3. 等排查出应用池停止的根因后，可以暂时关闭该日志，或者调整为只记录关键事件，减少长期运行的开销。

备注：内容来源于stack exchange，提问作者Tech with Thiru