Zużycie „Total Server Memory” w programie SQL Server utrzymuje się na stałym poziomie przez wiele miesięcy z dostępnymi 64 GB i więcej

Natknąłem się na dziwny problem polegający na tym, że 64-bitowy program SQL Server 2016 Standard Edition ograniczył się dokładnie do połowy przydzielonej mu pamięci (64 GB z 128 GB).

Dane wyjściowe @@VERSIONto:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 grudnia 2017 11:25:00 Prawa autorskie (c) Microsoft Corporation Standard Edition (64-bit) w systemie Windows Server 2012 R2 Datacenter 6.3 ( Kompilacja 9600:) (Hypervisor)

Dane wyjściowe sys.dm_os_process_memoryto:

Kiedy pytam sys.dm_os_performance_counters, widzę, że Target Server Memory (KB)jest o 131072000i Total Server Memory (KB)jest prawie o połowę niższa o 65308016. W większości scenariuszy zrozumiałbym to jako normalne zachowanie, ponieważ SQL Server nie określił jeszcze, że musi przydzielić sobie dodatkową pamięć.

Jednak już od ponad 2 miesięcy „utknął” na poziomie ~ 64 GB. W tym czasie wykonaliśmy znaczną ilość operacji wymagających dużej ilości pamięci na niektórych bazach danych i dodaliśmy do instancji prawie 40 kolejnych baz danych. Łącznie siedzimy na 292 bazach danych, każda z wstępnie przydzielonymi plikami danych o wielkości 4 GB z 256 MB szybkością wzrostu i 2 GB plików dziennika z szybkością wzrostu 128 MB. Pełną kopię zapasową wykonuję co noc o godzinie 00:00, a kopie zapasowe dziennika transakcji rozpoczynam od poniedziałku do piątku od godziny 6:00 do 20:00 w odstępach co 15 minut. Te bazy danych mają stosunkowo niską ogólną przepustowość, ale jestem sceptyczny, że coś jest nie tak, biorąc pod uwagę, że SQL Server nie wkradł się w kierunkuTarget Server Memory naturalnie poprzez nowe dodatki do bazy danych, normalne wykonywanie zapytań, a także uruchomione potoki ETL zajmujące dużo pamięci.

Sama instancja programu SQL Server znajduje się na zwirtualizowanym (VMware) serwerze Windows Server 2012R2 z 12 procesorami, 144 GB pamięci (128 GB na SQL Server, 16 GB zarezerwowane dla systemu Windows) i 4 wszystkimi dyskami wirtualnymi, które znajdują się na szczycie sieci vSAN z 15K dyskami SAS . System Windows znajduje się naturalnie na dysku C: 64 GB z plikiem strony o wielkości 32 GB. Pliki danych znajdują się na dysku D: 2 TB, pliki dziennika znajdują się na dysku L: 2 TB, a tempdb na dysku T: 256 GB z plikami 8x16 GB bez automatycznego wzrostu.

Zweryfikowałem, że na serwerze nie ma innych wystąpień SQL Server MSSQLSERVER.

Ten serwer jest w całości poświęcony tylko wystąpieniu SQL Server, więc nie mamy na nim uruchomionych żadnych innych aplikacji ani usług, które mogłyby zużywać pamięć.

Używam RedGate SQL Monitor do analizy, a poniżej znajduje się historia ostatnich 18 dni Total Server Memory. Jak widać, wykorzystanie pamięci pozostało całkowicie w zastoju, poza pojedynczym wzrostem ~ 300 MB na początku kwietnia.

Co może być tego przyczyną? Na co mogę przyjrzeć się bliżej, aby ustalić, dlaczego SQL Server nie chce używać dodatkowych 64 GB + przydzielonej pamięci?

Wynik działania sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Priorytet 50: Wydajność :

• Harmonogramy procesorów offline - niektóre rdzenie procesorów nie są dostępne dla programu SQL Server z powodu maskowania koligacji lub problemów z licencjonowaniem.

• Węzły pamięci offline - ze względu na problemy z maskowaniem koligacji lub licencjonowaniem część pamięci może być niedostępna.

Priorytet 50: Niezawodność :

• Zdalny DAC wyłączony - Zdalny dostęp do dedykowanego połączenia administracyjnego (DAC) nie jest włączony. DAC może znacznie ułatwić zdalne rozwiązywanie problemów, gdy SQL Server nie odpowiada.

Priorytet 100: Wydajność :

• Wiele planów dla jednej kwerendy - 300 planów dla pojedynczego zapytania w pamięci podręcznej planu - co oznacza, że ​​prawdopodobnie mamy problemy z parametryzacją.

• Server Triggers Enabled

  • Trigger serwera [RG_SQLLighthouse_DDLTrigger] jest włączony. Upewnij się, że rozumiesz, co robi ten wyzwalacz - im mniej pracy, tym lepiej.

  • Trigger serwera [SSMSRemoteBlock] jest włączony. Upewnij się, że rozumiesz, co robi ten wyzwalacz - im mniej pracy, tym lepiej.

Priorytet 150: Wydajność :

• Zapytania wymuszające wskazówki dotyczące dołączania - od ponownego uruchomienia zarejestrowano 1480 instancji podpowiedzi dotyczących dołączania. Oznacza to, że zapytania kierują optymalizatorem SQL Server, a jeśli nie wiedzą, co robią, może to spowodować więcej szkody niż pożytku. To może również wyjaśniać, dlaczego wysiłki związane z dostrajaniem DBA nie działają.

• Zapytania wymuszające wskazówki dotyczące zamówienia - od ponownego uruchomienia zarejestrowano 2153 przypadków podpowiedzi dotyczących zamówień. Oznacza to, że zapytania kierują optymalizatorem SQL Server, a jeśli nie wiedzą, co robią, może to spowodować więcej szkody niż pożytku. To może również wyjaśniać, dlaczego wysiłki związane z dostrajaniem DBA nie działają.

Priorytet 170: Konfiguracja pliku :

• Systemowa baza danych na dysku C.

  • master - główna baza danych ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

  • model - baza danych modelu ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

  • msdb - baza danych msdb ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

Priorytet 200: Informacyjny :

• Zadania agenta uruchamiane jednocześnie - Wiele zadań agenta programu SQL Server jest skonfigurowanych do jednoczesnego uruchamiania. Aby uzyskać szczegółowe informacje o harmonogramie, zobacz zapytanie w adresie URL.

• Tabele w głównym wzorcowej bazie danych - Tabela CommandLog w głównej bazie danych została utworzona przez użytkowników końcowych w dniu 30 lipca 2017 17:22. Tabele w głównej bazie danych mogą nie zostać przywrócone w przypadku awarii.

• TraceFlag On

  • Flaga śledzenia 1118 jest włączona globalnie.

  • Flaga śledzenia 1222 jest włączona globalnie.

  • Flaga śledzenia 2371 jest włączona globalnie.

Priorytet 200: Domyślna konfiguracja serwera :

• Agent XPs - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• domyślna suma kontrolna kopii zapasowej - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• domyślna kompresja kopii zapasowej - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• próg kosztu dla równoległości - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 5 i została ustawiona na 48.

• maksymalny stopień równoległości - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 12.

• maksymalna pamięć serwera (MB) - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 2147483647 i została ustawiona na 128000.

• optymalizuj pod kątem obciążeń ad hoc - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• pokaż zaawansowane opcje - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• xp_cmdshell - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

Priorytet 200: Niezawodność :

• Rozszerzone procedury składowane w systemie głównym

• master - rozszerzona procedura składowana [sqbdata] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqbdir] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura przechowywana [sqbmemory] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqbstatus] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - rozszerzona procedura składowana [sqbtest] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqbtestcancel] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqbteststatus] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqbutility] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

  • master - Rozszerzona procedura składowana [sqlbackup] znajduje się w głównej bazie danych. CLR może być w użyciu, a główna baza danych musi być teraz częścią planu tworzenia kopii zapasowych / odzyskiwania.

Priorytet 210: Domyślna konfiguracja bazy danych :

• Czytaj zatwierdzone izolowanie migawek włączone - To ustawienie bazy danych nie jest domyślne.

  • RedGate

  • RedGateMonitor

• Snapshot Isolation Enabled - To ustawienie bazy danych nie jest domyślne.

  • RedGate

  • RedGateMonitor

Priorytet 240: Statystyki czekania :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 godzin oczekiwania, średni czas oczekiwania 115,9 minut na godzinę, oczekiwanie sygnału 100,0%, 1419212079 zadań oczekiwania, średni czas oczekiwania 4,5 ms.

Priorytet 250: Informacyjny :

• SQL Server działa na koncie NT Service - pracuję jako NT Service \ MSSQLSERVER. Chciałbym mieć zamiast tego konto usługi Active Directory.

Priorytet 250: Informacje o serwerze :

• Domyślna zawartość śledzenia - Domyślny ślad zawiera 36 godzin danych między 14 kwietnia 2018 23:21 a 16 kwietnia 2018 11:13. Domyślne pliki śledzenia znajdują się w: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Dysk C Space - 196816.00 MB bezpłatnie na dysku C.

• Dysk D Space - 894823.00 MB bezpłatnie na dysku E.

• Dysk L Space - 1361367.00 MB bezpłatnie na dysku F.

• Dysk T Space - 114441.00 MB bezpłatnie na dysku G.

• Sprzęt - procesory logiczne: 12. Pamięć fizyczna: 144 GB.

• Sprzęt - Konfiguracja NUMA

  • Węzeł: 0 Stan: ONLINE Plany online: 4 Plany offline: 2 Grupa procesorów: 0 Węzeł pamięci: 0 Zarezerwowany VAS pamięci GB: 186

  • Węzeł: 1 Stan: OFFLINE Plany online: 0 Plany offline: 6 Grupa procesorów: 0 Węzeł pamięci: 0 Zarezerwowany VAS pamięci GB: 186

• Natychmiastowa inicjalizacja pliku włączona - konto usługi ma uprawnienia do wykonywania zadań konserwacji woluminu.

• Plan zasilania - Twój serwer ma procesory 2,60 GHz i jest w zrównoważonym trybie zasilania - Uch ... chcesz, aby twoje procesory działały z pełną prędkością, prawda?

• Ostatnie uruchomienie serwera - 9 marca 2018 07:27

• Nazwa serwera - [zredagowany]

• Usługi

  • Usługa: SQL Server (MSSQLSERVER) działa na koncie usługi NT Service \ MSSQLSERVER. Czas ostatniego uruchomienia: 9 marca 2018 07:27. Typ uruchomienia: Automatyczny, obecnie uruchomiony.

  • Usługa: SQL Server Agent (MSSQLSERVER) działa pod kontem usługi LocalSystem. Czas ostatniego uruchomienia: nie pokazano. Typ uruchomienia: Automatyczny, obecnie uruchomiony.

• Ostatnie uruchomienie programu SQL Server - 9 marca 2018 06:27

• Usługa SQL Server - wersja: 13.0.4466.4. Poziom łatki: SP1. Aktualizacja zbiorcza: CU7. Edycja: edycja standardowa (wersja 64-bitowa). Grupy dostępności włączone: 0. Status menedżera grup dostępności: 2

• Serwer wirtualny - Typ: (HYPERVISOR)

• Wersja systemu Windows - korzystasz z całkiem nowoczesnej wersji systemu Windows: era Server 2012R2, wersja 6.3

Priorytet 254: Podsumowanie :

• Dziennik kapitana: spóźnij się i coś ...

Założę się, że skonfigurowałeś wirtualne procesory w taki sposób, że niektóre węzły CPU i / lub węzły pamięci są w trybie offline.

Pobierz sp_Blitz (zastrzeżenie: jestem jednym z autorów tego darmowego skryptu open source) i uruchom go:

sp_Blitz @CheckServerInfo = 1;

Poszukaj ostrzeżeń o tym, że węzły CPU i / lub pamięci są w trybie offline. SQL Server Standard Edition widzi tylko pierwsze 4 gniazda procesora i być może skonfigurowałeś maszynę wirtualną jako coś w rodzaju 6 dwurdzeniowych procesorów. Skończy się to problemem podobnym do tego, w jaki sposób 20-rdzeniowe limity Enterprise Edition ograniczają ilość dostępnej pamięci .

Jeśli chcesz udostępnić wynik sp_Blitz tutaj, możesz uruchomić go w ten sposób, aby wyprowadzić do Markdown, który możesz następnie skopiować / wkleić do swojego pytania:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Aktualizacja 2018/04/16 - potwierdzona. Podłączyłeś wyjście sp_Blitz (dzięki za to!) I rzeczywiście pokazuje, że masz procesor i węzły pamięci w trybie offline. Ktokolwiek zbudował maszynę wirtualną, skonfigurował ją jako 12 jedno-rdzeniowych procesorów, więc SQL Server Standard Edition widzi tylko 4 pierwsze gniazda (rdzenie) i dołączoną do nich pamięć.

Aby to naprawić, wyłącz maszynę wirtualną, skonfiguruj ją jako 2-gniazdową, 6-rdzeniową maszynę wirtualną, a następnie SQL Server Standard Edition zobaczy wszystkie rdzenie i pamięć. Zmniejszy to również twoje oczekiwania SOS_SCHEDULER_YIELD - teraz SQL Server wbija pierwsze 4 rdzenie, ale to wszystko. Po tej poprawce będzie mógł działać na wszystkich 12 rdzeniach.

Jako dodatek do planu działania Brenta Ozara chciałem podzielić się wynikami. Jak zauważył Brent, w VMware nieprawidłowo skonfigurowaliśmy maszynę wirtualną z 12 jednordzeniowymi procesorami. Spowodowało to, że pozostałe 8 rdzeni było niedostępnych dla programu SQL Server, w wyniku czego wystąpił problem z pamięcią opisany w moim pierwotnym pytaniu. Zeszłej nocy przełączyliśmy nasze usługi w tryb konserwacji, aby odpowiednio zmienić konfigurację maszyny wirtualnej. Nie tylko widzimy, jak pamięć wypełnia się w normalny sposób, ale jak zasugerował Brent, liczba oczekiwań spadła wykładniczo, a nasza ogólna wydajność programu SQL Server gwałtownie wzrosła. Konfiguracje vNUMA to teraz szczęśliwe małe komponenty, które przecinają nasze obciążenia.

Dla tych, którzy mogą korzystać z VMware vSphere 6.5, krótkie kroki w celu wykonania czynności opisanej przez Brent są następujące.

1. Zaloguj się do klienta vSphere Web Client dla klastra VMware i przejdź do maszyny wirtualnej obsługującej SQL Server. Twoja maszyna wirtualna musi być w trybie offline, aby dostosować konfiguracje procesora i pamięci.

2. W głównym okienku przejdź do Configure > VM hardware, kliknij Editprzycisk w prawym górnym rogu. Otworzysz menu kontekstowe, które ma Edit Settings. Dla porównania, poniższy obraz jest niepoprawną konfiguracją. Zauważ, że Cores per Socketustawiłem na 1. Biorąc pod uwagę ograniczenia SQL Server Standard Edition, jest to zła konfiguracja.

   

3. Poprawka jest tak prosta, jak dostosowanie Cores per Socketwartości. W naszym przypadku ustawiliśmy to 6tak, abyśmy mieli 2 Sockets. Dzięki temu SQL Server może wykorzystywać wszystkie 12 procesorów.

   

Ważna uwaga: nie należy ustawić wartość gdzie albo Number of Coresczy Socketsbędzie nieparzysta. NUMA uwielbia równowagę i zgodnie z ogólną zasadą musi być podzielna przez 2. Na przykład konfiguracja 4 rdzeni na 3 gniazda byłaby niezrównoważona. W rzeczywistości, jeśli miałbyś działać sp_Blitzz tego rodzaju konfiguracją, rzuciłoby o tym ostrzeżenie.

Rozdział 3.3 w architekturze Microsoft SQL Server na VMware vSphere (ostrzeżenie PDF) szczegółowo to opisuje. Praktyki przedstawione w oficjalnym dokumencie mają zastosowanie do większości wszystkich lokalnych wirtualizacji programu SQL Server.

Oto kilka innych zasobów, które skompilowałem podczas moich badań po poście Brenta:

• Wirtualizacja dużych baz danych - planowanie wydajności procesorów VMware

• Virtual Machine vCPU i vNUMA Rightsizing - Reguły praktyczne

• Oddzielenie rdzeni na gniazdo od wirtualnej topologii NUMA w vSphere 6.5

Zakończę przechwytywanie z Monitora RedGate SQL w ciągu ostatnich 24 godzin. Najważniejszym punktem jest wykorzystanie procesora i liczba oczekujących - wczoraj w godzinach szczytu mieliśmy do czynienia z dużym obciążeniem procesora i oczekiwaniami. Po tej prostej poprawce poprawiliśmy naszą wydajność dziesięciokrotnie. Nawet nasze dyskowe wejścia / wyjścia znacznie się zmniejszyły. Jest to pozornie łatwo przeoczone ustawienie, które może poprawić wydajność wirtualną o rząd wielkości. Przynajmniej było pomijane przez naszych inżynierów i kompletnego d'oh chwili.

Ponadto, zgodnie z MSDN , standard SQL Server jest ograniczony do 64 GB pamięci RAM. „Rozwiązaliśmy” ten problem, dzieląc bazę danych na wiele instancji, ale Twoja sytuacja może na to nie pozwolić.

Hmm 2016 wydaje się mieć 128 GB jako limit, ale podział instancji może być nadal opcją.