Назад | Перейти на главную страницу

Я ищу инструмент для измерения или обнаружения «зависания» настольного ПК.

У меня есть клиент, который предоставляет некоторые серверные системы для больницы, и был подан запрос в службу поддержки, что настольное приложение зависло в ожидании сервера. Мы провели обширное тестирование, и довольно ясно, что сервер реагирует, сеть в порядке, и что проблема на стороне клиента. (во время зависания запросов не поступает и т.д ...)

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

Во всяком случае, разговаривая с медсестрами, они говорят, что эти машины часто «зависают» на 30 секунд за раз, а иногда и в важные моменты, когда им нужно получить данные для нездорового пациента, такие как диаграммы и статус.

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

Очевидно, я с осторожностью предлагаю какое-то приложение, которое потребляет ресурсы и усугубляет проблему, поэтому мне было бы интересно увидеть любые инструменты, которые обнаруживали бы эти (правильно ли говорить, что прерывания клавиатуры отбрасываются?) Сценарии, ища ОС, отбрасывающая прерывания, или что здесь уместно.

Так что продолжайте serverfault, вот ваш шанс спасти жизнь .... ;-)


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


Думайте об этом как о космическом шаттле. Как только вещь запущена, вот и все. Он запущен, и вы застряли с тем, что установлено. Так что нет удаленного управления машинами, к которым у меня есть доступ, и я не могу сидеть и смотреть логи. Все кейсы нужно было проработать заранее. (я думаю, что если бы я мог «обнаружить» отсутствие ответа, то я мог бы запустить VBscript для копирования соответствующих файлов журнала и показателей производительности в файл, а местный техник передал эти файлы дальше)

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

Графитовый особенно хорош для этого.


С другой стороны, если проблема заключается в самом рабочем столе, я не знаю лучшего способа обнаружить отсутствие ответа, чем комбинация пользователя и вашего прямого номера телефона.

(По определению система не будет знать, что она медленная или не отвечает.)

Это бесконечная битва. Компания-производитель оборудования обвиняет компанию-разработчика программного обеспечения ... кто обвиняет ИТ-персонал ... кто виноват ... ... ... ... <ДА АУТСОРСИНГ!>

К сожалению, "зависание" может быть вызвано ооочень разными причинами по оооочень множеству разных причин. Не существует одного волшебного инструмента, который мог бы отслеживать все возможные причины «времени ожидания». Что касается того, что вы можете сделать ... это использовать инструмент "perfmon", встроенный в Windows, и добавлять различные интересующие вас счетчики производительности ... которые могут быть любыми. (да, вы можете контролировать удаленные машины) Начните с основ ... таких как использование ЦП, длина очереди физического диска, настройка сети и т. д.

Если вы видите высокую загрузку ЦП ... Пришло время выяснить, что делает приложение и почему оно потребляет так много ЦП.

Если вы видите значительное количество вещей, ожидающих в очереди диска ... возможно, вам следует оптимизировать свой диск (дефрагментировать? Заменить на более быстрые диски? Проверить на наличие ошибок ... и т. Д.). Если у вас все еще нет удачи здесь ... возможно приложение не очень хорошо оптимизировано. Плохие разработчики часто допускают ошибки, когда приложение считывает 100 МБ данных, когда ему нужны только последние 5 строк журнала.

Если вы видите большой объем сетевого трафика ... время выяснить, почему. Возможно, происходит много "повторных передач" из-за неисправных кабелей / оборудования ... возможно, в сети есть петля, а коммутаторы не поддерживают связующее дерево ... Может быть, в сети много лишнего мусора, например принтеры с поддержкой apple-talk / ipx ... список можно продолжить.

Возможно, вам придется пойти еще дальше и реализовать что-то вроде Wire-Shark и контролировать обмен пакетами между клиентом и сервером. Возможно, приложение отправляет пакет на сервер и ожидает (блокирует) ответ, прежде чем продолжить выполнение программы. Возможно, сам сервер перегружен и не успевает за количеством клиентских подключений.

... это всего лишь царапина на поверхности ... Устранение проблем с "зависанием" приложений, когда у вас нет доступа к исходному коду или к разработчику, который знает, что они делают ... - ОГРОМНОЕ мероприятие.