Rozwiązywanie problemów z wydajnością na kontach usługi Azure Storage

Ten artykuł ułatwia badanie nieoczekiwanych zmian w zachowaniu (takich jak wolniejsze niż zwykle czasy odpowiedzi). Te zmiany zachowania mogą być często identyfikowane przez monitorowanie metryk magazynu w usłudze Azure Monitor. Aby uzyskać ogólne informacje na temat używania metryk i dzienników w usłudze Azure Monitor, zobacz

Monitorowanie wydajności

Aby monitorować wydajność usług magazynu, możesz użyć następujących metryk.

  • Metryki SuccessE2ELatency i SuccessServerLatency pokazują średni czas podejmowania żądań przez usługę magazynu lub typ operacji interfejsu API. SuccessE2ELatency to miara kompleksowego opóźnienia, która obejmuje czas potrzebny na odczytanie żądania i wysłanie odpowiedzi oprócz czasu potrzebnego do przetworzenia żądania (w związku z tym obejmuje opóźnienie sieci po osiągnięciu usługi magazynu); SuccessServerLatency to miara tylko czasu przetwarzania i w związku z tym wyklucza wszelkie opóźnienia sieci związane z komunikacją z klientem.

  • Metryki ruchu wychodzącego i ruchu przychodzącego pokazują całkowitą ilość danych w bajtach, przychodzących do usługi magazynu i wychodzących z usługi lub za pomocą określonego typu operacji interfejsu API.

  • Metryka Transakcje pokazuje łączną liczbę żądań odbieranych przez usługę magazynu operacji interfejsu API. Transakcje to całkowita liczba żądań odbieranych przez usługę magazynu.

Możesz monitorować nieoczekiwane zmiany w dowolnej z tych wartości. Te zmiany mogą wskazywać na problem, który wymaga dalszego badania.

W Azure Portal można dodać reguły alertów, które powiadamiają o tym, gdy dowolna z metryk wydajności tej usługi spadnie poniżej lub przekroczy określony próg.

Diagnozowanie problemów z wydajnością

Wydajność aplikacji może być wartością subiektywną, zwłaszcza z punktu widzenia użytkownika. Dlatego należy mieć dostępne metryki linii bazowej, które ułatwiają wykrywanie problemów z wydajnością. Wiele czynników może mieć wpływ na wydajność usługi Azure Storage z perspektywy aplikacji klienckiej. Te czynniki mogą działać w usłudze magazynu, w kliencie lub w infrastrukturze sieciowej; dlatego ważne jest, aby mieć strategię identyfikacji źródła problemu z wydajnością.

Po zidentyfikowaniu prawdopodobnej lokalizacji przyczyny problemu z wydajnością z metryk możesz następnie użyć plików dziennika, aby znaleźć szczegółowe informacje, aby zdiagnozować i rozwiązać problem dalej.

Metryki pokazują wysoką wartość SuccessE2ELatency i niską wartość SuccessServerLatency

W niektórych przypadkach może się okazać, że powodzenieE2ELatency jest znacznie wyższe niż SuccessServerLatency. Usługa magazynu oblicza tylko metryki SuccessE2ELatency pod kątem pomyślnych żądań, a w przeciwieństwie do klasy SuccessServerLatency, obejmuje czas potrzebny klientowi na wysłanie danych i odebranie potwierdzenia z usługi magazynu. W związku z tym różnica między rozwiązaniami SuccessE2ELatency i SuccessServerLatency może być spowodowana powolnym reagowaniem przez aplikację kliencką lub warunkami w sieci.

Uwaga

Możesz również wyświetlić dane E2ELatency i ServerLatency dla poszczególnych operacji magazynowania w danych dziennika rejestrowania magazynu.

Badanie problemów z wydajnością klienta

Możliwe przyczyny, dla których klient odpowiada powoli, obejmują ograniczoną liczbę dostępnych połączeń lub wątków albo niską liczbę zasobów, takich jak procesor CPU, pamięć lub przepustowość sieci. Możesz rozwiązać ten problem, modyfikując kod klienta, aby był bardziej wydajny (na przykład przy użyciu wywołań asynchronicznych do usługi magazynu) lub używając większej maszyny wirtualnej (z większą ilością rdzeni i większą ilością pamięci).

W przypadku usług tabel i kolejek algorytm Nagle może również spowodować wysoką wartość SuccessE2ELatency w porównaniu z successServerLatency: aby uzyskać więcej informacji, zobacz wpis Nagle's Algorithm is Not Friendly towards Small Requests (Algorytm nagle nie jest przyjazny dla małych żądań). Algorytm Nagle można wyłączyć w kodzie przy użyciu klasy ServicePointManager w przestrzeni nazw System.Net . Należy to zrobić przed wykonaniem wywołań do usług tabeli lub kolejki w aplikacji, ponieważ nie ma to wpływu na połączenia, które są już otwarte. Poniższy przykład pochodzi z metody Application_Start w roli procesu roboczego.


var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Należy sprawdzić dzienniki po stronie klienta, aby zobaczyć, ile żądań przesyła aplikacja kliencka, i sprawdzić ogólne wąskie gardła wydajności związane z platformą .NET w kliencie, takie jak procesor CPU, odzyskiwanie pamięci platformy .NET, wykorzystanie sieci lub pamięć. Jako punkt wyjścia do rozwiązywania problemów z aplikacjami klienckimi platformy .NET zobacz Debugowanie, śledzenie i profilowanie.

Badanie problemów z opóźnieniami sieci

Zazwyczaj duże opóźnienia spowodowane przez sieć są spowodowane przejściowymi warunkami. Możesz zbadać zarówno przejściowe, jak i trwałe problemy z siecią, takie jak porzucone pakiety, korzystając z narzędzi, takich jak Wireshark.

Metryki pokazują niską wartość SuccessE2ELatency i niską wartość SuccessServerLatency, ale klient ma duże opóźnienie

W tym scenariuszu najbardziej prawdopodobną przyczyną jest opóźnienie żądania magazynu docierającego do usługi magazynu. Należy zbadać, dlaczego żądania od klienta nie są wysyłane do usługi obiektów blob.

Jedną z możliwych przyczyn opóźnienia wysyłania żądań przez klienta jest to, że istnieje ograniczona liczba dostępnych połączeń lub wątków.

Sprawdź również, czy klient wykonuje wiele ponownych prób, i zbadaj przyczynę, jeśli tak jest. Aby określić, czy klient wykonuje wiele ponownych prób, możesz:

  • Sprawdź dzienniki. Jeśli wystąpi wiele ponownych prób, zobaczysz wiele operacji z tymi samymi identyfikatorami żądań klienta.

  • Sprawdź dzienniki klienta. Pełne rejestrowanie oznacza, że nastąpiła ponowna próba.

  • Debuguj kod i sprawdź właściwości obiektu OperationContext skojarzonego z żądaniem. Jeśli operacja została ponowiona, właściwość RequestResults będzie zawierać wiele unikatowych żądań. Możesz również sprawdzić czasy rozpoczęcia i zakończenia dla każdego żądania.

Jeśli nie ma problemów z klientem, należy zbadać potencjalne problemy z siecią, takie jak utrata pakietów. Aby zbadać problemy z siecią, możesz użyć narzędzi, takich jak Wireshark.

Metryki pokazują wysoką wartość SuccessServerLatency

W przypadku dużego powodzeniaServerLatency dla żądań pobierania obiektów blob należy użyć dzienników usługi Storage, aby sprawdzić, czy istnieją powtarzające się żądania dla tego samego obiektu blob (lub zestawu obiektów blob). W przypadku żądań przekazania obiektu blob należy zbadać, jakiego rozmiaru bloku używa klient (na przykład bloki mniejsze niż 64 tys. mogą powodować obciążenia, chyba że odczyty są wykonywane również we fragmentach mniejszych niż 64 tys.) i czy wielu klientów równolegle przesyła bloki do tego samego obiektu blob. Należy również sprawdzić metryki na minutę pod kątem skoków liczby żądań, które powodują przekroczenie wartości docelowych skalowalności na sekundę.

Jeśli widzisz wysoką wartość SuccessServerLatency dla żądań pobierania obiektów blob, gdy istnieją powtarzające się żądania tego samego obiektu blob lub zestawu obiektów blob, należy rozważyć buforowanie tych obiektów blob przy użyciu usługi Azure Cache lub usługi Azure Content Delivery Network (CDN). W przypadku żądań przekazywania możesz zwiększyć przepływność przy użyciu większego rozmiaru bloku. W przypadku zapytań dotyczących tabel można również zaimplementować buforowanie po stronie klienta na klientach, którzy wykonują te same operacje zapytań i w miejscu gdzie dane nie zmieniają się często.

Wysokie wartości SuccessServerLatency mogą być również objawem słabo zaprojektowanych tabel lub zapytań, które powodują operacje skanowania lub które są zgodne z dołączanym/wstępnie utworzonym wzorcem.

Uwaga

Kompleksową listę kontrolną dotyczącą wydajności można znaleźć tutaj: Microsoft Azure Storage lista kontrolna dotycząca wydajności i skalowalności.

Występują nieoczekiwane opóźnienia w dostarczaniu komunikatów w kolejce

Jeśli występuje opóźnienie między czasem, w którym aplikacja dodaje komunikat do kolejki, a czas, w którym stanie się dostępny do odczytu z kolejki, należy wykonać następujące kroki, aby zdiagnozować problem:

  • Sprawdź, czy aplikacja pomyślnie dodaje komunikaty do kolejki. Sprawdź, czy aplikacja nie ponawia próby metody AddMessage kilka razy przed powodzeniem.

  • Sprawdź, czy nie ma niesymetryczności zegara między rolą procesu roboczego, która dodaje komunikat do kolejki i rolę procesu roboczego, która odczytuje komunikat z kolejki, który sprawia, że wygląda tak, jakby wystąpiło opóźnienie przetwarzania.

  • Sprawdź, czy rola procesu roboczego, która odczytuje komunikaty z kolejki, kończy się niepowodzeniem. Jeśli klient kolejki wywołuje metodę GetMessage , ale nie odpowiada przy użyciu potwierdzenia, komunikat pozostanie niewidoczny w kolejce do momentu wygaśnięcia okresu invisibilityTimeout . W tym momencie komunikat stanie się dostępny do ponownego przetwarzania.

  • Sprawdź, czy długość kolejki rośnie wraz z upływem czasu. Może się to zdarzyć, jeśli nie masz wystarczającej ilości dostępnych procesów roboczych, aby przetworzyć wszystkie komunikaty, które inni pracownicy umieszczają w kolejce. Sprawdź również metryki, aby sprawdzić, czy żądania usuwania kończą się niepowodzeniem, a liczba dequeue komunikatów, co może wskazywać na powtarzające się nieudane próby usunięcia komunikatu.

  • Sprawdź dzienniki magazynu pod kątem operacji kolejki, które mają wyższe niż oczekiwano wartości E2ELatency i ServerLatency w dłuższym okresie niż zwykle.

Zobacz też