SQL Server Filestream - Löschen "Geschwindigkeit"

8

Ich arbeite mit dem Filestream-Datentyp zum ersten Mal (SQL Server 2008) und ich stehe auf Probleme, wenn ich einige schnelle Einfügungen / Löschungen mache. Grundsätzlich ist die Geschwindigkeit, mit der die Dateien tatsächlich aus dem Dateisystem entfernt werden, viel langsamer als die Einfüge- / Löschgeschwindigkeit, auch wenn ich den Garbage Collector manuell aufruft (so weit ich weiß, dass der CHECKPOINT den Garbage Collector aufrufen soll) >

Der folgende Code veranschaulicht das Problem - Es dauert ungefähr 30 Sekunden, um ausgeführt zu werden, aber Sie müssen einige Minuten warten, bis die letzte Datei aus dem Dateisystem gelöscht wird (Wenn ich den Ordner C: \ FSTest \ Files suche )

Gibt es eine Möglichkeit, den Garbage Collector zu beschleunigen? (Es scheint ungefähr alle 20 Sekunden 20 Dateien zu löschen - was mich glauben lässt, dass, wenn ich mehr als 2 Datensätze pro Sekunde speichere / lösche, ich letztendlich die Festplatte füllen werde)

Danke

%Vor%

Aktualisierung:

Ich habe das gleiche für eine längere Zeit mit einer Einfüge- / Löschgeschwindigkeit versucht, die meinen Bedürfnissen näher kommt, und nach 30 Minuten Ausführung ist die gleiche Situation zu beobachten: Dateien werden viel schneller erstellt als gelöscht.

%Vor%     
Benoittr 28.01.2010, 23:06
quelle

3 Antworten

5

Nach einigen weiteren Recherchen (und dank Paul Randals Blog - viele sehr detaillierte Informationen über Filestream und Garbage Collection) werden die Dateien nach dem Löschen der Zeilen und dem Ausführen eines Checkpoints in eine Systemtabelle (Tombstone-Tabelle) gestellt. Dann wird alle 10 Sekunden ein Prozess (Ghost Cleanup) ausgeführt und einige Elemente aus dieser Tabelle entfernt (20, um genau zu sein). Im Grunde sind wir auf 2 Löschungen / Sekunden beschränkt und es scheint (noch) keine Möglichkeit zu geben, dieses Verhalten zu ändern.

Da ich ständig 4 Löschungen pro Sekunde habe, muss ich eine Alternative zu Filestream finden.

Danke allen für Ihre Eingaben.

    
Benoittr 11.02.2010, 15:31
quelle
2

Wie Remus sagte, wenn Sie das vollständige Wiederherstellungsmodell verwenden, sind die Dinge kompliziert. Aber selbst unter dem einfachen Wiederherstellungsmodell müssen Sie daran denken, dass CHECKPOINT den Garbage Collector (GC) aufruft, aber es garantiert nicht, dass GC alle Dateien in einem einzigen Durchlauf löscht. GC hat derzeit ein Limit für die Anzahl der Operationen, die in einem einzelnen Aufruf ausgeführt werden können. Darüber hinaus werden Dateien mit der Option FILE_DELETE_ON_CLOSE gelöscht. Wenn also offene Handles für eine Datei vorhanden sind, sehen Sie sie trotzdem, obwohl GC sie möglicherweise bereits gelöscht hat. Solche offenen Handles können von Antivirenprogrammen oder anderen Dateisystemfiltertreibern gehalten werden.

Zu guter Letzt: Wenn Sie nicht gerade über wenig Speicherplatz auf der Festplatte verfügen, muss ich mich nicht so sehr um veraltete Dateien kümmern - sie werden schließlich als Teil der automatischen Datenbankprüfpunkte gelöscht. Ich glaube (obwohl glauben, ist das Schlüsselwort hier), dass GC, obwohl es möglicherweise eine langsame "Startzeit" hat, mit dem physischen Löschen von Dateien fortfährt, wenn Sie Ihren Test über einen längeren Zeitraum stabil ausführen ( Minuten?).

Wenn Sie Wert auf Leistung legen, ist das Speichern von Filestream-Containern auf einem Systemlaufwerk möglicherweise keine so gute Idee. Hier finden Sie hier für Tipps zur Filestream-Leistung.

    
Pawel Marciniak 30.01.2010 21:40
quelle
1

Die Dinge sind ein bisschen komplizierter als ein einfacher Checkpoint. Die Datei kann entfernt werden, wenn der letzte VLF mit Protokolldatensätzen zur Dateierstellung inaktiv ist. Siehe FILESTREAM-Garbage Collection .

    
Remus Rusanu 28.01.2010 23:15
quelle

Tags und Links