我们有一个MVC应用程序,每天流量约为800个用户,最近我们发现我们的应用程序池自行停止了。转到日志我们发现了MemoryOutOfException。我们无法弄清楚为什么会发生这种情况,所以我们进行了代码审查。在代码审查期间,我们发现我们有静态类,静态方法/扩展方法。我们没有任何静态变量,我们正在使用block来处理DbContext。 那么我们的静态类/静态方法可能是内存问题的原因吗?
如何在静态方法和类中创建实例?它们是由GC收集的吗?
请建议我们还可以做些什么来解决问题。
修改 很抱歉不共享任何代码。 我想了解Web应用程序中静态类的生命周期。如果我正在做带内存的复杂操作,它们会造成问题吗?
例如,如果我将我的Domain模型转换为静态类中的View Model,如下所示:
public static class PersonTranslator{
public static PersonVM (this Person p)
{
return new PersonVM{
Name = p.Name,
//etc...
//lots of property here
}
}
}
这是一个好习惯还是我应该使用正常的课而不是去 扩展方法。像这样的代码会产生问题吗?
由于
编辑2: 我们的db上下文在基类中实现,所有数据访问类都是从它中解脱出来的。我认为(我可能错了)这里出了问题。
public class DataAccessBase : IDisposable
{
protected ApplicationDataContext dataContext = null;
public DataAccessBase()
{
dataContext = new ApplicationDataContext();
}
public DataAccessBase(ApplicationDataContext dataContext)
{
if (dataContext == null)
dataContext = new ApplicationDataContext();
this.dataContext = dataContext;
}
~DataAccessBase()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// The bulk of the clean-up code is implemented in Dispose(bool)
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// free managed resources
}
// get rid of unmanaged resources
if (dataContext != null)
{
dataContext.Dispose();
}
}
}
答案 0 :(得分:0)
坦率地说,这可能是任何事情:
此时,我建议使用性能向导分析您的应用程序。通常情况下,您可以在生产之前完成此操作并为您的应用程序进行检测,因为您还可以决定应用程序需要的服务器/ VM大小?
.NET内存分配让您深入了解内存管理 你的应用程序,因为它分析内存中的每个对象 创建垃圾收集。显示器可以有两种不同的工作方式 方法。第一个也是影响较小的是通过抽样。它也可以 更深入地了解添加代码的工具 进入二进制文件以跟踪内存工作。
您还可以考虑在服务器上使用Performance Counters和perfmon。至少你应该在AppPool被删除之前收到警报。以80%的容量为例。
甚至可能没有"代码"问题。您可能只是低估了运行站点所需的资源类型(考虑增长模式),因为如上所述,如果没有性能分析预生产,它可能只是猜测您实际需要什么。