kein Performancegewinn nach Umstellung auf Win7 und 16GB RAM

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

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

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

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

Tjo. Das liegt an der enorm schlechten Insert-Performance des EF.
Da bringt nen neuer Rechner nichts. Nur Bulk-Insert.

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

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.

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.

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