内存泄漏实体框架
作者:互联网
当我将实体框架与SQL Server Compact Edition一起使用时,发生内存泄漏.我的情况:
我有一个大约600MByte的文件.我逐行阅读它,创建一个实体类并将其添加到SQL Server CE数据库中.内存由此快速增长. Gen 0 Collections计数器和Gen 2堆大小增长非常快(Process Explorer中的信息).如果我理解正确,第二代堆适用于大型物品.我认为我的实体类是一个大对象.因此,Entity Framework保存了我的对象,并且不释放它们.我已经尝试分离它们并调用GC.Collect(2),但它没有帮助.
首先,我读了这一行.然后在解析该行之后创建一个对象.然后将其添加到数据库.这是我的数据库代码:
DBEntities dbConnection = new DBEntities();
dbConnection.My_Table.AddObject(MyObjectCreatedFromTheLine);
dbConnection.SaveChanges();
// dbConnection.Detach(MyObjectCreatedFromTheLine);
// dbConnection.Dispose();
MyObjectCreatedFromTheLine = null;
dbConnection = null;
我还阅读到创建的实体类(MyObjectCreatedFromTheLine)属于DbContext.因此,我为每一行调用此代码,每次都创建一个新的上下文.
我究竟做错了什么?
解决方法:
我遇到了尝试使用实体框架将50,000条记录插入SQL数据库的问题.实体框架并不适合进行大量的批量操作(大量的插入或删除操作),因此我最终使用了System.Data.SqlClient.SqlBulkCopy库,该库效率更高,速度更快.我什至编写了下面的辅助函数来自动映射,因此不必手动构造SQL Insert语句. (它是边际类型独立的!我想).
基本上,工作流程是:IList< MyEntityType> ->数据表-> SqlBulkCopy
public static void BulkInsert<T>(string connection, string tableName, IList<T> list)
{
using (var bulkCopy = new SqlBulkCopy(connection, SqlBulkCopyOptions.KeepNulls))
{
bulkCopy.BatchSize = list.Count;
bulkCopy.DestinationTableName = tableName;
bulkCopy.BulkCopyTimeout = 3000;
var table = new DataTable();
var props = TypeDescriptor.GetProperties(typeof(T))
//Dirty hack to make sure we only have system data types
//i.e. filter out the relationships/collections
.Cast<PropertyDescriptor>()
.Where(propertyInfo => propertyInfo.PropertyType.Namespace.Equals("System"))
.ToArray();
foreach (var propertyInfo in props)
{
bulkCopy.ColumnMappings.Add(propertyInfo.Name, propertyInfo.Name);
table.Columns.Add(propertyInfo.Name, Nullable.GetUnderlyingType(propertyInfo.PropertyType) ?? propertyInfo.PropertyType);
}
var values = new object[props.Length];
foreach (var item in list)
{
for (var i = 0; i < values.Length; i++)
{
values[i] = props[i].GetValue(item);
}
table.Rows.Add(values);
}
bulkCopy.WriteToServer(table);
}
}
在我的示例中,我从15-20分钟插入到不到一分钟.
标签:sql-server-ce,entity-framework-4,c,net,entity-framework 来源: https://codeday.me/bug/20191101/1981055.html