SQL Errorlog Stałe komunikaty FlushCache
Serwer będący częścią grupy SQL 2017 Always on availability (BAG) Zauważyłem wzrost liczby tych komunikatów. Rozumiem, że są to komunikaty, które pojawiają się w dzienniku standardowo od 2012 r. (Flaga śledzenia przed 2012 r.), Ale w ciągu ostatnich 2 dni pojawiają się co kilka minut, w tym czasie nie ma uruchomionych kopii zapasowych ani zadań konserwacyjnych
Serwer działa jako pomocniczy nieczytelny partner przełączania awaryjnego, a serwer główny nie działa w ten sam sposób.
09/04/2020 10:52: 24, spid82s, Unknown, FlushCache: wyczyszczono 2303 bufory z 1881 zapisami w 81090 ms (uniknięto 11 nowych brudnych buforów) dla db 7: 0 09/04/2020 10:52:07, spid52s, nieznany, ostatni zaległy cel: 2 avgWriteLatency 86 04.09.2020 10:52:07, spid52s, nieznany, średni zapis na sekundę: 17,70 zapisów / s średnia przepustowość: 0,19 MB / s Nasycenie we / wy: 13073 przełączniki kontekstu 15434
W dzienniku błędów systemu znajduje się również ostrzeżenie o problemie z dyskiem, kilka sekund po tym, gdy grupa dostępności uległa awarii, od czasu zwiększenia liczby komunikatów FlushCache.
Czy ktoś doświadczył czegoś podobnego lub ma jakąś radę, mój administrator systemu przygląda się również posiadłości SAN i VMware.
Czy nagle pomyślał, że może to być spowodowane aktywnością autoregulacji?
Odpowiedzi
Przełącz się na pośrednie punkty kontrolne (ogólnie ustaw interwał odtwarzania na 60 sekund, przynajmniej dla baz danych użytkowników).
Pisałem o tym problemie tutaj i tutaj , i powinieneś przeczytać te posty w całości przed dokonaniem zmiany, chociaż jest to prawie bez myślenia IMHO.
Wpływ na nasze środowisko był drastyczny i natychmiastowy, a łatwo było udowodnić, że zmiana była odpowiedzialna. Każda baza danych z symptomem przeszła od 30-60 sekundowych punktów kontrolnych i dzienników błędów pełnych tych komunikatów do punktów kontrolnych poniżej sekundy i nie ma już wpisów w dziennikach błędów.
Prawdopodobnie istnieją również techniki łagodzenia obciążenia pracą, na przykład zobacz ten post autorstwa Itzika Ben-Gana, ale zwiększenie wydajności punktów kontrolnych jest szybszą i łatwiejszą ścieżką. Twoja pamięć masowa i ludzie z maszynami wirtualnymi nie są jednak oderwani; na pewno istnieje problem z dyskiem, który muszą rozwiązać (ale nie zgadzam się, że te komunikaty FlushCache były główną przyczyną każdego przełączenia awaryjnego; bardziej prawdopodobne jest, że są one po prostu inną ofiarą / symptomem).
Skontaktuj się z administratorem magazynu, jeśli ostatnio są dostępne aktualizacje oprogramowania układowego lub Twój podsystem magazynu wymaga nowszej aktualizacji oprogramowania układowego. Widziałem te wiadomości w środowisku SQL wiele razy i jedną rzeczą, na którą możesz spojrzeć, jest konfiguracja warstwy pamięci (jest to częsta przyczyna). Jedną rzeczą jest monitorowanie wydajności dysku za pomocą perfmon. liczniki dysków trzeba skupić się na: avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.
Możesz sprawdzić poniższy link, który możesz zobaczyć poniżej:
- Jak to działa: kiedy komunikat FlushCache jest dodawany do dziennika błędów programu SQL Server?
- https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038
Kiedy powiem warstwa pamięci, sprawdź następujące elementy: HBA / CNA, kabel światłowodowy, przełącznik FC, porty, kontroler pamięci masowej, oprogramowanie (sterowniki MPIO) - cała jego konfiguracja
Na koniec gorąco polecam, aby zawsze sprawdzać i badać komunikaty ostrzeżeń / błędów w dziennikach zdarzeń. NIE przepuszczaj tego, ponieważ tego rodzaju wiadomości mają długoterminowe konsekwencje w przyszłości.