Wydajność FILESTREAM

Wydajność FILESTREAM zależy od konfiguracji dysku i systemu plików wykorzystywanego do przechowywania obiektów.

Jak FILESTREAM zmienia ścieżkę odczytu danych

FILESTREAM jest funkcją aparatu SQL Server przeznaczoną do przechowywania wartości varbinary(max) w systemie plików NTFS, przy zachowaniu powiązania z wierszem tabeli. Dane nie są umieszczane w zwykłych stronach danych bazy w taki sam sposób jak małe wartości binarne. SQL Server zapisuje je w specjalnym kontenerze FILESTREAM należącym do grupy plików FILESTREAM, natomiast w tabeli przechowuje metadane i logiczne powiązanie z obiektem.

Wydajność zależy więc jednocześnie od silnika SQL Server, konfiguracji grupy plików FILESTREAM, systemu plików, urządzenia magazynującego oraz sposobu wykonywania operacji przez aplikację. Odczyt wartości przez standardowe zapytanie T-SQL ma inną charakterystykę niż strumieniowanie za pomocą interfejsu Win32 OpenSqlFilestream. Ten drugi mechanizm pozwala aplikacji pobierać zawartość jako strumień, zamiast przenosić cały obiekt przez zwykły mechanizm obsługi wartości w zapytaniu.

Magazyn danych, NTFS i opóźnienia operacji

Kontener FILESTREAM powinien znajdować się na woluminie NTFS przeznaczonym do obsługi danych tej funkcji. Znaczenie ma nie tylko maksymalna przepustowość dysku, lecz także czas odpowiedzi dla wielu operacji wejścia-wyjścia. Duże obiekty binarne mogą być odczytywane i zapisywane w sposób sekwencyjny, ale aplikacja obsługująca wiele jednoczesnych żądań może generować również znaczną liczbę operacji losowych. W takim przypadku ograniczeniem stają się opóźnienia urządzenia, kolejka dyskowa i liczba równoległych żądań.

Ważna jest separacja obciążenia. Jeżeli kontener FILESTREAM, pliki danych SQL Server i dziennik transakcji korzystają z tego samego przeciążonego urządzenia, opóźnienia jednej ścieżki mogą wpływać na pozostałe. Szczególnie istotny jest dziennik transakcji, ponieważ operacje modyfikujące dane FILESTREAM nadal uczestniczą w transakcjach SQL Server i wymagają prawidłowej obsługi logowania oraz zatwierdzania zmian. Sama duża szybkość odczytu kontenera nie gwarantuje więc wysokiej wydajności zapisu.

Przy ocenie magazynu należy obserwować przepustowość, średni i maksymalny czas odpowiedzi, długość kolejki dyskowej, wykorzystanie procesora oraz opóźnienia dziennika transakcji. Pomiary trzeba wykonywać przy obciążeniu zbliżonym do rzeczywistego, ponieważ pojedynczy test dużego pliku może nie ujawnić problemu występującego przy wielu równoległych operacjach.

Transakcje, dostęp strumieniowy i zachowanie aplikacji

Wydajność FILESTREAM zależy od modelu dostępu używanego przez aplikację. Zwykły odczyt przez T-SQL jest wygodny, gdy obiekt ma być częścią wyniku zapytania lub gdy aplikacja wykonuje niewielkie operacje na danych. Przy długich odczytach i zapisach dużych obiektów można wykorzystać OpenSqlFilestream. Interfejs ten wymaga kontekstu transakcji uzyskanego z SQL Server i zapewnia kontrolowany dostęp do strumienia powiązanego z konkretną wartością FILESTREAM.

Nieprawidłowo zaprojektowany czas trwania transakcji może ograniczać przepustowość. Transakcja utrzymywana przez cały czas powolnego przesyłania pliku może długo zajmować zasoby i zwiększać liczbę oczekujących operacji. Z drugiej strony zbyt wczesne zatwierdzenie albo zamknięcie kontekstu dostępu może przerwać strumieniowanie. Aplikacja powinna więc odpowiednio dobierać rozmiar operacji, zamykać uchwyty oraz obsługiwać wycofanie transakcji i ponawianie operacji po błędach.

Na wynik wpływają także zapytania wyszukujące rekordy zawierające dane FILESTREAM. Indeksy dotyczące kolumn identyfikujących obiekty i metadane mogą ograniczyć liczbę odczytywanych wierszy, ale nie przyspieszą samego transferu zawartości, jeżeli wąskim gardłem jest magazyn plikowy. Analiza powinna rozdzielać czas wyszukania rekordu od czasu otwarcia i przesłania strumienia.

Diagnostyka wydajności w środowisku SQL Server

Diagnozę należy rozpocząć od ustalenia, która część przepływu jest najwolniejsza: wyszukiwanie rekordu w SQL Server, rozpoczęcie transakcji, otwarcie strumienia, odczyt z kontenera NTFS, zapis do dziennika czy przesłanie danych przez sieć. Pomocne jest porównanie czasu wykonania zapytania z czasem samego transferu pliku. Jeżeli zapytanie zwraca rekord szybko, lecz strumień działa wolno, problemu należy szukać przede wszystkim w magazynie, konkurencji operacji wejścia-wyjścia albo połączeniu sieciowym.

Warto sprawdzić konfigurację grupy plików FILESTREAM, dostępne miejsce, stan woluminu NTFS, błędy systemowe oraz obciążenie urządzenia podczas reprodukcji problemu. Po stronie SQL Server należy analizować oczekiwania, aktywne transakcje, czas zatwierdzania zmian i obciążenie dziennika. Po stronie aplikacji trzeba zweryfikować, czy dane są przesyłane strumieniowo, czy nie są niepotrzebnie kopiowane do pamięci, oraz czy liczba równoległych żądań nie przekracza możliwości magazynu.

Naprawa problemu może obejmować zmianę konfiguracji magazynu, ograniczenie konkurencji operacji, korektę obsługi transakcji albo modyfikację kodu korzystającego z FILESTREAM. Przed zmianą należy zebrać pomiary bazowe i powtórzyć ten sam scenariusz po wdrożeniu korekty. W przeciwnym razie poprawa pojedynczego parametru może jedynie przenieść wąskie gardło z dysku do dziennika transakcji, procesora lub sieci.