Szacowanie wymagań We / Wy dla użycia Bursty

Mamy aplikację, która okresowo odpytuje bazę danych SQL w ciągu dnia. Są okresy zerowej lub tylko niewielkiej aktywności, przeplatane indywidualnymi żądaniami względnie dużych ilości danych. Kiedy przychodzą te żądania, głównym celem jest szybkie dostarczenie danych, a celem wtórnym jest robienie tego w opłacalny sposób. Ze względu na charakter aplikacji jest mało prawdopodobne, aby dane / indeksy były buforowane w pamięci RAM z poprzedniego zapytania (różni użytkownicy, pracujący na różnych częściach danych).

W przypadku systemu, który korzysta ze stosunkowo stabilnego użycia, słyszałem ogólną zasadę obserwowania długości kolejki dyskowej i utrzymywania tej liczby względnie małej. Działa to szczególnie w AWS, gdzie widziałem zasadę, że długość kolejki dyskowej 1 na 100 IOPS jest rozsądna.

Jak mogę oszacować wymagania IO dla takiego systemu? Czy długość kolejki dyskowej jest wiarygodnym wskaźnikiem w przypadku pojedynczych zapytań z seriami? Czy są inne wskaźniki, które powinienem wziąć pod uwagę?

sql-server performance

— Eric J.
źródło

Czy trwają jakieś zapisy, czy jest to zbyt obszerne?

— Jack mówi, że spróbuj topanswers.xyz

@JackDouglas: To jest 98% odczytów. Jest strużka zapisów.

— Eric J.

Następne pytanie: czy odczyty są rozproszone lub czy „indywidualne żądania dotyczące stosunkowo dużych ilości danych” prawdopodobnie powodują sekwencyjne operacje we / wy?

— Jack mówi, że spróbuj topanswers.xyz

@JackDouglas: Największe odczyty odbywają się w widoku indeksowanym, tak że klauzula WHERE odpowiada indeksowi, ale zwraca więcej danych niż tylko to, co jest w indeksie. Nie jestem pewien, co to oznacza dla stopnia sekwencyjnego We / Wy. Ponieważ podstawowym podsystemem IO jest AWS EBS, nie jestem pewien, jak to wpływa na fizyczny dostęp.

— Eric J.

Podstawowy podsystem IO wpłynie na spójność wydajności , ale będzie dbał o rozproszony v sekwencyjny dostęp w podobny sposób jak pamięć lokalna. Te duże odczyty, ile różnych bloków trafiają typowo? Sam skan indeksu będzie sekwencyjny, ale dostęp do tabeli nie będzie, jeśli do tej pory dobrze cię zrozumiałem.

— Jack mówi, że spróbuj topanswers.xyz

Podstawową miarą, którą zawsze rozważałem dla operacji we / wy w programie SQL Server, nie są procesory IOP lub długość kolejki dysków, ale przepustowość dysku (s / odczyt i s / zapis). Ogólnie rzecz biorąc, w bazach danych nie chodzi o liczbę operacji, które można wykonać na dysku, ale o to, jak szybko te operacje są zakończone. Ogólna zasada polega na tym, aby mieć mniej niż 20 ms / operację (chociaż niższa jest zawsze lepsza). Więcej szczegółów można znaleźć w tym artykule .

Długość kolejki dyskowej jest fałszywą statystyką i nie jest już istotna. Problem polega na tym, że wartość mierzy kolejkę dla pojedynczego dysku, ale teraz, gdy żyjemy w epoce macierzy RAID, SAN i innej rozproszonej pamięci, nie ma sposobu, aby poprawnie przetłumaczyć tę wartość na znaczącą liczbę. Świetnym punktem wyjścia do pomiaru wydajności jest plakat z Quest / Dell, który zawiera wiele rzeczy i wyjaśnień, dlaczego lub dlaczego są one ważne. Nie musisz używać ich wszystkich, ale to dopiero początek.

Aby przetestować swoje IO, musisz zrozumieć swoje obciążenie pracą w szczytowym momencie. Ile transakcji i ile jest buforowanych? Jeśli nie znasz ich i nie mierzyłeś, naprawdę trudno jest ocenić. Możesz tworzyć obciążenia robocze i używać narzędzi, takich jak SQLIO, do testowania pamięci, ale będziesz potrzebować wzorców obciążenia, aby zbudować odpowiedni test.

Na koniec uwaga na temat AWS: o ile wiem, Amazon nie gwarantuje wydajności IO w AWS. Wynika to przede wszystkim z tego, że pamięć masowa jest ogromnym zasobem współdzielonym i niemożliwe jest zmierzenie wzorców ciebie i twoich sąsiadów w danym obszarze pamięci (patrz problem Noisy Neighbor ).

Radzę przydzielić jak najwięcej pamięci. SQL Server wypchnie rzeczy z pamięci tylko wtedy, gdy znajdzie się pod presją i będzie mieć miejsce w puli buforów (na podstawie LRU-K). Jeśli więc twoja pula buforów może przechowywać większość bazy danych w pamięci, możesz złagodzić część wydajności. Rozważ także taktyki, które mogą utrzymywać obiekty pamięci podręcznej w „cieple”. Na koniec miej oko na SQL 2014 i nową funkcję Hekaton .

— Mike Fal
źródło

„SQL Server wypchnie rzeczy z pamięci tylko wtedy, gdy znajdzie się pod presją” lub w punkcie kontrolnym ?

— Jack mówi, że spróbuj topanswers.xyz

Checkpoint nie usuwa obiektów z bufora, ale zapisuje brudne strony na dysku w celu odzyskania. Nadal utrzyma obiekty w puli buforów.

— Mike Fal

Dziękuję za szczegółową odpowiedź. AWS ma teraz funkcję premium o nazwie Provisioned IOPS, która zapewnia, że zakupiona liczba operacji IO na sekundę może być wykonana przez 99,9% czasu. Myślę, że operacja We / Wy jest zdefiniowana jako odczyt lub zapis 16 k bloku danych.

— Eric J.

@MikeFal: Czy masz jakieś przemyślenia na temat metodologii testowania specjalnie dla tego wzorca? Wystarczy uruchomić jedno zapytanie i obserwować liczniki, o których mowa? Wykonać kilka (zwykle okresowych) zapytań jeden po drugim, obserwując liczniki?

— Eric J.

Tak, znam PIOPS. Jak stwierdzam, nie chcę wiedzieć, ile operacji można wykonać, chcę wiedzieć, jak szybkie są one. I nie jest to coś, co może zagwarantować AWS, nawet w przypadku PIOP.

— Mike Fal