Hallo Gemeinde,
habe, in der Hoffnung auf einen Performancegewinn, von XP auf Win7 umgestellt und den Arbeitsspeicher auf 16GB erweitert.
Bei dem Projekt werden Daten aus einer Datenbank gelesen und in aggregierter Form in eine neue Datenbank geschaufelt(SQL2008R2).
Beim Import ist jedoch keine Steigerung der Verarbeitungsgeschwindigkeit festzustellen.
Welche Ursachen kann es dafür geben?
Oder ist der SQL Server die Engstelle?
Viele Grüße
Jürgen
Man muß nichts wissen,
man muß nur wissen wer es wissen könnte
oder wo es steht😉
Hallo bigeddie,
worauf gründete sich denn deine Hoffnung auf einen Performancegewinn?
Wenn z.B. der Speicher auch bisher ausreichte, bringt mehr Speicher nicht mehr.
Und der Wechsel des Betriebssystems bringt abhängig von der konkreten Aufgabe nicht automatisch mehr Performance.
herbivore
Hi herbivore,
als das Projekt noch unter XP gefahren habe hatte ich immer einen SWAP von 2-3GB, welchen ich jetzt unter Win7 nicht habe und ich dachte die Performance würde darunter leiden.
Viele Grüße
Jürgen
Man muß nichts wissen,
man muß nur wissen wer es wissen könnte
oder wo es steht😉
Die Frage ist auch, wie ihr die Daten in die andere DB schaufelt.
Per Insert wäre es kein wundern wenn es sau lange dauert.
Dafür dann SqlBulkCopy verwenden.
Auch ist die Frage wie der Server mit DB A und DB B aussieht.
Wenn dies nur langsame Server sind, kann man eh nicht viel machen.
Eine Umstelling von OS und mehr RAM bringt im Schnitt nur wenig.
Da ihr aber nun kein Swapping mehr habt, kann dies schon etwas helfen.
Hier wäre aber noch die Frage wie ihr die Daten auslest und wieder importiert?
Ich habe mir für sowas mal eine Methode geschrieben die die Daten per DataReader in gewissen Mengen einliest, in ein DataTable packt und dann per BulkCopy in die Ziel DB schiebt.
Ist bisher meine beste Lösung um große Datenbestände zu verschieben.
Aber ohne mehr Infos über eure Umgebung und deine Verarbeitung der Daten kann dir hier kaum jemand helfen.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Hallo T-Virus,
also für den Import verwende ich EF5 (bin leider daran gebunden, obwohl mein eigener ActiveRecord - Ansatz nur ca 45% der Zeit beansprucht hat, ich jedoch die DB-Struktur, Constraints etc. selbst verwalten musste)
Die interne Struktur der Daten ist wie ein "Baum" mit 6 Ebenen aufgebaut. und ich hangel mich für jeden Datensatz durch diesen Baum.
Übrigens: ohne das abspeichern der Daten in der neuen DB beträgt der Zeitaufwand nur ca 10% des Gesamtzeitbedarfs.
Viele Grüße
Jürgen
Man muß nichts wissen,
man muß nur wissen wer es wissen könnte
oder wo es steht😉
Tjo. Das liegt an der enorm schlechten Insert-Performance des EF.
Da bringt nen neuer Rechner nichts. Nur Bulk-Insert.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Gibt also nur zwei Möglichkeiten.
1.Es so belassen und damit leben müssen das es langsam ist.
2.Verzicht auf EF und alles selbst umsetzen um die Daten zu kopieren.
Da aber wohl Punkt 2 rausfällt bleibt dir nicht viel als mit Punkt 1 zu leben.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Nönö.
Man kann das EF auch zum Bulk zwingen. Man muss aber die FK-Felder in den Entities pflegen und die IDs manuell setzen. Dann kann man schon die Performance um den Faktor 1000 verbessern.
Das Performance-Problem bei EF tritt eben auf, sobald Relationen und Joins verwendet werden. Ohne das ist EF nur 10-20 mal langsamer als Plain und damit fast noch erträglich bei einmaligen Dingen.
Ansonsten ist eben auch Reflection ein Geschwindigkeitsproblem beim EF, um die Daten in die Entities zu mappen.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Danke für die Info.
Hab mit EF keine Erfahrung, deshalb kann ich da nicht viel sagen.
Da es aber scheinbar eine größ0ere Sache ist, würde ich eher davon ausgehen das EF hier nicht der beste Weg wäre.
Dazu kann man aber nur was sagen, wenn man mehr Infos hat.
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Hallo T-Virus
Um die Geschwindigkeit drastisch zu optimieren (für Bulk Inserts) ohne grossen Aufwand kannst du folgendes tun :
=> SaveChanges() selten aufrufen (z.B. alle 100 Records)
=> Ab und zu neuer Context erstellen ( attachet Entities, DetectChanges ... wegen..)
=> Wenn du den Context erstellst, AutoDetect Changes deaktivieren
context = new MyContext();
context.Configuration.AutoDetectChangesEnabled = false;
context.Configuration.ValidateOnSaveEnabled = false;
Beste Grüsse
Diräkt