ASP.NET内存管理技术

Question

我们有几个使用ASP.NET和DevExpress ASPxGridView组件的不同项目。在整个这些项目的开发过程中，已经使用了几种数据绑定技术，现在我们发现其中一些项目正在耗尽服务器上的所有内存。

最初，我们使用一个调用存储过程并将DataSet绑定到gridview，但是在DX建议中，将其修改为一个ObjectDataSource并创建了一个对象，最终对该数据库使用Linq语句并返回一个然后绑定的对象的通用列表。

不幸的是，这并不能解决手头的问题。我们仍然注意到大量的内存被吃掉了，我正在努力解决这个问题。在运行RedGate内存分析器时，我注意到有很多字符串，RuntimeTypeHandles以及每次我们重新绑定到网格时创建的对象实例。

DataBind在加载页面时完成，网格在排序时使用回传，但这会导致MB的内存在每个绑定上泄漏，所以我想知道我可以使用哪些技术/管理对象的最佳做法我们有控制权？我已经在数据对象中实现了IDisposable，处理了linq上下文并将任何其他对象设置为null，但似乎没有什么区别。我似乎是在每次调用时创建一个数据对象的实例，甚至调用dispose也没有什么区别。

Answer 1

哇，很多管道和移动部件在那里。

是否可以缩小一点？也就是说，你能剥离页面上的东西，看看它是如何执行的？

原谅这一点，但是当你说'泄漏记忆'你是什么意思，你怎么知道？ GC是'懒惰'的，在有压力之前不会做任何事情。这是一件好事，但它也意味着内存可能会积累，直到需要收集，然后你可能会发现它释放了很多。由于这个原因，内存轮廓仪通常看起来像锯齿。

如何存储网格数据以使分页工作？我已经看到数据集在viewstate中持续存在，这意味着数据会随着网格一起发送到客户端。如果您在回页面加载时再次查询，那么您在那里浪费了大量空间。

另一个常见问题是事件订阅会使大对象比他们应该活动的时间更长。实际上，我看到代码将数据网格放置在会话状态下，只要会话保持活动状态。每回发生一次又一次，直到噗噗。在这种情况下，GC无法帮助我们确保物体确实仍然处于“使用中”状态。

因此，尽量简化 - 关闭排序，摆脱第三方控制，使用更小的数据集等。使用内存分析器以及让服务器承受压力的东西，测量这种情况。如果你发现没有“泄漏”，那么开始添加东西，看看它何时出现故障。

Answer 2

您可能每次都将过多的数据返回到您的iis服务器。请记住，使用标准linq数据源和devexpress网格，每次您对排序或分页或任何其他回调进行回调时，整个数据都会加载到内存中，然后进行排序和分页。

这意味着如果您正在加载大量的数据，您将很容易浪费服务器内存。想想你可能有很多用户打开同一页面，这会为每个用户加载内存中的全部数据，而GC可能没有足够的时间来释放所有这些东西。

DevExpress为此提供LinqServerModeDataSource，它可以完成数据服务器中的所有分页和排序。

如果您不能使用它，请尝试通过过滤来检索一组较小的数据。