Głównym celem tej witryny bloga jest wydajność w środowisku SQL Server. Można argumentować, że wydajność zaczyna się od projektowania baz danych i aplikacji. Ale możesz też argumentować, że posiadanie odpowiednich dostępnych zasobów jest niezbędne dla dobrej wydajności. Podczas całej dyskusji na temat właściwych zasobów (jaki model procesora, ile pamięci, jaki rodzaj pamięci) czasami zaniedbujemy planowanie pojemności:wykorzystanie danych, które posiadamy podejmować świadome decyzje dotyczące tego, czego potrzebujemy . Planowanie pojemności to nie tylko określenie, ile potrzebujemy miejsca na dysku, ale obejmuje również zasoby, które musi mieć instancja SQL Server, aby obsłużyć obciążenie.
Nowe czy istniejące?
Planowanie pojemności dla nowego rozwiązania jest naprawdę trudne. Musisz oszacować obciążenie pracą na podstawie informacji zebranych od firmy. Oznacza to, że musisz zadać trudne pytania o to, ile danych będą oczekiwać w pierwszym miesiącu, pierwszych sześciu miesiącach i pierwszym roku. Kiedy pojawia się nowe rozwiązanie, często jest to OSTATNIA rzecz, o której myśli firma, więc bardzo często otrzymasz niejasne odpowiedzi. W przypadku nowego rozwiązania naprawdę musisz się starać. Nie wyrywaj włosów, próbując uzyskać dokładne liczby.
Jeśli rozwiązanie pochodzi od dostawcy, należy poprosić dostawcę o zalecenia dotyczące planowania, dotyczące zarówno potrzebnego miejsca, jak i potrzebnych zasobów. Przyznaję, mogą nie mieć tych danych, ale nie dostajesz tego, o co nie prosisz. Nigdy nie zaszkodzi spróbować.
[Bonus:Jeśli dostawca nie ma żadnych informacji do przekazania, czy nie byłoby pomocne, gdy po uruchomieniu systemu przez kilka miesięcy wyślesz mu swoje dane… takie jak posiadany sprzęt? i jak wygląda obciążenie? Nie musi to być 20-stronicowy opis, ale opinie mogą popchnąć ich w kierunku większej proaktywności w przyszłości.]
Jeśli chodzi o istniejące rozwiązanie, jeśli masz problem z wydajnością lub chcesz uaktualnić sprzęt, będziesz chciał przechwycić informacje o obecnym środowisku, aby zaplanować nowe.
Pamięć
Planowanie kwoty potrzebnej przestrzeni dyskowej jest dość proste, wymaga jedynie planowania z góry. W moich proaktywnych artykułach dotyczących sprawdzania kondycji programu SQL Server omawiam monitorowanie miejsca na dysku i dołączam zapytanie w celu przechwycenia informacji o plikach. To zapytanie przechwytuje rozmiar plików bazy danych dla instancji oraz zajęte miejsce. Konieczna jest zmiana trendu tych danych w czasie, co nie oznacza kilku tygodni. Chcesz zobaczyć, jak pliki zmieniają się w ciągu miesięcy, prawdopodobnie przez okres od jednego do dwóch lat, ponieważ wzorce użytkowania aplikacji mogą się zmieniać. Informacje te są łatwe do uchwycenia, wymagają niewiele miejsca do przechowywania i są nieocenione jako punkt odniesienia podczas zamawiania pamięci masowej. Jeśli możesz podać dane ilościowe o rozwoju systemu, masz znacznie większą szansę na uzyskanie potrzebnej przestrzeni z góry, zamiast prosić o nią później. A kiedy prosisz o miejsce, pamiętaj, aby uwzględnić tempdb w swoich obliczeniach.
Zasoby sprzętowe
procesor
Optymalizacja wydajności procesora to nie tylko liczba posiadanych procesorów, ale także model i obciążenie (np. hurtownia danych z dużymi zapytaniami równoległymi w porównaniu z OLTP z zapytaniami szeregowymi). Dzięki tym informacjom i niewielkiej pomocy Glenna możesz określić najlepszy procesor dla swojego serwera. Nie zapomnij wziąć pod uwagę kosztów licencji i ograniczeń w zależności od wersji SQL Server!
Pamięć
Pamięć jest stosunkowo niedroga i zalecamy, aby zawsze kupować maksymalną ilość pamięci, jaką może pomieścić serwer. Odczytywanie danych z pamięci jest znacznie szybsze niż odczytywanie ich z dysku, więc im więcej danych mieści się w pamięci, tym lepiej. Pamiętaj, że cała baza danych nie ma zmieścić się w pamięci. Potrzebujesz tylko roboczego zestawu danych, który zmieści się w pamięci. Rozważ bazę danych o pojemności 2 TB. Jest mało prawdopodobne, że w scenariuszu OLTP wszystkie 2 TB są dostępne każdego dnia. Zazwyczaj dostępne są tylko najnowsze dane – być może tylko ostatnie 30 lub 60 dni. To są dane, które muszą zmieścić się w pamięci. Ale oczywiście rzadko widzimy czyste środowisko OLTP, często jest to środowisko mieszane, ponieważ użytkownicy lubią uruchamiać raporty na dużych zestawach danych, a nie ma hurtowni danych ani kopii raportów bazy danych, więc mają do uruchomienia raportów z produkcji. To komplikuje wymagania dotyczące pamięci. Czasami potrzebujesz tych starszych danych w pamięci, ale czasami nie. Ważne jest, aby zrozumieć obciążenie pracą; jakie typy zapytań są wykonywane w bazie danych?
Jeśli używasz wersji Standard Edition, sprawdź, czy masz więcej pamięci na serwerze niż maksymalna obsługiwana pamięć. Na przykład w programie SQL Server 2014 i nowszym w wersji Standard Edition maksymalna ilość pamięci, którą można przydzielić do puli buforów (poprzez ustawienie maksymalnej pamięci serwera) wynosi 128 GB. Dlatego chcesz mieć więcej pamięci na serwerze (np. 160 GB), aby ustawić maksymalną pamięć serwera na najwyższą możliwą wartość 128 GB i nadal mieć dostępną pamięć dla systemu operacyjnego i innych procesów SQL Server. Co więcej, dzięki SQL Server 2016 SP1 Standard Edition można używać OLTP w pamięci, z limitem 32 GB na bazę danych. Jest to wartość powyżej maksymalnej wartości pamięci serwera, więc jeśli planujesz korzystać z tej funkcji, kup odpowiednio pamięć.
Pamięć
Kiedy mówimy o wymaganiach dotyczących wydajności dla pamięci masowej, często słyszysz, jak ludzie mówią o IOPS (operacje wejścia/wyjścia na sekundę). W rzeczywistości ten artykuł został zainspirowany pytaniem od widza, który obejrzał mój kurs Pluralsight dotyczący benchmarkingu i bazowania. Pytanie brzmiało:„Jak skorelować liczniki Monitora wydajności dla odczytów i zapisów na sekundę z połączeniami użytkowników, aby oszacować liczbę operacji we/wy na użytkownika?” Odczyty i zapisy na sekundę to operacje wejścia/wyjścia, więc mamy te dane dostępne za pośrednictwem PerfMon na poziomie instancji i to jest to, czego używasz do definiowania wymagań IOPS dla instancji.
Jeśli jednak wiesz, że czyta i pisze i połączenia użytkowników, wtedy możesz trochę policzyć i obliczyć liczbę IOPS na użytkownika. Jest to przydatne, jeśli planujesz rozwijać rozwiązanie i dodawać więcej użytkowników. Chcesz mieć pewność, że rozwiązanie będzie się skalować, a jedną z dostępnych opcji jest pobranie obliczonych IOPS na użytkownika na podstawie liczby X użytkowników, a następnie oszacowanie IOPS wystąpienia dla Y użytkowników. Teraz przy tych obliczeniach robimy wiele założeń. Wychodzimy z założenia, że sposób, w jaki nowe połączenia korzystają z systemu, jest taki sam, jak obecnie – może tak być, ale nie musi, w końcu nie będziesz wiedział, dopóki system nie będzie na miejscu. Kiedy rozumiesz tę wartość (odczyty + zapisy / połączenia użytkowników =średnia IOPS na użytkownika), wiesz, jak oszacować IOPS dla rozwiązania na podstawie przewidywanych połączeń użytkowników.
Następnie przekazujesz te informacje osobie odpowiedzialnej za przechowywanie, aby omówić potencjalne dostępne konfiguracje. Możesz obliczyć maksymalną liczbę IOPS dla konfiguracji dysku, pod warunkiem, że masz informacje o dyskach (np. liczbę dysków, prędkość, rozmiar i konfigurację RAID). Możesz przetestować przepustowość IO dla dysku za pomocą CrystalDiskMark, chociaż może to nie być możliwe, jeśli nie zdecydowano o przechowywaniu. Jednak po uruchomieniu należy przejść przez te testy, aby upewnić się, że IOPS dla danego dysku może sprostać oczekiwanym obciążeniom.
IOPS to tylko jeden ze sposobów oceny wydajności pamięci masowej. Zrozum, że te dane mówią ci, jak dużo IO występuje, a najlepiej, jeśli znasz IOPS i masz pamięć masową, aby spełnić wymagania, wtedy opóźnienie powinno być minimalne. Ale opóźnienie ma wpływ na wydajność. Aby określić, jakie opóźnienie istnieje, musisz użyć narzędzia takiego jak DiskSpd, aby przetestować pamięć masową. Glenn ma świetny artykuł, który wyjaśnia, jak analizować wydajność IO, a następnie kolejny artykuł o tym, jak używać DiskSpd do testowania go, aby zrozumieć opóźnienia. Gorąco polecam przejrzenie obu artykułów, jeśli wcześniej nie patrzyłeś na pamięć i wydajność.
Wniosek
Planowanie pojemności to coś więcej niż tylko wiedza, ile miejsca potrzebujesz na pliki bazy danych. Musisz zrozumieć obciążenie i wymagania dotyczące procesora, pamięci i zasobów dyskowych. Aby to zrobić, potrzebujesz danych… co oznacza, że potrzebujesz przechwytywania linii bazowych. Moja pierwsza sesja w społeczności SQL Server odbyła się w grudniu 2010 roku i dotyczyła tematu linii bazowych. Sześć lat później wciąż mówię o ich znaczeniu i wciąż słyszę od ludzi, że nie mają tych liczb. Jeśli chcesz wykonać inteligentne, ukierunkowane planowanie wydajności, musisz zebrać odpowiednie dane… w przeciwnym razie tylko zgadujesz.
