在线程中用 OracleBulkCopy 导至 CPU 百分百

抓取到的数据, 要批量写数据到 ORACLE , 一开始是用的EF, 处理速度很慢.

主要表现在验证数据上(db.GetValidationErrors), 每分钟才能写 1000条不到.

换成 EnterpriceLibrary.Validation (Validation.Validate) 后, 验证速度大增, 1000条只需几秒钟.

但是整体速度还是慢, 是因为每条数据都被EF转换为一个INSERT语句.

 

我花了一些时间用 OracleBulkCopy (需要引用客户端下面的 Oracle.DataAccess.dll ) 重写了这部份的逻辑, 1000条写到写ORACLE中也不过几秒时间, 直接从牛车跨越到高铁时代.

 

 1         private void BulkCopy(string connStr, DataTable dt, string tblName) { 

 2             if (dt.Rows.Count > 0) { 

 3                 using (var bc = new OracleBulkCopy(connStr)) { 

 4                     bc.DestinationTableName = tblName; 

 5                     foreach (DataColumn col in dt.Columns) { 

 6                         bc.ColumnMappings.Add(col.ColumnName, col.ColumnName); 

 7                     } 

 8                     bc.WriteToServer(dt); 

 9                 } 

10             } 

11         }

connStr 是 ORACLE 的连接字符串, tblName 是目标表的表名.

 1        /// <summary> 

 2         /// 将 List 转换为 DataTable, 只针对 T 中 的 public Property 

 3         /// </summary> 

 4         /// <typeparam name="T"></typeparam> 

 5         /// <param name="list"></param> 

 6         public static DataTable ToDataTable<T>(this List<T> list) where T : class { 

 7             if (list == null) 

 8                 return null; 

 9 

10 

11             Type type = typeof(T); 

12             var ps = type.GetProperties().Where(p => p.CanWrite && (p.PropertyType.IsValueType || p.PropertyType.IsPrimitive || p.PropertyType == typeof(String))); 

13             Type targetType; 

14             NullableConverter nullableConvert; 

15             List<DataColumn> cols = new List<DataColumn>(); 

16             foreach (var p in ps) { 

17                 if (p.PropertyType.IsGenericType && p.PropertyType.GetGenericTypeDefinition().Equals(typeof(Nullable<>))) { 

18                     nullableConvert = new NullableConverter(p.PropertyType); 

19                     targetType = nullableConvert.UnderlyingType; 

20                     cols.Add(new DataColumn(p.Name, targetType)); 

21                 } else { 

22                     cols.Add(new DataColumn(p.Name, p.PropertyType)); 

23                 } 

24             } 

25 

26 

27             DataTable dt = new DataTable(); 

28             dt.Columns.AddRange(cols.ToArray()); 

29 

30 

31             list.ForEach((l) => { 

32                 List<object> objs = new List<object>(); 

33                 objs.AddRange(ps.Select(p => p.GetValue(l, null))); 

34                 dt.Rows.Add(objs.ToArray()); 

35             }); 

36 

37 

38             return dt; 

39         } 

这段代码是我几年前用存储过程的时代写的, 现在还能用上.

只将T中的可写的 值类型, 基元类型 和字符串映射到 DataTable 中.

因为 EF 生成的实体类中, 导航属性并不是于数据库中的字段.

CLR 中的基元类型有:

Boolean 、 Byte 、 SByte 、 Int16 、 UInt16 、 Int32 、 UInt32 、 Int64 、 UInt64 、 IntPtr 、 UIntPtr 、 Char 、 Double  和  Single 。 

https://msdn.microsoft.com/zh-cn/library/system.type.isprimitive.aspx 

 

String 不是基元类型, 而且是地址引用的, 但它是一个特殊.

除 字符串,基元类型,值类型的属性, 我还真找不出来哪个可以映射到数据库中.

 

本地调试没问题后,放到服务器上, CPU居然高居不下.

生成DUMP文件, 用 WinDbg 查看: 

 

0:000> .load sos.dll 

0:000> !threadpool 

CPU utilization: 96% 

Worker Thread: Total: 0 Running: 0 Idle: 0 MaxLimit: 32767 MinLimit: 3 

Work Request in Queue: 0 

-------------------------------------- 

Number of Timers: 0 

-------------------------------------- 

Completion Port Thread:Total: 1 Free: 1 MaxFree: 6 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 3 

CPU 使用率 96% 

杳看线程执行时间: 

0:000> !runaway 

 User Mode Time 

  Thread       Time 

  21:13dc      0 days 0:39:58.140 

  24:13d4      0 days 0:08:41.750 

  27:11ac      0 days 0:01:29.906 

   5:1250      0 days 0:00:18.796 

查看21号线程的堆栈:

~21s

!clrstack

OS Thread Id: 0x13dc (21) 

Child SP               IP Call Site 

000000002595e7f8 00000000777e85d7 [HelperMethodFrame: 000000002595e7f8]  

000000002595e910 000007fe9482b688 *** ERROR: Module load completed but symbols could not be loaded for Oracle.DataAccess.dll 

Oracle.DataAccess.Client.OracleTuningAgent.DoScan() 

000000002595e950 000007fe9481d28f Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction() 

000000002595e9c0 000007fef0bdd0b5 *** WARNING: Unable to verify checksum for mscorlib.ni.dll 

System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 

000000002595eb20 000007fef0bdce19 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 

000000002595eb50 000007fef0bdcdd7 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 

000000002595eba0 000007fef0b50301 System.Threading.ThreadHelper.ThreadStart() 

000000002595eeb8 000007fef1c7ffe3 [GCFrame: 000000002595eeb8]  

000000002595f1e8 000007fef1c7ffe3 [DebuggerU2MCatchHandlerFrame: 000000002595f1e8]  

000000002595f3c8 000007fef1c7ffe3 [ContextTransitionFrame: 000000002595f3c8]  

000000002595f5b8 000007fef1c7ffe3 [DebuggerU2MCatchHandlerFrame: 000000002595f5b8]  

 

接连查了几个线程的堆栈, 都是这个: 
Oracle.DataAccess.Client.OracleTuningAgent.XXX 

 

搜了一下 Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction : 
http://stackoverflow.com/questions/2782169/oracle-data-provider-pegs-iis-worker-process-when-web-site-is-stopped 

This has been fixed in 11.2.0.2 and in Patch 9966926 ORACLE 11G 11.2.0.1 PATCH 5 BUG FOR WINDOWS (64-BIT AMD64 AND INTEL EM64T). 
Or WORKAROUND: is to disable self tuning by adding "Self Tuning=false" to the connection string. 

看不大懂, 但是里面提及了 Oracle.DataAccess.Client 的版本. 
这个DLL 我是从客户端: 11.2.0 中考出来的, 版本是: 2.112.1.0  

Self Tuning 从 VS 的数据库连接管理中, 可以看出它的意思是:

对连接启用或禁用自我优化

 

具体有什么功效, 什么影响没有去查证. 先不管.

 

从ORACLE上下载了一个 ODAC121021_x64 (客户端) , 200多M, 安装后, ODP.NET 目录下面有两个文件夹 2.X 和 4

引用 4 下面的 Oracle.DataAccess.dll (版本: 4.121.2.0),  本地运行也是毫无压力,很完美.

拿这个DLL直接替换到服务器上, 结果 CPU 是不高了, 但是连写都不写了! 

不知道是不是需要安装最新的客户端, 没有试验. 也不能去实验, 因为基础环境一改,会影响一大片.

 

 

索性还拿 2.x 的版本, 在连接字符串中加入 Self Tunning = False, 放到服务器上, 数据正常写入了, CPU也不高了!