我在 51degrees 论坛上发布了这个帖子，因为它在那里没有得到太多的关注。
我继续将 51Degrees 的最新 NuGet 包版本实施到我们在工作中管理的站点中。(2.19.1.4) 我们正在尝试将本网站的移动视图管理纳入内部（目前由第三方完成）。所以我们唯一感兴趣的功能是检测。我们通过注释掉配置中的重定向元素来禁用重定向功能，并将日志记录级别修改为致命（日志位于 App_Data 文件夹中）。
据我们了解，这些是唯一需要的更改。这奏效了。我们可以根据 51degrees 提供的信息在桌面和移动设备之间切换布局视图。
在通过 DEV 和 QA 进行测试和推广时，我们注意到应用程序池中的内存消耗增加了，但没有什么是我们过度担心的。标准流量级别的应用程序池在 PROD 中消耗大约 230 MB 的内存。在高峰期它会飙升到 300 MB，所以没什么好担心的，尤其是考虑到我们做了相当多的 InProc 缓存。
截至周日，我们将 51degreees lite 升级为 PROD，但禁用了移动视图（我们在 QA 中也这样做了）。我们想看看它在 PROD 中的表现如何，以及它在实时环境中会对服务器产生什么样的影响。重申一下，QA 显示内存使用增加，但我们无法复制 PROD 负载和差异。
PROD 揭示了一些担忧。两个前端之一的应用程序池的内存消耗在一天中缓慢增长，直到晚上 11 点在应用程序池上达到 560MB 的峰值。另一个峰值为 490MB。
我们通过将其从现场移除、回收和再监控一天来确认问题已隔离到 51 度。应用程序池内存从未超过 300MB。
我们还通过 SciTech 的内存分析器运行了应用程序池以确认。结果显示 51Degrees 消耗了超出预期的大部分额外内存。（如果需要，我们可以在 QA 环境中再次运行这些测试。数字会更低，但它们会描绘出一幅图画）。
所以问题：
1）什么会导致这么大的内存消耗？虽然 500-600MB 的应用程序池并不是世界末日，但让我们的移动检测解决方案使我们的应用程序池大小增加一倍以上是令人担忧的。（虽然我们的网站不是流量最大的网站，但它确实收到了相当数量的请求）
2）我们可以应用任何设置来防止或减少内存消耗吗？理想情况下，我们希望将 51 度的内存消耗限制为仅加载产品和监控传入请求所需的内存。
感谢您的任何反馈。