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ę?
źródło
Odpowiedzi:
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 .
źródło