我在IIS 7.5上托管了RESTful WCF服务。当调用某些操作时，它几乎立即返回，但是启动一个复杂的任务，处理组合并在内存中打开大文件。在几次请求之后，应用程序池正在使用大约50％的内存，尽管任务已经完成。 IIS池什么时候回收内存？我试着打电话给GC.Collect()，但什么都没发生。有没有办法分析像这样的应用程序？我尝试了几个分析器，但它们只显示.NET类，IIS用它来处理请求本身。
答案 0 :(得分：3)
工作进程本身不会自行向操作系统释放内存。您可以将进程设置为按计划进行回收 - 这会重新启动进程释放内存而不会干扰正在运行的请求。
你可能不应该这样做 - 基本上.net持有内存以避免为以后的请求重新分配它。内存可在WCF进程中重用，如果未使用内存，操作系统会将其分页并允许在其他进程需要时重用它。有关详细信息，请参阅Answer to When is memory, allocated by .NET process, released back to Windows。
答案 1 :(得分：3)
长时间运行的任务通常不适合Web应用程序，因为它们会超时/挂起网站/ API的响应性 是否可以将后台任务配置为以异步方式运行IIS站点？因此，您可以将这些缓慢的任务推送到队列中并在后台处理它们
我认为这个过程中的内存使用情况是一个问题，但并不能说明整个故事，到目前为止您设法分析了什么？你有未闭合的联系吗？您是否正在创建多个未被有效处理的类的实例？我想查看调用执行计划的内容而不是内存使用情况，因为它可能会引导您更多地调用项目所在的位置
当你说50％的记忆我们在mb中实际谈论了多少？当它不需要放弃RAM时，IIS可能有点贪婪/懒惰
答案 2 :(得分：1)
我有几乎类似的问题，我使用Castle.Windsor作为IoC容器解决了它，将svc客户端类添加到带有Transient Scope的容器中，最后，我用以下内容装饰了svc类： [ServiceBehavior（InstanceContextMode = InstanceContextMode.PerCall）]。
所有其他依赖绑定都添加了Transient Livestyle，从而使它们依赖于它们的实例化器。我不确定这会对您的情况有所帮助，因为您使用大文件，但如果其他任何事情都失败了，请尝试在大多数内存容器类上实现IDisposable，并检查是否应该调用Dispose。
希望有所帮助！