У нас есть ~10 пользователей, которые используют устаревшее (16-битный DOS на Windows 98) программное обеспечение для ввода данных на файловом сервере Windows 2003. Доступ к файлам осуществляется напрямую (т. е. оно работает как клиентское приложение с постоянным доступом к сетевым файлам, а не как клиент-серверное приложение).
В последнее время производительность этого приложения была ужасной. 15 секунд на запуск крошечного отчета или открытие нового экрана. Но когда мы смотрим на показатели производительности сервера, то, похоже, никаких проблем не возникает. Низкий IOPS, никакого среднего ожидания диска, мало байтов чтения/записи, почти 0% использования ЦП, тонны свободной оперативной памяти и т. д. Мы просмотрели все показатели и не увидели ничего, что хотя бы отдаленно приближалось бы к пределам сервера.
Мы находимся в процессе замены программного обеспечения, но нам нужно, чтобы оно работало еще год, пока не завершится наш переход. Есть идеи, как мы можем определить источник проблем?
решение1
По моему комментарию, оказалось, что это была проблема сети. Не знаю почему, но перемещение одного пользователя на другой коммутатор исправило это.
решение2
Монитор процессов от Sysinternals (теперь часть Microsoft) предоставит вам всю необходимую информацию:
http://technet.microsoft.com/en-gb/sysinternals/bb896645
Просто запустите его, прежде чем запускать свое приложение, убедитесь, что вы правильно настроили фильтры и параметры (оно выдает огромный объем информации!), затем расслабьтесь и наблюдайте за тем, что отображается на мониторе во время работы приложения, пока происходит замедление.
Учитывая, что вы можете воспроизвести свой сценарий, после нескольких запусков вы сможете увидеть, что вызывает у вас проблемы.
На сайте Sysinternals есть и другие инструменты, которые, вероятно, вам помогут.