#.net-3.5 #crash #windows-server-2003 #vmware #windbg
#.net-3.5 #сбой #windows-server-2003 #vmware #windbg
Вопрос:
У меня есть довольно большой серверный процесс, написанный на .net-3.5, то есть запущенный на сервере VMware vCenter, который продолжает сбоить без сообщений о каких-либо ошибках. Процесс создается службой Windows на 32-разрядной версии Windows Server 2003 и предназначен для длительного выполнения (несколько дней). Это процесс совместной работы, который принимает соединения через Tcp-сокеты от нескольких клиентов, работающих на других компьютерах с Windows XP, и позволяет им обмениваться данными. Кроме того, процесс также самостоятельно размещает около 8 служб WCF, которые предоставляют смесь конечных точек Tcp и Http. Процесс обычно потребляет около 500 Мб памяти и от 30 до 50% процессора в любое время. На той же виртуальной машине также имеется экземпляр SQL Server 2005, на котором размещены 6 баз данных, и который потребляет около 1-1,2 Гб памяти. Всей системе выделено 8 Гб оперативной памяти, и при нормальной работе она потребляет целых 7 Гб. Я предполагаю, что PAE включен, чтобы разрешить системе обращаться к 8 Гб оперативной памяти, но не подтвердил это.
Проблема в том, что в кажущиеся случайными моменты времени процесс внезапно завершается сбоем без сообщений об ошибках, в том числе в журнале событий. Я пытался подключить отладчики к процессу, и они также не зафиксировали сбой. Сначала я попробовал WinDbg в сборке выпуска с загруженными символами, затем я заменил все библиотеки DLL / exes выпуска отладочными сборками и загрузил их символы. Сбои все еще происходили, и отладчик их не перехватил. Затем я установил Visual Studio в системе с надстройкой .Net Reflector и прикрепил ее. Он также не зафиксировал сбой.
Прежде чем вы прочтете мне лекцию о том, почему мы запускаем так много всего на одной виртуальной машине, знайте, что я не проектировал систему и не реализовывал ее таким образом. Наш заказчик продиктовал это по определенным причинам, и меня попросили прийти и заставить это работать. Меня интересует критика среды только в том случае, если вы можете разместить конкретные доказательства, которые помогли бы объяснить внезапные сбои. Наш клиент может захотеть изменить среду, если мы сможем предоставить такие доказательства. Также я был бы весьма признателен за любые дополнительные методы отладки, которые позволят мне получить больше информации о сбое.
Комментарии:
1. Сначала я бы включил чрезмерное ведение журнала (например, с помощью NLOG или LOG4NET) в приложение и посмотрел, что регистрируется в случае исключений.
2. ru используете какие-либо неуправляемые сторонние библиотеки? когда вы подключаете windbg и исключение не перехватывается, есть ли что-нибудь еще интересное в выходных данных windbg?
3. Хм, мое первое предположение (и это все , что есть) заключается в том, что это какая-то ошибка нехватки памяти. Вероятно, ваш процесс потребляет много оперативной памяти, вы столкнулись с какой-то проблемой со сборкой мусора, и процесс завершается. Не уверен, почему вы не можете перехватить ошибку с помощью отладчика. Убедитесь, что у вас нет утечки памяти или дескрипторов. Что сообщает вам что-то вроде Process Monitor, пока все стабильно?
4. У нас избыточное ведение журнала (Nlog), и мы не видим никаких исключений, регистрируемых там при сбое процесса. Мы также используем некоторые неуправляемые сторонние библиотеки. В выходных данных отладчика нет ничего интересного.
5. Вот кое-что интересное, что мы наблюдали. Даже несмотря на то, что процесс и родительская служба выполняются от имени другой учетной записи пользователя, по крайней мере, в 3 случаях мы наблюдали, что если я вхожу на сервер (для архивирования журналов, перезапуска служб и т.д.), Когда я выхожу из системы, процесс завершается сбоем в тот же момент. Это происходит не все время, но достаточно, чтобы заставить меня думать, что что-то происходит. Опять же, процесс создается службой Windows и выполняется под собственной выделенной учетной записью пользователя (не моей).
Ответ №1:
Ответ №2:
«Сбой» без вывода предполагает вызов _exit() (или даже exit() ). Я видел, как это происходит в нескольких уголках библиотеки среды выполнения Visual Studio, хотя обычно они выводят зашифрованное сообщение на stderr . stderr Захвачен?
Подозрение на нехватку памяти также кажется вероятным. Если в .net есть heapspace() подобная функция для описания того, сколько памяти используется кучей, периодически регистрируйте это, возможно, вместе с общим объемом используемой памяти (код стек данные). Я не знаком с .net, но должны быть функции для получения этих значений.
Ответ №3:
Оказывается, что один из служебных плагинов искал библиотеку Java и ссылался на нее. Когда пользователь вышел из системы, плагин завершил работу службы из-за завершения работы JVM. Мы смогли заставить все снова работать, следуя предложениям в этом сообщении (запустив JVM с параметром ‘-Xrs’): http://www.velocityreviews.com/forums/t128371-java-app-dies-on-logoff.html