Udostępnij za pośrednictwem

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

  • Artykuł

Ten artykuł ułatwia badanie nieoczekiwanych zmian w zachowaniu (takich jak wolniejsze niż zwykle czasy odpowiedzi). Te zmiany zachowania można często zidentyfikować, monitorując metryki 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żna 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óra obejmuje czas potrzebny na odczyt żądania i wysłanie odpowiedzi oprócz czasu potrzebnego na przetworzenie żądania (w związku z tym obejmuje opóźnienie sieci po dotarciu żądania do usługi magazynu). SuccessServerLatency jest miarą 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, przechodzących do i wychodzących z usługi magazynu lub za pośrednictwem określonego typu operacji interfejsu API.

  • Metryka Transakcje pokazuje całkowitą 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 zbadania.

W Azure Portal można dodać reguły alertów, które powiadamiają Cię, gdy dowolna z metryk wydajności dla tej usługi spadnie poniżej określonego progu lub przekroczy go.

Diagnozowanie problemów z wydajnością

Wydajność aplikacji może być subiektywna, szczególnie z perspektywy użytkownika. Dlatego ważne jest, aby mieć dostępne metryki punktu odniesienia, aby ułatwić określenie, 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 użyć plików dziennika, aby znaleźć szczegółowe informacje umożliwiające dalsze diagnozowanie i rozwiązywanie problemu.

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

W niektórych przypadkach może się okazać, że wartość SuccessE2ELatency jest wyższa niż wartość SuccessServerLatency. Usługa magazynu oblicza tylko metrykę SuccessE2ELatency dla pomyślnych żądań i, w przeciwieństwie do successServerLatency, zawiera 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 powolną reakcją aplikacji klienckiej lub z powodu warunków w sieci.

Uwaga

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

Badanie problemów z wydajnością klienta

Możliwe przyczyny, dla których klient reaguje powoli, obejmują ograniczone dostępne połączenia lub wątki lub brak zasobów, takich jak procesor CPU, pamięć lub przepustowość sieci. Możesz rozwiązać ten problem, modyfikując kod klienta tak, aby był bardziej wydajny (na przykład za pomocą 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ż powodować wysoką wartość SuccessE2ELatency w porównaniu z wartością SuccessServerLatency. Aby uzyskać więcej informacji, zobacz post Nagle's Algorithm is Not Friendly to Small Requests (Algorytm Nagle'a 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 jakichkolwiek wywołań do usług tabel 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ć liczbę żądań przesyłanych przez aplikację kliencką 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óźnieniem sieci

Zazwyczaj duże opóźnienia end-to-end spowodowane przez sieć wynikają z przejściowych warunków. 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óźnienia

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 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 ponawia się wiele prób, zobaczysz wiele operacji z tymi samymi identyfikatorami żądań klienta.

  • Sprawdź dzienniki klienta. Pełne rejestrowanie będzie wskazywać, że nastąpiła ponawianie próby.

  • 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ć godziny rozpoczęcia i zakończenia dla każdego żądania.

Jeśli klient nie ma żadnych problemów, 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 wartości SuccessServerLatency dla żądań pobierania obiektów blob należy użyć dzienników magazynu, aby sprawdzić, czy istnieją powtarzające się żądania dotyczące tego samego obiektu blob (lub zestawu obiektów blob). W przypadku żądań przekazywania obiektów blob należy zbadać, jakiego rozmiaru bloku używa klient (na przykład bloki o rozmiarze mniejszym niż 64 K mogą powodować narzuty, chyba że operacje odczytu znajdują się również w fragmentach mniejszych niż 64 K) 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 w przypadku powtarzających się żądań dotyczących 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żna zwiększyć przepływność przy użyciu większego rozmiaru bloku. W przypadku zapytań do tabel można również zaimplementować buforowanie 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 źle zaprojektowanych tabel lub zapytań, które powodują operacje skanowania lub które są zgodne z antywzorzecem dołączania/przedpłaty.

Uwaga

Pełną listę kontrolną dotyczącą wydajności można znaleźć na liście kontrolnej Microsoft Azure Storage Performance and Scalability (Wydajność i skalowalność).

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, kiedy będzie ona dostępna do odczytu z kolejki, wykonaj następujące kroki, aby zdiagnozować problem:

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

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

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

  • Sprawdź, czy długość kolejki rośnie w czasie. Taka sytuacja może wystąpić, jeśli nie masz wystarczającej liczby dostępnych procesów roboczych, aby przetworzyć wszystkie komunikaty umieszczane w kolejce przez innych pracowników. Sprawdź również metryki, aby sprawdzić, czy żądania usunięcia kończą się niepowodzeniem, oraz czy kolejka liczy na komunikaty, co może wskazywać na powtarzające się nieudane próby usunięcia komunikatu.

  • Sprawdź dzienniki magazynu pod kątem wszelkich operacji w kolejce, które mają wyższe niż oczekiwano wartości E2ELatency i ServerLatency w dłuższym okresie czasu 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 platformy Azure.