Odpowiem w dwóch częściach: po pierwsze „dlaczego tradycyjna odpowiedź dotycząca oddzielania sekwencyjnego od losowego często nie ma zastosowania”.
Następnie omówię potencjalne korzyści z oddzielania plików na dysku fizycznym systemu Windows oraz dodawania dodatkowych dysków vHBA i dystrybucji dysków fizycznych między nimi.
Oczekiwanie korzyści z oddzielenia losowego i sekwencyjnego operacji we / wy dysku na poziomie fizycznego dysku systemu Windows zwykle obejmuje urządzenia HDD do przechowywania danych. Zazwyczaj zakłada się również, że oddzielne dyski fizyczne systemu Windows oznaczają oddzielne urządzenia HDD. Chodzi o to, że niektóre zestawy dysków twardych obsługują głównie sekwencyjne operacje we / wy dysku i mają bardzo ograniczony ruch głowicy dysku (np. Dyski twarde obsługujące jeden zajęty txlog *), natomiast oddzielny zestaw dysków twardych obsługuje operacje we / wy dysku losowego.
Te założenia rzadko mają dziś miejsce - szczególnie w maszynie wirtualnej. Przede wszystkim, chyba że dyski fizyczne Windows maszyn wirtualnych są dyskami RDM, wiele z nich może znajdować się w jednym magazynie danych - lub może wiele magazynów danych znajduje się na jednej jednostce LUN hosta ESXi. To, co jest oddzielone od gościa, można wymieszać na poziomie hosta ESXi.
Powiedzmy jednak, że używane są RDM lub że każdy dysk fizyczny gościa znajduje się we własnym magazynie danych, na swojej jednostce LUN ESXi. Nawet wtedy oddzielna sekwencja od losowego io w gościu jest często mieszana w tablicy, ponieważ jednostki LUN prezentowane hostowi ESXi mogą pochodzić z tej samej pojedynczej puli urządzeń dyskowych. Prawie każda macierz pamięci masowej robi to teraz - wyłącznie lub jako opcja w celu ułatwienia zarządzania i zwiększenia wydajności macierzy / wykorzystania zasobów.
Wreszcie, tyle pamięci dzisiaj to cała pamięć flash lub hybrydowa pamięć flash + dysk twardy. Bez martwienia się głową, flash nie przejmuje się sekwencją losowych… nie przejmuje się także tkaniem IO.
Więc… to są wszystkie powody oddzielania sekwencyjnego od losowego, może nie być aż tak korzystne. Następnie dlaczego rozprzestrzenianie plików na dyskach fizycznych i dyski fizyczne na dyskach vHBA nadal może zwiększyć wydajność.
* Celowo wspomniałem o pojedynczym dzienniku transakcji w tym przykładzie dysku twardego. Gdy kilka oddzielnych strumieni sekwencyjnych operacji we / wy dysku (np. 8 zajętych dzienników transakcji) odbywa się na tych samych dyskach twardych - chyba że jakoś prawie cała aktywność znajduje się w pamięci podręcznej SAN - ciągły ruch głowy między kolejnymi ścieżkami operacji we / wy prowadzi do tkania operacji we / wy. Jest to specyficzny rodzaj przebijania głowicy dysku, który prowadzi do opóźnienia dysku, które jest „gorsze niż losowe”. Zdarza się na RAID5 i RAID10, chociaż RAID10 może tolerować tylko nieco więcej zmian w tym zakresie niż RAID5 przed znaczną degradacją.
Teraz - biorąc pod uwagę tę długą dyskusję o tym, w jaki sposób oddzielanie sekwencyjne od losowego może nie pomóc - w jaki sposób rozprzestrzenianie plików na dyskach fizycznych może nadal pomóc? W jaki sposób rozprzestrzenianie się fizycznych dysków między vHBA może pomóc?
Chodzi o kolejki dyskowe we / wy.
Dowolny fizyczny dysk Windows lub LogicalDisk może mieć jednocześnie do 255 zaległych operacji We / Wy dysku w tym, co perfmon zgłasza jako „Bieżąca kolejka dysku”. Z zaległych operacji we / wy dysku w kolejce dysku fizycznego storport może przekazać do 254 minidrivera. Ale minidriver może mieć zarówno kolejkę usług (przekazywaną do następnego niższego poziomu), jak i kolejkę oczekiwania. Można też powiedzieć, że storport obniża liczbę, którą przekazuje z 254.
W gościu VMware Windows sterownik pvscsi ma domyślną głębokość kolejki „urządzenie” 64, gdzie urządzenie jest dyskiem fizycznym. Tak więc chociaż perfmon może pokazywać do 255 operacji we / wy dysku w „bieżącej długości kolejki dyskowej” dla pojedynczego dysku fizycznego, tylko do 64 z nich zostanie przekazanych na następny poziom jednocześnie (chyba że zostaną zmienione wartości domyślne).
Ile dyskowych operacji we / wy może być wyjątkowych dla jednegozajęty dziennik transakcji na raz? Cóż, zapisy dziennika transakcji mogą mieć rozmiar do 60 KB. Podczas ETL na dużą skalę często widzę każdy zapis na txlog przy 60kb. Program zapisujący txlog może mieć do 32 zapisów o wielkości 60 kb w stosunku do jednego txlog jednocześnie. Co jeśli mam zajęty txlog przemieszczania i zajęty dw txlog na tym samym dysku fizycznym z domyślnymi ustawieniami VMware? Jeśli oba txlogs osiągają maksimum przy 32 zaległych zapisach 60kb każdy, ten dysk fizyczny ma głębokość kolejki wynoszącą 64. Teraz… co, jeśli na dysku fizycznym znajdują się również pliki flatfile jako źródło ETL? Cóż ... między odczytami do plików płaskich a zapisem txlog musieliby skorzystać z kolejki oczekiwania, ponieważ tylko 64 może wyjść na raz. W przypadku baz danych z takimi zajętymi dziennikami txlog, czy to fizycznymi, czy wirtualnymi, polecam txlog na jego własnym dysku fizycznym, z niczym innym na dysku fizycznym. Zapobiega to kolejkowaniu na tym poziomie, a także eliminuje wszelkie obawy związane z zawartością przeplatania wielu plików (co jest obecnie znacznie, znacznie mniejszym problemem).
Ile dyskowych operacji we / wy może być zaległych w pliku wiersza jednocześnie (z perspektywy programu SQL Server niekoniecznie przesyłane na niższe poziomy)? Tak naprawdę nie ma limitu w samym SQL Server (który zresztą znalazłem). Ale zakładając, że plik znajduje się na jednym fizyczny Windows (nie polecam korzystania paski dysków dynamicznych SQL Server, to temat na inny czas), nie jest ograniczona. To 255, o których wspomniałem wcześniej.
Dzięki magii ponownego uruchamiania programu SQL Server i asynchronicznego we / wy widziałem 4 równoległe zapytania, z których każde działa na dysku szeregowym o łącznej „bieżącej długości kolejki dyskowej” ponad 1200! Z powodu limitu 255 nie jest to nawet możliwe w przypadku całej zawartości pliku wierszy na jednym dysku fizycznym. Było to przeciwko podstawowej grupie plików z 8 plikami, każdy na własnym dysku fizycznym.
Odczyty readahead mogą być bardzo agresywne i mogą obciążać kolejki We / Wy. Mogą być tak agresywne, że inne pliki wierszy odczytują i zapisują, czekając. Jeśli dzienniki transakcji znajdują się na tym samym dysku fizycznym co pliki wierszy, podczas równoczesnych odczytów readahead i zapisów w txlog bardzo łatwo jest czekać. Nawet jeśli to oczekiwanie nie jest na poziomie „bieżącej długości kolejki dyskowej”, może czekać w kolejce urządzeń (domyślnie 64 z pvscsi).
Odczyty kopii zapasowych względem plików wierszy mogą być również agresywne, szczególnie jeśli liczba buforów została dostrojona w celu maksymalizacji przepustowości kopii zapasowej.
Jest jeszcze jeden typ SQL Server io, o którym należy pamiętać, rozważając izolację txlogów: wyciek zapytania do tempdb. Kiedy ma miejsce wyciek zapytania, każde rozlane działanie zapisuje do tempdb. Masz wielu równoległych pracowników, którzy przelewają się jednocześnie? To może być dość obciążeniem zapisu. Utrzymanie zajętego txlog i ważnych plików wierszy z dala od tego może być naprawdę pomocne :-)
Teraz można zmienić domyślną głębokość kolejki urządzeń dla sterownika pvscsi. Domyślnie jest to 64 i może być ustawione na wartość 254, co jest najbardziej znaczącym przechowywaniem. Ale uważaj, zmieniając to. Zawsze zalecam wyrównanie głębokości kolejki urządzenia-gościa z bazową głębokością kolejki LUN hosta ESXi. I ustawianie głębokości kolejki LUN hosta ESXi dla najlepszych praktyk tablicy. Korzystasz z EMC VNX? Głębokość kolejki LUN hosta powinna wynosić 32. Gość używa RDM? Wspaniały. Ustaw głębokość kolejki urządzenia pvscsi gościa na 32, aby była zgodna z głębokością kolejki LUN hosta ESXi. EMC VMAX? Zazwyczaj 64 na poziomie hosta ESXi, 64 na gościa. Pure / Xtremio / IBM FlashSystem? Czasami głębokość kolejki LUN hosta będzie ustawiona na 256! Śmiało, ustaw głębokość kolejki urządzeń pvscsi na 254 (maks. Możliwe).
Oto link z instrukcjami.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Link mówi również o stronach żądających - WhatAreThose ?? Określają głębokość kolejki dla samego adaptera pvscsi. Każda strona zawiera 32 miejsca w głębokości kolejki adaptera. Domyślnie strona żądań wynosi 8 dla głębokości kolejki adaptera wynoszącej 256. Można ją ustawić na 32 dla 1024 gniazd głębokości kolejki adaptera.
Powiedzmy, że wszystko jest domyślnie. Mam 8 fizycznych dysków z plikami wierszy, a SQL Server jest lekko zajęty. Średnio 32 „bieżąca długość kolejki dyskowej” w poprzek 8, i żadna nie jest większa niż 64 (wszystko pasuje do różnych kolejek usług urządzenia). Świetnie - daje 256 OIO. Pasuje do kolejek usług urządzenia, pasuje do kolejek usług adaptera, więc wszystkie 256 wychodzą z gościa do kolejek na poziomie hosta ESX.
Ale… jeśli sprawy stają się trochę bardziej zajęte, więc średnio 64 z kolejką niektórych dysków fizycznych aż do 128. W przypadku urządzeń z ponad 64 zaległymi nadwyżkami jest kolejka oczekiwania. Jeśli w kolejce usług urządzeń na 8 dyskach fizycznych znajduje się więcej niż 256, nadwyżka występuje w kolejce oczekiwania do momentu otwarcia gniazd w kolejce usług adaptera.
W takim przypadku dodanie kolejnego vHBA pvscsi i rozłożenie fizycznych dysków między nimi podwaja całkowitą głębokość kolejki adaptera do 512. W tym samym czasie z gościa na hosta można przekazać więcej.
Coś podobnego można osiągnąć, pozostając na jednym adapterze pvscsi i zwiększając liczbę stron żądających. Przejście do 16 dałoby 512 miejsc, a 32 daje 1024 miejsc.
Jeśli to możliwe, zalecam poszerzenie (dodanie adapterów) przed głębokim (zwiększenie głębokości kolejki adaptera). Ale… na wielu najbardziej obciążonych systemach należy wykonać jedno i drugie: umieścić 4 gości vHBA na gościu i zwiększyć liczbę stron żądających do 32.
Istnieje również wiele innych rozważań. Rzeczy takie jak sioc i adaptacyjne ograniczanie głębokości kolejki, jeśli używane są vmdks, konfiguracja wielościeżkowości, konfiguracja adaptera ESXi poza głębokością kolejki LUN itp.
Ale nie chcę przedłużać mojego powitania :-)
Lonny Niederstadt @sqL_handLe
