Wiadomości FlushCache pojawiające się w logu o określonych godzinach

Ostatnio mieliśmy wiele problemów z wydajnością bazy danych i starałem się dowiedzieć, czy potrafię zrozumieć, dlaczego. Nie mamy DBA (jestem programistą), więc po prostu go uskrzydlam, a większość tego, co znajduję w Internecie, jest dla mnie językiem obcym.

SQL Server był restartowany każdego ranka, ponieważ jest to jedyny sposób, w jaki działa on w ciągu dnia roboczego. Zauważyłem, że każdego ranka około 5 rano zaczynamy otrzymywać tę wiadomość co dwie minuty w dzienniku:

FlushCache: wyczyściłem 11848 buforów 7432 zapisami w 97168 ms (uniknięto 8139 nowych brudnych bufów) dla db 9: 0

ostatni cel nierozstrzygnięty: 4, avgWriteLatency 32

średnia przepustowość: 0,72 MB / s, nasycenie we / wy: 11635, przełączniki kontekstu 18849

Liczby różnią się za każdym razem, ale jest to ten sam komunikat w kółko według tego wzoru, dopóki nie zrestartuję serwera. Nie jestem pewien, jak to zinterpretować, próbowałem o tym napisać w Google i wszystko, co zebrałem, to to, że może to oznaczać, że coś jest nie tak z I / O i że coś trwa dłużej niż powinno. Niedawno przeszliśmy na SSD, więc nie sądziłem, że powinien to być problem z zapisem.

Czy ktoś mógłby rzucić na to trochę światła?

Komunikat FlushCache w dzienniku błędów jest powodowany przez rejestrowanie punktu kontrolnego, aw tym przypadku przez długi punkt kontrolny (który jest zdefiniowany jako punkt kontrolny, który trwa dłużej niż interwał odzyskiwania). Niezależnie od tego, czy jest zalogowany, czy nie, zachowanie jest inne w wersjach wcześniejszych niż 2012 i 2012+. Przed SQL Server 2012, aby uzyskać rejestrowanie w punkcie kontrolnym, należy włączyć flagę śledzenia (T3504). Ale począwszy od SQL Server 2012 wiadomość ta jest domyślnie rejestrowana, gdy napotkamy długi punkt kontrolny.

A teraz pytanie „czy to naprawdę złe ?” , naprawdę musisz zacząć patrzeć na te liczby, biorąc pod uwagę ich kontekst. Ponad 97 sekund zajęło ci opróżnienie tylko około 93 MB brudnych buforów. Wygląda na to, że może to być potencjalnie mieszanka dużej ilości rezygnacji z danych (podczas samego punktu kontrolnego zabrudzono również bufory o wartości około 64 MB) i potencjalnie pamięci, która nie nadąża za modyfikacją danych i / lub resztą obciążenia we / wy.

Chciałbym zweryfikować kondycję twojego podsystemu pamięci masowej , spojrzeć na oczekiwania i po prostu uzyskać ogólny obraz wydajności wystąpienia. Spójrz na logiczne liczniki perfmon dysku i zobacz, jaka jest ogólna rezygnacja z operacji we / wy z przepustowością , opóźnieniami i operacjami wejścia / wyjścia . Pomoże Ci namalować bardziej żywy obraz wydajności dysków. Jeśli masz możliwość przetestowania swojego magazynu, jeśli jeszcze go nie oparłeś , powinieneś zobaczyć, do czego zdolne są te woluminy ( SQLIO jest świetnym narzędziem do tego) i co teraz robią (miło jest mieć poziom odniesienia, gdy wolumeny wzrosły, aby porównać z obecnym poziomem odniesienia).

Oto świetny artykuł wyjaśniający ten komunikat - Jak to działa: Kiedy komunikat FlushCache jest dodawany do dziennika błędów SQL Server?

EDYCJA : Ponownie czytając twoje pytanie, musiałem przeoczyć ten komentarz:

Zauważyłem, że każdego ranka około 5 rano zaczynamy otrzymywać tę wiadomość

Zobacz, co dzieje się teraz w twoim magazynie, zgodnie z powyższymi wskazówkami. To brzmi jak zaplanowana operacja podręcznika, która odbija się na pamięci masowej, powodując pogorszenie wydajności punktu kontrolnego i „długie”.