Файловый поток SQL Server - удалить «скорость» - PullRequest
8 голосов
/ 29 января 2010

Я впервые работаю с типом данных файлового потока (SQL Server 2008), и у меня возникают проблемы, когда я выполняю быструю вставку / удаление. В основном, скорость, с которой файлы фактически удаляются из FileSystem, намного ниже, чем скорость вставки / удаления, даже если я вызываю сборщик мусора вручную (насколько я знаю, CHECKPOINT должен вызывать сборщик мусора).

Приведенный ниже код иллюстрирует проблему: выполнение занимает около 30 секунд, но вам нужно подождать несколько минут, чтобы последний файл был удален из файловой системы (когда я просматриваю папку C: \ FSTest \ Files )

Есть ли способ ускорить сборщик мусора? (Кажется, примерно 10 файлов удаляются каждые 10 секунд, и это заставляет меня поверить, что если я буду хранить / удалять более 2 записей в секунду, я в конечном итоге заполню жесткий диск)

Спасибо

CREATE DATABASE FSTest ON PRIMARY
    (NAME = FSTest_data, FILENAME = N'C:\FSTest\FSTest_data.mdf'),
FILEGROUP FSTestFileGroup CONTAINS FILESTREAM
    (NAME = FSTestFiles,FILENAME = N'C:\FSTest\Files')
LOG ON 
    (NAME = 'FSTest_log', FILENAME = N'C:\FSTest\FSTest_log.ldf');
GO

USE FSTest;
GO

CREATE TABLE FSTest (
    Guid UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE DEFAULT NEWSEQUENTIALID(),
    Name VARCHAR (25),
    Data VARBINARY(MAX) FILESTREAM);
GO

ALTER DATABASE FSTest SET RECOVERY SIMPLE;
GO

SET NOCOUNT ON
DECLARE @test int
SET @test=0
WHILE @test<1000 BEGIN
    INSERT INTO FSTest(Name,Data) VALUES('test',CAST('abc' AS VARBINARY(MAX)))
    DELETE FROM FSTest WHERE Name='test'
    CHECKPOINT
    SET @test = @test+1
END

Обновление:

Я пытался сделать то же самое в течение более длительного периода времени со скоростью вставки / удаления, соответствующей моим потребностям, и после 30 минут выполнения наблюдается та же самая ситуация: файлы создаются намного быстрее, чем они удаляются.

SET NOCOUNT ON
DECLARE @test int
SET @test=0
WHILE @test<100000 BEGIN
    INSERT INTO FSTest(Name,Data) VALUES('test',CAST('abc' AS VARBINARY(MAX)))
    DELETE FROM FSTest WHERE Name='test'
    WAITFOR DELAY '00:00:00:200'
    CHECKPOINT
    SET @test = @test+1
END

Ответы [ 3 ]

5 голосов
/ 11 февраля 2010

После еще нескольких исследований (и благодаря блогу Пола Рэндала - много очень подробной информации, касающейся файлового потока и сборки мусора), после удаления строк и выполнения контрольной точки файлы помещаются в системную таблицу (таблицу Tombstone) затем каждые 10 секунд запускается процесс (Ghost Cleanup) и удаляются некоторые элементы из этой таблицы (20, если быть точным). Таким образом, в основном мы ограничены 2 удалениями / секундами, и, кажется, нет способа (пока) изменить это поведение.

Поскольку у меня есть устойчивые 4 удаления в секунду, мне нужно будет найти альтернативу файловому потоку.

Спасибо всем за ваш вклад.

2 голосов
/ 31 января 2010

Как сказал Ремус, если вы используете модель полного восстановления, тогда все сложно. Но даже при простой модели восстановления вы должны иметь в виду, что CHECKPOINT вызывает сборщик мусора (GC), но это не гарантирует, что GC удалит все файлы за один проход. GC в настоящее время имеет ограничение на количество операций, которые он может выполнять за один вызов. Кроме того, файлы удаляются с параметром FILE_DELETE_ON_CLOSE, поэтому, пока у файла есть открытые дескрипторы, вы все равно будете его видеть, даже если GC, возможно, уже удалил его. Такие открытые дескрипторы могут храниться антивирусными программами или другими драйверами фильтров файловой системы.

И наконец, если у вас действительно не хватает места на диске, я бы не стал сильно беспокоиться об устаревших файлах - они в конечном итоге будут удалены как часть автоматических контрольных точек базы данных. Я считаю (хотя верю - это ключевое слово здесь), что, хотя у него может быть медленное «время запуска», GC будет продолжать физически удалять файлы, если вы будете постоянно выполнять тест в течение длительного периода времени (минут ?).

Если вы заботитесь о производительности, хранение контейнеров файлового потока на системном диске может быть не очень хорошей идеей. См. здесь с советами по производительности файлового потока.

1 голос
/ 29 января 2010

Все немного сложнее, чем простая контрольная точка. Файл можно удалить, когда последний VLF, содержащий записи журнала о создании файла, неактивен. См. Сборка мусора FILESTREAM .

...