Jedną z rzeczy, która jest jednocześnie świetna i przerażająca w Internecie, jest to, że gdy coś zostanie umieszczone w eterze, w zasadzie nigdy nie zniknie. (Pewnego dnia politycy zdadzą sobie z tego sprawę. Możemy łatwo sprawdzić ich spójność.) Ze względu na długowieczność treści publikowanych w Internecie, wiele tematów dotyczących dostrajania wydajności staje się „zombiami”. Strzelamy do nich, ale one wracają!
Innymi słowy, te stare zalecenia były sugerowana najlepsza praktyka dawno temu, dla określonej wersji programu SQL Server, ale obecnie nieodpowiednia dla nowszej wersji. Nierzadko zdarza mi się, gdy przemawiam na konferencji, spotykać kogoś, kto wciąż trzyma się ustawień i technik, które nie były dobrymi praktykami od czasów SQL Server 2000. Przewodnik operacyjny SQL Server 2000 dotyczący pojemności/pamięci zawiera wiele „ zalecenia dotyczące najlepszych praktyk”, które były bardzo specyficzne dla wersji i nie mają już zastosowania.
Oto przykład. % Disk Time i Disk Queue Length Liczniki PerfMon były zdecydowanie zalecane jako kluczowe wskaźniki wydajności dla wydajności we/wy. SQL Server generuje wiele operacji we/wy na dyskach przy użyciu metody rozpraszania/zbierania, aby zmaksymalizować wykorzystanie podsystemu we/wy opartego na dyskach. Takie podejście prowadzi do krótkich serii długich kolejek głębokości podczas punktów kontrolnych i odczytu z wyprzedzeniem dla wystąpienia SQL Server. Czasami obciążenie serwera jest tak duże, że dysk nie jest w stanie nadążyć z wepchniętymi na niego operacjami we/wy, a gdy tak się stanie, zobaczysz również długie kolejki. Scenariusz krótkich serii nie stanowi problemu. Problemem jest zwykle scenariusz wydłużania się kolejki. Czy to dobra praktyka?
Słowem, nie za bardzo.
Liczniki te mogą być nadal przydatne w przypadku wystąpienia SQL Server, które ma tylko jeden dysk twardy (chociaż to nadmiernie rzadkie w dzisiejszych czasach). Dlaczego?
Licznik PerfMon % Disk Time jest fałszywym wskaźnikiem wydajności z kilku powodów. Nie uwzględnia asynchronicznych żądań we/wy. Nie może określić rzeczywistego profilu wydajności bazowego zestawu RAID, ponieważ zawierają one wiele dysków. Licznik PerfMon Disk Queue Length jest również w większości bezużyteczny, z wyjątkiem serwerów SQL Server z pojedynczym dyskiem fizycznym, ponieważ pamięć podręczna kontrolera dysku twardego zaciemnia, ile operacji we/wy faktycznie oczekuje w kolejce, czy nie. W rzeczywistości niektóre dyski twarde mają nawet małe pamięci podręczne do zapisu, co jeszcze bardziej dezorientuje, czy we/wy rzeczywiście jest ustawione w kolejce, w pamięci podręcznej gdzieś między systemem operacyjnym a dyskiem, czy też w końcu dotarło do końca do pamięci CMOS na dysku.
Lepsze liczniki We/Wy PerfMon
Zamiast korzystać z tych liczników PerfMon, użyj Avg Disk Reads/sec , Avg Disk Writes/sec i Avg Disk Transfers/sec do śledzenia wydajności podsystemów dyskowych. Liczniki te śledzą średnią liczbę operacji we/wy odczytu, operacji we/wy zapisu oraz połączonych operacji we/wy odczytu i zapisu, które wystąpiły w ciągu ostatniej sekundy. Czasami lubię śledzić te same metryki według ilości danych, a nie szybkości operacji we/wy. Aby więc uzyskać te dane, możesz wypróbować te liczniki PerfMon specyficzne dla woluminu: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec i Avg Disk Write Bytes/sec .
W celu uzyskania wydajności we/wy serwera SQL Server użyj widoków zarządzania dynamicznego (DMV)
A jeśli nie mieszkasz w jaskini, upewnij się, że korzystasz z widoków dynamicznego zarządzania (DMV) programu SQL Server, aby sprawdzić wydajność we/wy dla najnowszych wersji programu SQL Server. Niektóre z moich ulubionych DMV dla I/O to:
- sys.dm_os_wait_stats
- sys.dm_os_waiting_tasks
- sys.dm_os_performance_counters
- sys.dm_io_virtual_file_stats
- sys.dm_io_pending_io_requests
- sys.dm_db_index_operational_stats
- sys.dm_db_index_usage_stats
Jak więc śledzisz metryki wydajności we/wy? Którego używasz?
Nie mogę się doczekać wiadomości od Ciebie!
Miłej zabawy,
-Kev
–Obserwuj mnie na Twitterze!
