Запуск Process Monitor заставляет приложение работать

415
lcam

Это длинный пример, но, возможно, кто-то со знанием внутренней работы Process Monitor Sysinternal может иметь идею.

Недавно у нас была очень мутная проблема на работе. У нас есть программное обеспечение (назовите его SW1), которое создает сокет-соединение на определенном порту с другим программным обеспечением (назовите его SW2) и получает некоторые данные от этого программного обеспечения. Затем он создает другое сокет-соединение с другим принадлежащим ему процессом и отправляет ему некоторые данные, после чего цикл перезапускается, и он начинает получать дополнительные данные от SW2.

Это очень расплывчатое описание, и я не имею ничего общего ни с одним из этих приложений, однако, как владелец рабочих станций, я активно участвовал в поддержке. Вся эта система работала без каких-либо помех на одной конкретной рабочей станции, однако отказалась работать на четырех других идентичных рабочих станциях. Симптомом была внезапная остановка пакетов, отправляемых между двумя собственными процессами SW1, за которыми естественно последовал тайм-аут SW2.

Теперь немного странно: после нескольких недель отладки с соответствующими командами и запуска Wireshark, я решил запустить Process Monitor, возможно, что-то появится. Как ни странно, сокетные соединения остались установленными и все работало! Думая, что это было совпадением, мы попытались запустить монитор процессов на остальных трех, и все они начали работать. Кроме того, похоже, что перезагрузка все еще поддерживает работу приложений.

Конечно, остается вопрос: какое влияние Process Monitor может оказать на эти приложения? Из-за природы решения я не могу проанализировать захват procmon, так как кажется, что он решает проблему ...

Спасибо!

0

1 ответ на вопрос

0
piedramania

Это звучит как состояние гонки или тупик .

Т.е.: SW1 и SW2 должны иметь протокол связи с запросами и подтверждениями. Если этот протокол не разработан должным образом, может возникнуть состояние гонки, при котором пакеты не отправляются в правильном порядке. SW1 получает стек в ожидании пакета от SW2, но который SW2 уже отправил в прошлом (и SW1 пропустил его), и SW2 не собирается отправлять его снова, переходя в состояние блокировки на SW1.

В этом случае сбой зависит от скорости выполнения SW1 и SW2 и, более того, от нагрузки на серверы. Допустим, если оба процесса выполняются медленно, более сложно, чтобы SW1 пропустил пакет из SW2, который создает состояние блокировки. Запуск системного монитора немного замедляет работу всей системы, что может быть достаточно для этой работы.

Что касается разных серверов, если первый сервер имеет большую нагрузку, чем другие, то у вас это работает.

Интересная концепция, однако из анализа wireshark кажется, что пакеты идентичны по последовательности, вплоть до той части, где они перестают работать, конечно ... также, самый важный бит, который я отредактирую в своем вопросе - я не каждый раз, чтобы приложение работало, нужно запускать Procmon - если я перезагружаю рабочие станции, все работает! Похоже, один раз модификация ... lcam 6 лет назад 0
Я признаю, что мертвый взгляд - отдаленная возможность. Но все же это возможно. Порядок или пакеты важны не для создания мертвой блокировки, а для синхронизации. Если SW2 отвечает очень быстро, а SW1 не очень хорошо спроектирован, возможно, он пропустил пакет и получил его в стеке, ожидая его. Это как вовремя добраться до автобусной остановки, но никто не ждет. Вы не знаете, должен ли автобус приехать, или он ушел. Проверьте синхронизацию пакетов с разных серверов или попробуйте запустить любое программное обеспечение, кроме Procmon, которое создает большую нагрузку на сервер, чтобы увидеть, получаете ли вы тот же эффект. piedramania 6 лет назад 0
Спасибо за объяснение piedramania - теперь я пытаюсь воспроизвести проблему на автономной рабочей станции, чтобы я мог поэкспериментировать с этой проблемой. Я попробую. Спасибо! lcam 6 лет назад 0
Это объяснение не выполняется, если все теперь работает и продолжает работать без Process Monitor. harrymc 6 лет назад 0