Studium przypadku: wyizolowanie kilkusekundowych zatrzymań komunikacji kamery przemysłowej

Przegląd przypadku

Ten przypadek dotyczy sterowania kamerą przemysłową, w którym komunikacja zwykle działała, ale sporadycznie zatrzymywała się na zaledwie kilka sekund. Objaw mógł wyglądać zarówno na zatrzymanie po stronie aplikacji, jak i na problem sieciowy, dlatego pierwszym krokiem było rozdzielenie, co dokładnie się zatrzymuje.

Objawy

• Komunikacja zatrzymywała się na kilka sekund, z niską częstotliwością
• Nie wyglądało na to, by interfejs użytkownika lub cały proces były całkowicie zawieszone
• W sterowaniu urządzeniami nawet kilkusekundowe zatrzymanie ma duży wpływ na środowisko produkcyjne

Ograniczenia

• Błąd występował rzadko, a warunki jego odtworzenia trudno było dostrzec wyłącznie w logach
• Wyglądało na to, że może pojawiać się wszędzie: w SDK kamery, karcie sieciowej (NIC), przełączniku lub w kodzie aplikacji
• Izolowanie przyczyny trzeba było prowadzić bez zaburzania warunków zbliżonych do konfiguracji produkcyjnej

Co obserwowaliśmy

• Aby najpierw wykluczyć przyczyny zatrzymania w samej aplikacji, sprawdziliśmy opóźnienia przetwarzania i występowanie wyjątków
• Dzięki przechwytywaniu pakietów zaobserwowaliśmy zdarzenia Retransmission oraz odstępy czasowe
• Sprawdziliśmy, czy kształt opcji TCP i czasu oczekiwania na retransmisję zgadza się z objawem

Jak zawęziliśmy przyczynę

Zweryfikowaliśmy, czy zatrzymanie komunikacji można traktować nie jako „zatrzymanie aplikacji”, lecz jako oczekiwanie na retransmisję po utracie pakietów. W rezultacie mogliśmy stwierdzić, że przyczyną zatrzymania nie było zakleszczenie (deadlock) aplikacji, lecz struktura, w której na pierwszy plan wysuwa się czas oczekiwania po stronie TCP.

Jak poprawiliśmy sytuację

• Oceniliśmy, czy zachodzą warunki, w których ustawienia znaczników czasu w stylu RFC 1323 faktycznie przynoszą efekt
• Dostosowaliśmy konfigurację tak, aby czas oczekiwania na retransmisję można było skrócić
• Uporządkowaliśmy procedurę obserwacji i kryteria izolowania przyczyny, aby w przyszłości można było ponownie sprawdzić ruch na poziomie sieci (wire level)

Usługi powiązane z tym przypadkiem

Ten przypadek łączy się zarówno z usługą Diagnostyka błędów i analiza przyczyn źródłowych, która pozwala na podstawie dowodów wyizolować trudne do odtworzenia przerwy w komunikacji, jak i z usługą Tworzenie aplikacji dla systemu Windows, w ramach której od strony aplikacji przeglądamy projekt komunikacji i monitorowania.

Powiązane artykuły

Zapraszamy do konsultacji

Jeśli mają Państwo problem zbliżony do treści tej strony, prosimy o konsultację z nami, przekazując obecny kontekst oraz rodzaj potrzebnego wsparcia.