Jak wykrywać problemy z wysoką wydajnością procesora i długim czasem reakcji z programem Asp.NET Web Api

Question

Pracujemy z Asp.Net WebApi na 3 serwerach za HAProxy. HAProxy po prostu losowo rozdziela żądania między te 3 instancje.

Te instancje łączą się z mongodb, redis i niektórymi usługami Windows.

Zwykle w3wp.exe używa około 30% procesora na każdym serwerze APi.

Od czasu do czasu (kilka razy na godzinę) jeden z serwerów api decyduje się na użycie dużej liczby procesorów. W korelacji z tym zachowaniem zaczynamy dostrzegać coraz dłuższe czasy odpowiedzi. Liczby stale rosną, dopóki HAProxy nie wyświetli 10000ms czasów odpowiedzi i zdecyduje się skierować żądania do innych dwóch serwerów. Wszystko to za 10-20 sekund. Po pewnym czasie serwer wraca do normalnego stanu i ponownie pobiera żądania. Po kilku minutach inny serwer robi dokładnie to samo. To się ciągnie i trwa.

Używamy New Relic, ale ponieważ aplikacja jest aplikacją WebApi, nie otrzymujemy żadnych użytecznych informacji. Monitorujemy wszystkie nasze serwery (usługi redis, mongo i windows) w zakresie wykorzystania procesora, wykorzystania pamięci, ruchu sieciowego i operacji we/wy, ale nie widzimy żadnego znaczącego obciążenia podczas wspomnianych przestojów.

Jak możemy wykryć przyczynę tego zachowania aplikacji?

Answer 1

Dobrą opcją byłoby zrobienie mini-zrzutu przy użyciu czegoś takiego jak Process Explorer, a następnie sprawdzenie go za pomocą WinDBG lub w inny sposób, aby zobaczyć, co robią wątki i tak dalej. Mam dobrego blogu o tym, jak to zrobić tutaj:

http://www.haneycodes.net/but-it-didnt-happen-in-dev-or-qa/

Answer 2

Jak DavidH powiedział, coraz zrzut pamięci jest bardzo ważnym krokiem. Jeśli chcesz, mogę zaoferować pomoc, aby przeczytać zrzut.

Kolejna przydatna też jest CPU Analyzer, który jest wolny: http://samsaffron.com/archive/2009/11/11/Diagnosing+runaway+CPU+in+a+Net+production+application

Inną opcją jest użycie PerfView.

Jeszcze inną opcją jest użycie JetTrack dotTrace i dołączenie do procesu w3wp.exe.

Answer 3

Jedną rzeczą wspólną dla środowiska .NET i Java EE jest narzędzie do zbierania śmieci. Tak więc, jeśli twoja aplikacja używa dużej ilości pamięci, wtedy okresy wysokiego CPU mogą być wywoływane przez garbage collector. Miałem ten problem z .NET 3.5 IIS 7 z aplikacją, która konsekwentnie używała ponad gigabajta na proces. Garbage Collector zasadniczo zatrzymuje wszystko, gdy odzyskuje pamięć dla twojej aplikacji. Możesz zmienić ustawienia garbage collectora, a nawet wywołać je z kodu, gdy ma to sens. Istnieje wiele małych strategii, z których możesz skorzystać. Kolejny problem pojawi się w GC, jeśli robisz dużo i dużo ciągów. Na przykład analizowane są ciągi znaków przychodzące przez usługę Restful Web. Powoduje to dużą fragmentację pamięci i może spowodować, że GC spędza dużo więcej czasu i odzyskuje pamięć procesora.

Łatwo zauważyć, że tak się dzieje, jeśli tak właśnie się dzieje. Możesz użyć Taskmanager, aby obserwować wykorzystanie pamięci i procesor procesu. Spójrz na pamięć używaną, gdy procesor idzie w górę i po tym, jak znowu się obniża.