Я слишком долго занимался устранением неполадок, связанных с прерывистой производительностью сервера, и у меня заканчиваются идеи. Я ищу любые предложения относительно того, как я могу определить причину проблемы.
Мы (моя команда и я) несколько лет назад разработали клиент-серверное приложение Windows Forms с использованием базы данных SQL Server для клиента. У клиента недавно начались проблемы с производительностью, и он решил обновить свою инфраструктуру. Они мигрировали с одной физической машины SBS в виртуальную среду с несколькими виртуальными машинами. Мы успешно перенесли приложения и биты SQL в новую среду. Затем клиент запросил обновления приложения, чтобы исправить некоторые утечки памяти и другие проблемы / ошибки производительности, с которыми они работали в течение многих лет. Мы сделали обновления, и система получила хорошие оценки в нашей среде. Затем мы развернулись в их новой производственной среде, и система, похоже, работала нормально.
Через день или два после развертывания мы получили жалобы на зависание или отставание системы при загрузке / сохранении данных формы или создании отчетов. Мы связались с клиентом удаленно и подтвердили проблему. Мы проанализировали клиентскую среду и проверили возможные утечки памяти и другие проблемы, которые могут вызвать симптомы. Мы ничего не нашли. Затем мы поняли, что проблема с производительностью затрагивает несколько компьютеров в сети и должна быть связана с окружающей средой. Затем клиент попросил своих специалистов по поддержке оборудования устранить потенциальную конфигурацию оборудования / сети для источника. Они ничего не нашли.
Во время наших раундов устранения неполадок с клиентом мы наткнулись на способы исправления проблемы с производительностью, когда она возникает (что кажется случайным). Перезагрузка сервера устраняет проблему, но это недопустимое решение.
Другой способ и причина, по которой я публикую это, - когда клиент замечает снижение производительности, он может открыть «устаревшую» версию приложения (которая все еще доступна на некоторых клиентских машинах) и производительность восстановится. Перезапуск существующего экземпляра клиентского приложения не требуется.
Система хорошо работает между инцидентами, и проблема, кажется, возникает в среднем каждые 2-3 дня, но работала без инцидентов в течение недели, а также имела несколько инцидентов за один день (один утром, а затем один через неделю). днем).
Мы думали, что проблема могла быть в проблеме с SQL Server. Итак, я профилировал, сохранял трассировки, а также отслеживал счетчики производительности SQL в поисках подсказок. Я не эксперт по производительности SQL, и поэтому я, возможно, не разбираюсь в правильных счетчиках, но SQL Server, похоже, не сильно нагружен. Нет постоянных скачков ЦП, памяти, пакетов в секунду, транзакций в секунду, компиляций в секунду, повторных компиляций в секунду, а счетчики подкачки и кеша обычно статичны.
В приложении может быть одновременно запущено от 10 до 20 активных экземпляров. Приложение изначально не было написано с использованием наиболее эффективных методов извлечения данных, но созданная нагрузка - это то, с чем сервер не может справиться.
Я также отслеживал журналы событий Windows на предмет ошибок и предупреждений, которые могли бы пролить свет на проблему, но не видел ничего, что было выдано непосредственно перед или во время инцидента, указывающего на проблему.
Еще одно странное наблюдение, которое мы обнаружили, заключалось в том, что приложение работает без снижения производительности при запуске непосредственно на сервере, независимо от общей производительности системы. Я запускал приложение прямо на сервере, когда на других машинах возникала проблема, и у меня не было медлительности или задержек.
Простите за книгу. Я собираюсь продолжить поиски подсказок, но любые предложения будут очень благодарны.
Сервер: Windows Server 2012 R2 (виртуальная машина с большим количеством выделенных ресурсов) SQL: SQL Server 2014 Standard Клиенты: смешанные, но в основном Windows 7 Professional
Что касается базы данных, я бы начал регистрировать активность в таблице, вот так. Вам нужно будет настроить сохраненный процесс, чтобы он работал в течение более длительного времени, чтобы данные продолжали регистрироваться (SET @numberOfRuns = 10), или вообще отказаться от этой проверки.
Существуют инструменты, облегчающие анализ журнала производительности сервера. Вот является одним. Здесь блог авторов.
Вы можете попробовать использовать сетевой монитор, чтобы увидеть, что происходит на клиенте, когда возникает проблема. Также обратите внимание на счетчики трафика NIC в perfmon на сервере. Проверьте сеансы tcp, если, возможно, возникла проблема с netstat. Я мало знаю о сетях, так что это может быть случай, когда слепой ведет слепого :)
Вы когда-нибудь понимали это? Какую строку подключения использует ваше приложение? Если он работает нормально на сервере, но не работает на клиентах, помните о сетевом подключении. т.е. если ваша строка подключения использует datasource = computername, тогда на сервере он будет использовать цикл возврата, а на клиентах он будет использовать разрешение имени и IP-адрес. Возможно, попробуйте использовать IP-адрес в строке подключения вместо DNS-имени, чтобы исключить поиск DNS.