Udostępnij za pośrednictwem

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

  • Artykuł

Ten artykuł pomaga zbadać nieoczekiwane zmiany zachowania (takie 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 korzystania z metryk i dzienników w usłudze Azure Monitor, zobacz następujące artykuły:

Monitorowanie wydajności

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

  • Metryki SuccessE2ELatency i SuccessServerLatency pokazują średni czas przetwarzania żądań przez usługę magazynu lub typ operacji interfejsu API. SuccessE2ELatency to miara całkowitego opóźnienia, które obejmuje czas potrzebny na odczytanie żądania i wysłanie odpowiedzi oprócz czasu potrzebnego na przetworzenie żą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 i wychodzących z usługi magazynu 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 łączna 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 dalszej analizy.

W witrynie Azure Portal możesz dodać reguły alertów, które powiadamiają o tym, kiedy dowolny z metryk wydajności dla 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 ważne jest, aby metryki linii bazowej były dostępne, aby ułatwić ustalenie, gdzie może wystąpić problem 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, kliencie lub infrastrukturze sieciowej. Dlatego ważne jest, aby mieć strategię identyfikowania ź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 wartość SuccessE2ELatency jest wyższa niż SuccessServerLatency. Usługa magazynu oblicza tylko metryki SuccessE2ELatency dla pomyślnych żądań, a w przeciwieństwie do 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 successE2ELatency i SuccessServerLatency może być spowodowana powolnym reagowaniem przez aplikację kliencką lub z powodu warunków w sieci.

Uwaga 16.

Można również wyświetlić dane dziennika E2ELatency i ServerLatency dla poszczególnych operacji magazynowania.

Badanie problemów z wydajnością klienta

Możliwe przyczyny powolnej reakcji klienta obejmują ograniczone dostępne połączenia lub wątki lub niskie zasoby, takie 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 powodzeniemServerLatency. Aby uzyskać więcej informacji, zobacz wpis Nagle's Algorithm is Not Friendly to Small Requests (Algorytm Nagle nie jest przyjazny dla małych żądań). Algorytm Nagle w kodzie można wyłączyć przy użyciu ServicePointManager klasy w System.Net przestrzeni nazw. Należy to zrobić przed wykonaniem wywołań do usług tabeli lub kolejek w aplikacji, ponieważ nie ma to wpływu na połączenia, które są już otwarte. Poniższy przykład pochodzi z Application_Start metody 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 sprawdzić, 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, przy użyciu 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 przechodzą 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 wystąpiła ponowna próba.

  • Debuguj kod i sprawdź właściwości obiektu skojarzonego OperationContext z żądaniem. Jeśli operacja została ponowiona, RequestResults właściwość będzie zawierać wiele unikatowych żądań. Możesz również sprawdzić godziny 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 wysokiej klasy SuccessServerLatency 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ń przekazywania obiektów blob należy zbadać rozmiar bloku używany przez klienta (na przykład bloki o rozmiarze mniejszym niż 64 K mogą powodować obciążenie, chyba że odczyty znajdują się również w mniej niż 64 K fragmentów) i jeśli wielu klientów przekazuje bloki do tego samego obiektu blob równolegle. 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 dla tego samego obiektu blob lub zestawu obiektów blob, rozważ 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ń do tabel istnieje również możliwość zaimplementowania buforowania po stronie klienta na klientach, którzy wykonują te same operacje zapytań i gdzie dane nie zmieniają się często.

Wartości High 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/poprzedzanym wzorcem antywłaszczowym.

Uwaga 16.

Kompleksową listę kontrolną wydajności można znaleźć na liście kontrolnej wydajności i skalowalności usługi Microsoft Azure Storage.

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

Jeśli występuje opóźnienie między czasem dodawania komunikatu do kolejki przez aplikację, a czasem, w którym będzie dostępny odczyt z kolejki, wykonaj następujące kroki, aby zdiagnozować problem:

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

  • Sprawdź, czy między rolą procesu roboczego nie ma niesymetryczności zegara, która dodaje komunikat do kolejki i rolę procesu roboczego, która odczytuje komunikat z kolejki. Niesymetryczność zegara sprawia, że wydaje się, że istnieje opóźnienie przetwarzania.

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

  • Sprawdź, czy długość kolejki rośnie wraz z upływem czasu. Taka sytuacja może wystąpić, jeśli nie masz wystarczającej liczby 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, oraz liczba komunikatów w kolejce, 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ż

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.