實體框架和並行

我有一個接收週期數據轉儲（XML文件），然後導入到使用實體框架5（代碼優先）現有數據庫的應用程序。導入通過EF5而不是BULK INSERT或BCP發生，因爲必須應用已存在於實體中的業務規則。

處理似乎在應用程序本身的CPU綁定中（極快的啓用寫緩存的磁盤IO子系統在整個過程中顯示幾乎爲零的磁盤等待時間，並且SQL Server顯示CPU時間不超過8％-10％）。

爲了提高效率，我建了一個pipeline using TPL Dataflow與組件：

Read & Parse XML file 
     | 
     V 
Create entities from XML Node 
     | 
     V 
Batch entities (BatchBlock, currently n=200) 
     | 
     V 
Create new DbContext/insert batched entities/ctx.SaveChanges()

我看到這樣的性能大幅提高，但不能得到上述約60％的CPU。

分析

懷疑某種資源爭用的，我跑使用VS2012 Profiler的資源爭用數據（併發）模式的過程。

分析器顯示52％的標記爲Handle 2的資源爭用。在鑽井，我看到的方法負責創建最爭2是

System.Data.Entity.Internal.InternalContext.SaveChanges()

第二位，約40％爲多爭的調用SaveChanges（），是

System.Data.Entity.DbSet`1.Add(!0)

問題

我怎樣才能找出手柄2真的是（E 。G。 TPL的一部分，EF的一部分）？
EF節制調用來將DbContext實例與單獨的線程分開嗎？似乎有一個他們正在爭奪的共享資源。
在這種情況下，我可以做些什麼來提高並行度？

UPDATE

有問題的運行，爲調用的SaveChanges設置爲12任務的最大並行度（我嘗試過各種價值觀，包括在以前運行無界）。

更新2

微軟的EF團隊提供反饋。查看我的答案獲取摘要。

來源

2012-11-01 Eric J.

你確定你是不是等待的池連接？您是否嘗試過讓連接池大小更大？ – Maess

@Maess：對於有問題的運行，我將最大並行度設置爲12.如果我理解正確，連接池的默認最大大小爲100.但是，我會嘗試將其明確設置得更高。 –

@Maess：Perfmon顯示只有11個邏輯連接和11個用戶連接到SQL實例，遠遠低於連接池限制。 –

以下總結了我在此問題上與實體框架團隊的交互。如果有更多信息可用，我會更新答案

此問題可以在Microsoft重現。
句柄爭用與網絡I/O（甚至在本地主機上使用SQL Server）相關。特別是，System.Data.dll中的網絡I/O的讀取緩衝區存在爭用。
EF團隊現在正在與SQL連接團隊合作，以更好地理解問題。
微軟目前還沒有關於如何最小化此爭用的影響的指導。

UPDATE

這個問題現在正在跟蹤CodePlex上：

http://entityframework.codeplex.com/workitem/636?PendingVoteId=636

來源

2012-11-12 19:24:39

非常感謝Eric。我很感興趣，因爲我有一個類似的場景。我們是否在connect.microsoft.com上有這個問題，以便我們追蹤其進展？ – Dodd

@Dodd：它現在在Codeplex上被追蹤，因爲EF現在是開源的（但仍由微軟的團隊工作）。添加了鏈接。 –

實體框架和並行

回答

相關問題