Żądania we / wy trwają dłużej niż 15 sekund

Zwykle nasze cotygodniowe pełne kopie zapasowe kończą się w około 35 minut, a codzienne kopie różnicowe kończą się w ~ 5 minut. Od wtorku dzienniki zajęły prawie 4 godziny, o wiele więcej niż powinno być wymagane. Przypadkowo zaczęło się to zaraz po otrzymaniu nowej konfiguracji SAN / dysku.

Pamiętaj, że serwer działa w trybie produkcyjnym i nie mamy żadnych ogólnych problemów, działa płynnie - z wyjątkiem problemu we / wy, który przejawia się przede wszystkim w wydajności tworzenia kopii zapasowych.

Patrząc na dm_exec_requests podczas tworzenia kopii zapasowej, kopia zapasowa ciągle czeka na ASYNC_IO_COMPLETION. Aha, więc mamy spór o dysk!

Jednak ani MDF (dzienniki są przechowywane na dysku lokalnym), ani dysk zapasowy nie mają żadnej aktywności (IOPS ~ = 0 - mamy dużo pamięci). Długość kolejki dyskowej ~ = 0 również. Procesor waha się w granicach 2-3%, nie ma też problemu.

SAN to Dell MD3220i, jednostka LUN składająca się z 6x10k dysków SAS. Serwer jest połączony z siecią SAN dwiema fizycznymi ścieżkami, z których każda przechodzi osobnym przełącznikiem z redundantnymi połączeniami z siecią SAN - łącznie cztery ścieżki, z których dwie są aktywne w dowolnym momencie. Mogę sprawdzić, czy oba połączenia są aktywne poprzez menedżera zadań - rozdzielając obciążenie idealnie równomiernie. Oba połączenia działają w trybie pełnego dupleksu 1G.

Kiedyś używaliśmy ramek typu jumbo, ale wyłączyłem je, aby wykluczyć tutaj jakiekolwiek problemy - bez zmian. Mamy inny serwer (ten sam system operacyjny + konfiguracja, 2008 R2), który jest podłączony do innych jednostek LUN i nie wykazuje żadnych problemów. Nie działa jednak na nim SQL Server, a jedynie na nim współużytkuje CIFS. Jednak jedna z preferowanych ścieżek LUN znajduje się na tym samym kontrolerze SAN, co kłopotliwe jednostki LUN - więc też to wykluczyłem.

Przeprowadzenie kilku testów SQLIO (plik testowy 10G) wydaje się wskazywać, że IO jest przyzwoite, pomimo problemów:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Zdaję sobie sprawę, że nie są to wyczerpujące testy w żaden sposób, ale sprawiają, że czuję się swobodnie wiedząc, że to nie są kompletne śmieci. Zauważ, że wyższa wydajność zapisu jest spowodowana dwiema aktywnymi ścieżkami MPIO, podczas gdy odczyt użyje tylko jednej z nich.

Sprawdzanie dziennika zdarzeń aplikacji ujawnia zdarzenia takie jak te rozrzucone wokół:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

Nie są stałe, ale zdarzają się regularnie (kilka na godzinę, więcej podczas tworzenia kopii zapasowych). Oprócz tego zdarzenia dziennik zdarzeń systemowych opublikuje następujące informacje:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Występują one również na bezproblemowym serwerze CIFS działającym na tym samym SAN / kontrolerze i od mojego Googlinga wydają się nie mieć znaczenia krytycznego.

Pamiętaj, że wszystkie serwery używają tych samych kart sieciowych - Broadcom 5709C z aktualnymi sterownikami. Same serwery to Dell R610.

Nie jestem pewien, co jeszcze sprawdzić. Jakieś sugestie?

Aktualizacja - uruchamiając perfmon
Próbowałem nagrać Śr. Liczniki wydajności dysku sec / odczyt i zapis podczas tworzenia kopii zapasowej. Tworzenie kopii zapasowej rozpoczyna się błyskawicznie, a następnie zasadniczo zatrzymuje się przy 50%, powoli czołgając się do 100%, ale zajmuje 20 razy więcej czasu, niż powinno.

Pokazuje obie ścieżki SAN, które są używane, a następnie odpadają.

Kopia zapasowa została zainicjowana około 15:38:50 - zauważ, że wszystko wygląda dobrze, a potem jest seria szczytów. Nie interesuje mnie pisanie, tylko teksty wydają się zawieszać.

Zwróć uwagę na bardzo małą akcję włączania / wyłączania, choć niesamowitą wydajność na samym końcu.

Uwaga: maksimum 12 sekund, chociaż średnia jest ogólnie dobra.

Aktualizacja - Tworzenie kopii zapasowej na urządzeniu NUL
Aby wyizolować problemy z czytaniem i uprościć rzeczy, uruchomiłem następujące czynności:

BACKUP DATABASE XXX TO DISK = 'NUL'

Wyniki były dokładnie takie same - zaczyna się od odczytania serii, a następnie zatrzymuje się, od czasu do czasu wznawiając operacje:

Aktualizacja - IO stragany
Pobiegłem zapytanie dm_io_virtual_file_stats Jonathan Kehayias i Ted Kruegers książki (strona 29), zgodnie z zaleceniami Shawn. Patrząc na 25 najlepszych plików (po jednym pliku danych - wszystkie wyniki są plikami danych), mogłoby się wydawać, że odczyty są gorsze niż zapisy - być może dlatego, że zapisy trafiają bezpośrednio do pamięci podręcznej SAN, podczas gdy zimne odczyty muszą trafić na dysk - to tylko przypuszczenie .

Aktualizacja - statystyki
czekania Zrobiłem trzy testy, aby zebrać statystyki czekania. Statystyki oczekiwania są sprawdzane za pomocą skryptu Glenn Berry / Paul Randals . I tylko dla potwierdzenia - kopie zapasowe nie są wykonywane na taśmie, ale na jednostce iSCSI LUN. Wyniki są podobne, jeśli są wykonywane na dysku lokalnym, z wynikami podobnymi do kopii zapasowej NUL.

Wyczyszczone statystyki. Biegał przez 10 minut, normalne obciążenie:

Wyczyszczone statystyki. Działał przez 10 minut, normalne ładowanie + normalne wykonywanie kopii zapasowej (nie zostało ukończone):

Wyczyszczone statystyki. Działał przez 10 minut, normalne ładowanie + tworzenie kopii zapasowej NUL (nie zostało ukończone):

Aktualizacja - Wtf, Broadcom?
W oparciu o sugestie Marka Storey-Smithsa i wcześniejsze doświadczenia Kyle'a Brandtsa z kartami sieciowymi Broadcom postanowiłem przeprowadzić pewne eksperymenty. Ponieważ mamy wiele aktywnych ścieżek, mogłem stosunkowo łatwo zmieniać konfigurację kart sieciowych jeden po drugim, nie powodując żadnych awarii.

Wyłączenie TOE i dużego odciążenia wysyłania przyniosło prawie idealny przebieg:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Więc kto jest winowajcą, TOE lub LSO? TOE włączone, LSO wyłączone:

Didn't finish the backup as it took forever - just as the original problem!

TOE wyłączone, LSO włączone - dobrze wygląda:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

Jako kontrolę wyłączyłem zarówno TOE, jak i LSO, aby potwierdzić, że problem zniknął:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

Podsumowując, wydaje się, że problem spowodował włączony silnik odciążający TCP Broadcom NICs. Gdy tylko TOE zostało wyłączone, wszystko działało jak urok. Chyba nie będę już zamawiać żadnych kart sieciowych Broadcom.

Aktualizacja - serwer idzie w dół - serwer CIFS
Dzisiaj identyczny i działający serwer CIFS zaczął wyświetlać zawieszone żądania We / Wy. Na tym serwerze nie działał SQL Server, tylko zwykły Windows Web Server 2008 R2 obsługujący udziały przez CIFS. Gdy tylko wyłączyłem TOE, wszystko wróciło do normy.

Potwierdza tylko, że nigdy więcej nie będę używać TOE na NIC Broadcom, jeśli w ogóle nie mogę uniknąć NIC Broadcom.

Pamiętaj, że wszystkie serwery używają tych samych kart sieciowych - Broadcom 5709C z aktualnymi sterownikami. Same serwery to Dell R610.

Kyle Brandt ma opinię na temat kart sieciowych Broadcom, która odzwierciedla moje własne (powtarzane) doświadczenia.

Broadcom, Die Mutha

Moje problemy zawsze były związane z funkcjami TCP Offload, aw 99% przypadków wyłączenie lub przejście na inną kartę sieciową rozwiązało objawy. Jeden klient, który (jak w twoim przypadku) korzysta z serwerów Dell, zawsze zamawia osobne karty sieciowe Intel i wyłącza wbudowane karty Broadcom.

Jak opisano w tym blogu MSDN , zacznę od wyłączenia w systemie operacyjnym za pomocą:

netsh int ip set chimney DISABLED

IIRC w niektórych okolicznościach może być konieczne wyłączenie funkcji na poziomie sterownika karty, z pewnością nie zaszkodzi to zrobić.

Nie dlatego, że jestem ekspertem od SAN / dysków (są tu ludzie, którzy wiedzą więcej ode mnie) ... Udostępniam tylko to, co zrobiłem trochę i głównie czytam :)

Jonathan Kehayias i Ted Krueger napisali książkę „Rozwiązywanie problemów z serwerem SQL”, która zawiera dobre informacje na temat wydajności dysku. Możesz pobrać plik PDF za darmo tutaj . (Mogę też kupić wersję drukowaną na biurko).

W każdym razie mają dobre zapytanie, za pomocą którego można sprawdzić sys.dm_io_virtual_file_stats i sprawdzić średnie opóźnienie w plikach danych. Może się okazać, że RAID10 nie jest idealną konfiguracją do przechowywania plików danych.