SQL Server tempdb na dysku RAM?

Nasza baza danych aplikacji dostawców wymaga bardzo TempDB.

Serwer jest wirtualny (VMWare) z 40 rdzeniami i 768 GB pamięci RAM, na którym działa SQL 2012 Enterprise SP3.

Wszystkie bazy danych, w tym TempDB, znajdują się na dyskach SSD poziomu 1 w sieci SAN. Mamy 10 plików danych tempdb, każdy wstępnie powiększony do 1 GB i nigdy nie rośnie automatycznie. To samo z plikiem dziennika 70 GB. Flagi śledzenia 1117 i 1118 są już ustawione.

sys.dm_io_virtual_file_stats pokazuje ponad 50 terabajtów odczytanych / zapisanych na danych tempdb i plikach dziennika w poprzednim miesiącu, z łącznym io_stall wynoszącym 250 godzin lub 10 dni.

W ciągu ostatnich 2 lat dostosowaliśmy już kod dostawcy i SP.

Teraz myślimy o umieszczeniu plików tempdb na dysku RAM, ponieważ mamy mnóstwo pamięci. Ponieważ tempdb ulega zniszczeniu / odtworzeniu po ponownym uruchomieniu serwera, jest idealnym kandydatem do umieszczenia w pamięci nietrwałej, która również zostaje wypłukana po ponownym uruchomieniu serwera.

Przetestowałem to w niższym środowisku i spowodowało to szybsze czasy zapytań, ale zwiększyło użycie procesora, ponieważ procesor wykonuje więcej pracy zamiast czekać na wolnym dysku tempdb.

Czy ktoś jeszcze umieścił tempdb na pamięci RAM w systemach produkcyjnych o wysokiej wydajności? Czy jest jakaś poważna wada? Czy są jacyś dostawcy, którzy wybierają lub unikają?

Po pierwsze, poprawka: upewnij się, że korzystasz z aktualizacji zbiorczej 10 z dodatkiem Service Pack 1 w wersji 10 lub nowszej. W SQL 2014 Microsoft zmienił TempDB, aby był mniej chętny do zapisywania na dysku , i wspaniale przeniosły go do wersji SP1 CU10 z 2012 r., Co może złagodzić dużą presję zapisu w TempDB.

Po drugie, uzyskaj dokładne liczby dotyczące opóźnienia. Sprawdź sys.dm_io_virtual_file_stats, aby zobaczyć średnie opóźnienie zapisu dla plików TempDB. Mój ulubiony sposób to:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Spójrz na sekcję statystyk plików i skup się na fizycznych zapisach. Dane SinceStartup mogą być nieco mylące, ponieważ obejmują również czasy działania CHECKDB, a to może naprawdę hamować twój TempDB.

Jeśli średnie opóźnienie zapisu wynosi ponad 3 ms, to tak, możesz mieć pamięć półprzewodnikową w swojej sieci SAN, ale nadal nie jest to szybkie.

Najpierw rozważ lokalne dyski SSD dla TempDB. Dobre lokalne dyski SSD (takie jak karty Intel PCIe NVMe, które są poniżej 2 tys. USD, zwłaszcza przy rozmiarach, które opisujesz) mają wyjątkowo małe opóźnienia, niższe niż można osiągnąć przy współużytkowaniu pamięci. Jednak w przypadku wirtualizacji ma to pewną wadę: nie można vMotion gości od jednego hosta do drugiego, aby zareagować na obciążenie lub problemy sprzętowe.

Rozważ dysk RAM jako ostatni. Przy takim podejściu istnieją dwa duże problemy:

Po pierwsze, jeśli naprawdę masz dużą aktywność zapisu TempDB, szybkość zmian w pamięci może być tak wysoka, że ​​nie będziesz w stanie vMotion gościć z jednego hosta na drugiego, nie wszyscy tego zauważą. Podczas vMotion musisz skopiować zawartość pamięci RAM z jednego hosta na drugi. Jeśli naprawdę zmienia się tak szybko, szybciej niż można go skopiować przez sieć vMotion, możesz napotkać problemy (szczególnie jeśli to okno jest związane z tworzeniem kopii lustrzanych, bloków awaryjnych lub klastra pracy awaryjnej).

Po drugie, napędy RAM to oprogramowanie. W testach obciążenia, które przeprowadziłem, nie byłem pod wrażeniem ich prędkości przy naprawdę dużej aktywności TempDB. Jeśli jest tak ciężki, że dysk SSD klasy korporacyjnej nie nadąża, to również będziesz opodatkowywał oprogramowanie pamięci RAM. Naprawdę będziesz chciał mocno to przetestować przed uruchomieniem - wypróbuj takie rzeczy, jak wiele jednoczesnych przebudowań indeksu na różnych indeksach, wszystkie przy użyciu sort-in-tempdb.

Tworzenie napędu RAM powinno być trywialne. Wiele rozruchowych napędów kciukowych i optycznych Linux tworzy napęd RAM i przechowuje tam pliki systemu operacyjnego. Główny system plików jest wtedy w pamięci. W systemie Windows w przeszłości dysk RAM został załadowany jako sterownik urządzenia w config.sys. Zwykle sterownik był ładowany w wysokiej pamięci. Moim zdaniem jest to bardzo dobre i proste rozwiązanie. Jeśli stworzyłem twoje rozwiązanie za pomocą napędu RAM, chciałbym o nim usłyszeć. Chciałbym zrobić coś podobnego, ale chciałbym robić zapisy do pamięci trwałej i przechowywać db w pamięci RAM. W moim przypadku mamy maszyny, które mogą zainstalować więcej pamięci RAM niż system operacyjny. Utworzenie dysku RAM przed załadowaniem systemu operacyjnego pozwoli na wykorzystanie pamięci RAM, której system inaczej by nie widział.