Kluczowy wskaźnik wydajności bazy danych

Наша команда-партнер Artmisto

Kluczowy wskaźnik wydajności (zwany dalej KPI) bazy danych jest jedynym pełnoprawnym wskaźnikiem zdolnym do oceny ogólnej wydajności bazy danych na poziomie zarządzania w czasie.

Jednorodność jest krytycznym czynnikiem przy ocenie każdego KPI. Określenie linii bazowej, a następnie ciągłe powtarzanie tego samego pomiaru jest jedynym sposobem na identyfikację trendów i ocenę wyników optymalizacji. W takim przypadku testy należy powtarzać w regularnych odstępach czasu.

Kluczowy wskaźnik wydajności powinien porównywać dane uzyskane w „czystym” środowisku testowym, a także rzeczywiste dane, biorąc pod uwagę efekt skalowania systemu. Aby uzyskać prawdziwy wskaźnik KPI, zespół programistów musi stawiać szczególne wymagania dotyczące testów i metod obliczeniowych. Zalecam skalowanie wyników trzech kolejnych testów, aby uzyskać jedną trzecią w wyniku każdego z nich i że ich suma, tj. oryginalna pełna metryka to jedna, jak pokazano w arkuszu roboczym i schemat na rys. 49,7.

Rys 49,7. Kluczowy wskaźnik wydajności jest obliczany na podstawie trzech testów w programie Excel

Pełna miara wydajności bazy danych w formie skoroszytu programu Excel jest dostępna na stronie książki.

Okresowe testy wydajności

Testy okresowe mierzą wydajność bazy danych w rzeczywistych warunkach na podstawie scenariusza i bazy danych utworzonej podczas fazy testowania. Środowisko wykonawcze można zarejestrować w zmiennych T-SQL, a także w SQL Server Profiler.

Jeśli architektura wykorzystuje poziom abstrakcji danych, należy wykonać do niej wszystkie połączenia testowe. Jeśli baza danych używa bardziej nietypowego podejścia przy użyciu modelu klient / serwer, testowanie będzie musiało mieszać różne zapytania. Jeśli baza danych korzysta z architektury zorientowanej na usługi sieciowe, naturalnie, prośby będą składane specjalnie dla tych usług. Aby zrównoważyć ekstrakcję i aktualizację danych dla tabel, należy utworzyć dość reprezentatywną próbkę, która uwzględnia funkcje aplikacji klienckich i procesów wsadowych.

Początkowo wykonanie powtarzalnego testu wydajności ustala pomiar bazowy. Przy każdym uruchomieniu testu przywracana jest oryginalna baza danych i uruchamiany jest oryginalny skrypt. Powtarzalny test wydajności jest najbardziej przydatny do oceny wyników optymalizacji w „czystym” środowisku - tj. nie podlega innym procesom, niedostępnym dla innych użytkowników i zmianom danych.

Liczne czynniki wpływają na szybkość reakcji systemu. Aby ocenić, który z nich wpływa na określoną zmianę wydajności, tylko jeden z nich powinien zostać zmieniony w każdym teście, a następnie czas reakcji powinien być mierzony przy użyciu jednolitej metody. Każdy test wydajności musi zaczynać się od tych samych danych, a serwer używany do testowania musi być wolny od innych procesów, połączeń i użytkowników.

Możesz uruchomić dwa testy: jeden dla środowiska dla jednego użytkownika, a drugi dla środowiska dla wielu użytkowników w obecności konkurencji, jednocześnie uruchamiając kilka przykładów doskonałych testów. Testy te powinny być kombinacją operacji odczytu i zapisu, generowania danych dla raportów i aktualizacji zbiorczych, które symulują rzeczywiste środowisko działania bazy danych tak blisko, jak to możliwe.

Aby przetestować scenariusz dla wielu użytkowników, najlepiej jest napisać aplikację .NET, która tworzy wiele połączeń i wywołań baz danych, a tym samym symuluje duże obciążenie. Im dokładniej to obciążenie (ilościowo i jakościowo) odzwierciedla żądania rzeczywistych użytkowników, tym lepsze są testy. Nie zapominaj, że nie wszyscy konkurencyjni użytkownicy ładują bazę danych w dowolnym momencie. Wynikiem tego testu powinna być liczba transakcji, które baza danych jest w stanie obsłużyć.

Aby oszacować wymaganą liczbę transakcji, spędziłem trochę czasu na obserwacjach i badaniach (chodziłem po organizacji i zapisywałem, ilu użytkowników i jakiego rodzaju zadania wykonują, a także jak często te zadania są wykonywane).

Zbieranie danych o wydajności

Mierząc rzeczywisty czas odpowiedzi procedur składowanych na poziomie abstrakcji danych, test wydajności w środowisku produkcyjnym zbiera informacje o działaniach użytkownika.

Dane dotyczące wydajności w środowisku produkcyjnym można gromadzić na kilka sposobów.

? SQL Server Profiler może wykonywać śledzenie po stronie serwera i zbierać czas wykonania wszystkich procedur przechowywanych. Ślady mogą być rejestrowane w bazie danych i analizowane w celu dostrojenia wydajności lub uzyskania rzeczywistych danych obciążenia. Taki ślad jest łatwy do uruchomienia i zatrzymania, co daje pełną swobodę w wyborze czasu pomiaru.

? Kod programu na końcu każdej procedury składowanej może obliczyć czas jego wykonania i zapisać wynik w dzienniku w celu dalszej analizy. W zależności od konfiguracji śledzenia w Profiler ta metoda najprawdopodobniej da ci mniej szczegółów niż sam SQL Server Profiler. W zależności od złożoności kodu rejestrowania, w przypadku tej metody pojawia się inny problem: dość trudno jest wyłączyć takie rejestrowanie, jeśli zdecydujesz się mierzyć tylko przez kilka godzin lub dni.

? Kod programu aplikacji może rejestrować informacje od momentu, w którym użytkownik kliknie przycisk przesyłania formularza, aż do zakończenia aktualizacji formularza. Pomimo faktu, że ta metoda daje pełny obraz rzeczywistej aktywności użytkowników, zapewnia najmniejszą ilość informacji niezbędnych do strojenia.

Chociaż wszystkie przedstawione metody nakładają dodatkowe obciążenie na bazę danych i istnieje wiele zmiennych, uważam, że SQL Server Profiler zapewni najlepsze informacje przy najniższych możliwych kosztach.

Testowanie wpływu skalowania na wydajność

Ten rodzaj testu jest tylko odmianą regularnego testu skuteczności. Jego celem jest sprawdzenie ograniczeń skali i użyteczności bazy danych w przyszłości. Skalowalność bazy danych jest mierzona przez pomiar czasu odpowiedzi przy pełnym oczekiwanym obciążeniu i połowie obciążenia. Aby rozszerzyć oryginalne tabele robocze, generowane są nowe dane, aby podwoić bieżącą liczbę roboczą wierszy. Liczba jednoczesnych użytkowników może być również podwojona w aplikacji .NET. Po rozszerzeniu bazy danych przeprowadzany jest cykliczny test.

W SQL Server schemat bazy danych i zapytania mogą być testowane pod kątem ładowania tylko wtedy, gdy ilość danych kilkakrotnie przekracza pojemność pamięci serwera. Zachowanie indeksów jest inne, gdy SQL Server ma możliwość załadowania wszystkich niezbędnych stron danych i indeksów do pamięci. Gdy wszystkie te strony są w pamięci, logiczne odczyty stają się jedynym istotnym czynnikiem. Ponieważ nie korzysta z fizycznego dostępu do dysku, wydajność samych indeksów staje się praktycznie nieistotna.

SQL Server DBMS jest zoptymalizowany pod kątem inteligentnego buforowania danych

Notatka w pamięci, która wpływa na kolejne testy. Pamięć można uzupełnić, zatrzymując i ponownie uruchamiając serwer, a także używając komend dbcc DropCleanBuffers I DBCC FreeProcCache.

Nowe widoki dynamiczne zostały dodane do dodatku SP1. Ostrzeżenie! kontroluje monitorowanie alokacji pamięci dla żądań -

sys.dm_exec_query_memory_grants i semafory sys.dm_exec_query_resource_.

W przykładach tworzenia kluczowych wskaźników wydajności bazy danych można użyć bazy danych PerfTest dostępnej na stronie internetowej książki.

Podsumowanie

Pomiar wydajności jest głównym aspektem dostrajania i optymalizacji bazy danych. Aby zmierzyć ogólną wydajność bazy danych, organizacja może użyć kluczowych wskaźników wydajności (KPI), a do jej optymalizacji potrzebne są szczegółowe wskaźniki wydajności, które pomogą zidentyfikować problem i go naprawić. Programy SQL Server Profiler i Monitor systemu wraz z nowymi dynamicznymi widokami zarządzania zapewniają szczegółowe informacje o wydajności bazy danych.

Po opanowaniu metod monitorowania wydajności optymalizacji, w następnym rozdziale zbadamy konfigurację kluczowych narzędzi SQL Server - zapytań i indeksów. Dzięki narzędziom pomiarowym i możliwości dostosowywania zapytań i indeksów można tworzyć wysokowydajne bazy danych.

Analiza zapytań i strojenie indeksu

Podstawowe zasady architektury informacji przedstawione w rozdziale 1 stanowią, że głównym warunkiem planowania hurtowni danych jest zapoznanie się z wymaganiami dotyczącymi wydajności.

Teoria optymalizacji utorowała drogę do osiągnięcia tego celu i stworzyła podstawy do projektowania wysokowydajnych baz danych, ujawniając zależności między różnymi poziomami optymalizacji.

Teoria optymalizacji indeksów przypisuje średni poziom. Zależą one od jakości projektu znormalizowanego schematu i żądań. Bez tych dwóch elementów trudno oczekiwać dobrych wyników indeksowania.

Nie ma wątpliwości, że indeksowanie ma kluczowe znaczenie dla wysokiej wydajności bazy danych. Indeksy należy postrzegać z perspektywy wspólnego modelu podstawowego. Zależą od schematu i poziomów zapytań, a jednocześnie zapewniają skalowalność i strojenie rywalizacji serwera.

Analiza zapytań i strojenie indeksu to obszary, w których SQL Server 2005 odniósł sukces. Serwer dostarcza obszernych informacji na temat planu wykonania zapytania, jego indeksy są szybkie, są budowane przy użyciu zrównoważonego algorytmu drzewa, są łatwe do skonfigurowania, a nawet bez żadnej konfiguracji działają dobrze.

Źródło: Nielsen, Paul. Microsoft SQL Server 2005. Biblia użytkownika. : Trans. z angielskiego - M .: „I.D. Williams ”, 2008. - 1232 s. : il. - Paral. sikorka Angielski