dlaczego io_stall_writes_ms jest o wiele wyższy dla tempdb?

Mamy pliki danych użytkownika i systemu na tym samym dysku. (Io_stall_write_ms / (1.0 + num_of_writes)) jest poniżej 2 dla plików użytkownika, ale pliki tempdb mają zwykle ponad 400. Widzę to na kilku serwerach i jestem ciekawy, czy istnieje powód, dla którego zapisywanie w tempdb zajmuje więcej czasu niż zwykły plik danych bazy danych.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Dziękuję Ci,

Krótka odpowiedź: Widzenie wyższych przeciągnięć we / wy może samo w sobie stanowić problem. Jeśli masz problem, musisz sprawdzić więcej informacji. To wydaje się trochę wysokie, tak, ale cierpisz? Jeśli tak, to prawdopodobnie dlatego, że albo twój system IO nie obsługuje poprawnie obciążenia (ponieważ nie może, ponieważ masz wszystko na jednym dysku lub z innego powodu) lub robisz za dużo w TempDB (zmieniając pierwszy problem - wydajność IO - jest to prawdopodobnie łatwiejsza i bardziej wydajna poprawka, ale najpierw ustal, czy masz problem)

Dłuższa dyskusja / odpowiedź:

Tutaj grają dwa pytania -

1.) Co mam zrobić, gdy widzę wysokie przeciągnięcia we / wy?

Po pierwsze, „wysoki” jest w oku patrzącego. Gdybyś zapytał 10 DBA, co jest „zbyt wysokie” dla stoisk IO, prawdopodobnie dostałbyś 2-3 różne odpowiedzi z liczbami, 5-6 odpowiedzi „To zależy” i jedno puste spojrzenie. Moje założenie jest takie, że średnia 400 ms jest tutaj potencjalnie zbyt wysoka, szczególnie gdy inne DB mają 2 ms lub mniej dla średniego czasu przeciągnięcia.

Bez względu na to, która baza danych widzi wysokie kabiny, powinieneś podejść do niej w ten sam sposób. Stoisko We / Wy to brzmi ... Prośba We / Wy trwa dłużej niż oczekiwano ... Stalling. Te się zdarzają. Zdarza się to cały czas w systemie z zasobami współdzielonymi i zasobami skończonymi (tak naprawdę wszystkie nasze systemy). Stają się problemem, gdy przeciągnięcia stają się problemami z wydajnością lub prowadzą do nich. Więc ufam, że szukasz tutaj jako proaktywnej części monitorowania lub ponieważ masz problemy z wydajnością, które rozwiązujesz. Nie chcemy też zgubić się w samych straganach IO. Patrzymy na kawałek układanki, a nie na duży obraz. Spojrzenie na statystyki oczekiwania lub statystyki plików może być kłopotliwe od czasu ostatniego restartu SQL, ponieważ patrzysz cały czas, a niektóre okno konserwacji lub okno dużego obciążenia może wypaczać liczniki. Upewnij się więc, że spojrzysz na pełny obraz.

Ale gdy podejrzewam, że mam problem z wydajnością dysku lub widzę coś w zapytaniu takim jak ten, zwykle wykonuję proces, który wygląda następująco:

1. Spójrz na statystyki oczekiwania na serwerze. @swasheck udostępnił świetny link jako komentarz w odpowiedzi poniżej. To zabierze Cię do postu Paula Randala na temat przeglądania i analizowania statystyk oczekiwania w SQL Server. Idź tam. Jakiego rodzaju czekasz? Czy widzisz czeka związanych z realizacją IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, itd.?). Jeśli to zrobisz, jest to kolejna wskazówka, że ​​masz problemy z wydajnością związane z IO, podobnie jak utknięcie IO. Ale daje ci to inną formę porozumienia.
2. Spójrz na wydajność IO. W szczególności spójrz do perfmon na Physical Disk:Avg Disk Sec/Readi Avg Sec Disk Sec/Writeliczniki. Mierzą one twoje opóźnienie. Obserwuj te liczniki w okresie czasu zapisanym w pliku dziennika wydajności. Co widziałeś dla średnich? Jeśli widzisz liczby powyżej 0,020 sekundy (20 ms), może to być problem. Jeśli widzisz numery powyżej 40-50 ms średnio lub więcej, jest to bardziej jednoznaczne wskazanie problemu. Spójrz też na swoje kolce? Jak wysoko i jak długo trwają? Jeśli zauważysz wzrosty do setek ms i trwają one przez dziesiątki lub dziesiątki sekund lub dłużej i / lub zdarzają się często, to bardziej prawdopodobne jest, że będziesz mieć problem z wydajnością IO dla twojego obciążenia.
3. Spójrz na swoją konfigurację IO. Co to jest? Lokalne dyski? SAN? Macierz pamięci? Jakiego rodzaju i IOP powinieneś zobaczyć z tego? Czy to wystarczy do tego, co próbujesz zrobić? Być może Twoje IO było niewymiarowe ze względu na obciążenie pracą. Nie patrz tylko na fizyczne wrzeciona, ustawienia RAID itp. Spójrz na swoje ścieżki do dysków. Czy przepychasz wszystko przez jedno łącze 1 GB, które udostępniasz dużej ilości ruchu? Czy możesz spojrzeć na wskaźniki wydajności dysku z perspektywy magazynu.

( Uwaga: w przypadku tej analizy statystyk oczekiwania i analizy perfmon - spójrz na różne okresy i rodzaj użytkowania. Czy masz inne statystyki użytkowania w nocy niż w ciągu dnia? Okna przetwarzania wsadowego? Okna konserwacji, w których odbudowuje się wiele indeksów? Spójrz na te narzędzia w każdym z tych okresów i zrozum, co widzisz dla każdego)

Kolejna kwestia wydajności IO tutaj -

• Powiedziałeś, że systemowe DB i DB użytkownika są wspólne. Czy to produkcja? Jeśli tak, nie zawsze jest to najlepszy scenariusz. Czy udostępniasz również pliki dziennika i pliki danych na tych samych dyskach? To też nie jest najlepszy scenariusz. Co jeszcze dzieli tę pamięć? W świecie, w którym martwisz się wrzecionami, grupami rajdowymi i dyskami i musisz podejmować decyzje o tym, kto otrzyma dyski o najwyższej wydajności, zazwyczaj (ogólnie rzecz biorąc, które nie są świetne w świecie DB ale ten ma tendencję do trzymania się prawdy) idź z moim najszybszym i najbardziej oddanym TempDB (więcej na ten temat poniżej), następnie pliki dziennika, a następnie pliki danych. W świecie, w którym masz duży stos dysków na urządzeniu takim jak NetApp, Dell Equal Logic lub EMC VNX itp.

2.) Z jakich powodów TempDB może być wyższy?

Tak więc TempDB jest bazą danych i może mieć przeciągnięcia we / wy jak każda inna baza danych, jak właśnie omówiłem. Ale z jakich powodów TempDB może mieć wyższe odczyty? (nie wyczerpujące, z zadowoleniem przyjmuję uzupełnienia lub przemyślenia w edycjach, innych odpowiedziach lub komentarzach) -

1. Z powodu twojego kodu - czy celowo używasz TempDB w swoim kodzie? Wiele tabel tymczasowych i zmiennych tabel utworzonych i zniszczonych? Robisz tak wiele rzeczy w TempDB? Nie jest to wcale złe ani dobre, ale możesz na to spojrzeć i zrozumieć swój celowy wzorzec użycia TempDB.
2. TempDB to współdzielony koń roboczy - TempDB to jedna baza danych, która jest używana jako tymczasowa przestrzeń dla obiektów tymczasowych zdefiniowanych przez użytkownika oraz różnych tabel roboczych i operacji używanych przez całą instancję SQL. Ile jest baz danych użytkowników? Jakie obciążenie widzisz ogólnie? TempDB jest jednym zasobem do udostępniania wszystkich rzeczy.
3. Niewystarczające zapytania i niewystarczająca pamięć - Być może istnieją zapytania, które nie używają indeksów wystarczająco mocno lub wykonują duże operacje skanowania i sortowania. Duże operacje skrótu, a pamięć na serwerze nie jest na to wystarczająca. Operacje te „przeniosą się” do TempDB jako stoły robocze za kulisami. Czasami można tego uniknąć, przeglądając plany zapytań i indeksując lub dostosowując zapytania. Czasami to się zdarza (bardziej przypominam obciążenia magazynowe). Jeśli masz wystarczającą ilość pamięci, może to pomóc, ale te zapytania mogą się czasem rozlewać. Zobacz też.
4. Czy używasz poziomu izolacji zatwierdzonego odczytu migawki z dużą liczbą aktualizacji w swoim systemie? Może to również spowodować zwiększenie aktywności TempDB.

Chodzi o to, że - TempDB jest używany na wiele sposobów i wcale mnie nie dziwi, że jest to jedna z twoich najbardziej obciążonych, jeśli nie najbardziej obciążonych, baz danych. Nie zaskakuje mnie również, gdy widzę, że ma największą liczbę i najwyższą średnią liczbę przeciągnięć ze wszystkich baz danych w witrynie klienta. Czasami jest to charakter obciążenia pracą. Spojrzenie na niektóre z rzeczy, o których tu wspomniałem, z pewnością pomoże ci ustalić, czy liczby te wskazują na problem, a jeśli tak, to jak głębiej go rozwiązać.

TempDB jest współużytkowany przez wszystkie bazy danych w instancji. Dlatego w TempDB może czasami występować spór o niektóre strony: SGAM , GAM i PFS . W skrócie, strony te śledzą, co do tej pory było używane w TempDB i gdzie jest miejsce na nowe zastosowania.

Zazwyczaj rozwiązuje się to poprzez dodanie wielu plików danych do TempDB. Istnieje kilka różnych filozofii dotyczących poprawnej liczby, ale wszyscy zgadzają się, że powinieneś mieć więcej niż jedną.

Oto kilka zapytań do uruchomienia ...

Ten pokaże Ci, ile plików ma TempDB i gdzie się znajdują.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Ten pokaże ci, ile masz procesorów i rdzeni.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Ten pokaże Ci, ile masz węzłów NUMA i rdzeni na węzeł NUMA.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Ten pokazuje, które strony oczekują w TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Oto artykuł, który bardziej szczegółowo omawia problem rywalizacji stron.

OK, więc teraz część filozofii ... :-)

Dla mnie, jeśli jestem w systemie SMP , chcę tylko tyle plików, ile wynosi połowa wszystkich rdzeni .

Jeśli korzystam z systemu NUMA , chcę tylko tyle plików, ile rdzeni przypada na węzeł NUMA .

Rzadko jednak widzę jakąkolwiek poprawę dla posiadania więcej niż czterech plików dla TempDB. Zwykle zaczynam od czterech i monitoruję rywalizację, jak wyjaśniono w artykule, do którego linkowałem.

Jeśli nadal widzę problemy, dodałbym jeszcze dwa. Sprawdź ponownie, dodaj więcej i powtarzaj, aż spór zniknie.