Iterowanie poprzez IQueryable z foreach skutkuje wyjątkiem braku pamięci

Question

Powtarzam przez małą tablicę (~ 10GB) z foreach/IQueryable i LINQ-SQL. Wygląda mniej więcej tak:

using (var conn = new DbEntities() { CommandTimeout = 600*100}) 
{ 
    var dtable = conn.DailyResults.Where(dr => dr.DailyTransactionTypeID == 1); 
    foreach (var dailyResult in dtable) 
    { 
     //Math here, results stored in-memory, but this table is very small. 
     //At the very least compared to stuff I already have in memory. :) 
    } 
} 

Visual Studio debugger rzuca out-of wyjątkiem pamięci po krótkim czasie na bazie pętli foreach. Zakładam, że wiersze tabeli dtable nie są przepłukiwane. Co robić?

Answer 1

IQueryable<DailyResult> dtable będzie próbował załadować cały wynik zapytania do pamięci, gdy wyliczone ... przed wszelkimi iteracji pętli foreach. Nie ładuje on jednego wiersza podczas iteracji pętli foreach. Jeśli chcesz tego zachowania, użyj DataReader.

Answer 2

Zadzwoń do 10GB mniej? masz dobre poczucie humoru!

Można rozważyć ładowanie wierszy w porcjach, np. Stronicowanie.

conn.DailyResults.Where(dr => dr.DailyTransactionTypeID == 1).Skip(x).Take(y); 

Answer 3

Używanie programu DataReader jest krokiem do tyłu, chyba że istnieje sposób na użycie go w LINQ. Myślałem, że próbujemy uciec od ADO.

Rozwiązanie zasugerowane powyżej działa, ale jest naprawdę brzydkie. Tu jest mój kodu:

int iTake = 40000; 
int iSkip = 0; 
int iLoop; 
ent.CommandTimeout = 6000; 
while (true) 
{ 
    iLoop = 0; 
    IQueryable<viewClaimsBInfo> iInfo = (from q in ent.viewClaimsBInfo 
             where q.WorkDate >= dtStart && 
             q.WorkDate <= dtEnd 
             orderby q.WorkDate 
             select q) 
             .Skip(iSkip).Take(iTake); 
    foreach (viewClaimsBInfo qInfo in iInfo) 
    { 
    iLoop++; 
    if (lstClerk.Contains(qInfo.Clerk.Substring(0, 3))) 
    { 
      /// Various processing.... 
    } 
    } 
    if (iLoop < iTake) 
    break; 
    iSkip += iTake; 
} 

Widać, że muszę sprawdzić, że zabrakło zapisów, ponieważ pętla foreach zakończy się 40000 rekordów. Niedobrze.

Zaktualizowano 6/10/2011: Nawet to nie działa. Przy 2 000 000 rekordów otrzymuję wyjątek poza pamięcią. Jest również niesamowicie powolny. Kiedy zmodyfikowałem go, aby używał OleDB, działał przez około 15 sekund (w przeciwieństwie do 10+ minut) i nie zabrakło mu pamięci. Czy ktoś ma rozwiązanie LINQ, które działa i działa szybko?

Answer 4

Sugerowałbym użycie SQL zamiast modyfikacji tych danych.

Answer 5

Zastosowanie .AsNoTracking() - mówi DbEntities nie buforować pobrane wiersze

using (var conn = new DbEntities() { CommandTimeout = 600*100}) 
{ 
    var dtable = conn.DailyResults 
       .AsNoTracking()  // <<<<<<<<<<<<<< 
       .Where(dr => dr.DailyTransactionTypeID == 1); 
    foreach (var dailyResult in dtable) 
    { 
     //Math here, results stored in-memory, but this table is very small. 
     //At the very least compared to stuff I already have in memory. :) 
    } 
}