У нас есть примерно 200 серверов, Hyper V, File Cluster и IIS, которые испытывают одну и ту же проблему: на сервере при нормальном использовании происходит событие, которое приводит к максимальному или почти максимальному выходу ОЗУ на сервере. Как только это произойдет, служба SVCHOST / Workstation, в частности (отсеянная путем изоляции службы Workstation от ее собственного SVCHOST), перестает освобождать дескрипторы / потоки, и память, используемая этой службой, никогда не освобождается. В некоторых крайних случаях у нас есть службы рабочих станций, которые используют до 40 ГБ оперативной памяти на сервере размером 255 ГБ. Также в некоторых случаях обнаруживается до 40 миллионов ручек.
При перезагрузке проблема, конечно, исчезает и не появляется снова, пока вся память не будет использована, скажем, процессом W3 или виртуальными машинами HyperV, после чего служба рабочей станции начнет захватывать всю оперативную память. Этот процесс очень медленный и может занять недели / месяцы в зависимости от объема оперативной памяти на сервере.
И наши серверы Hyper V, и серверы IIS имеют доступ к общим ресурсам для рабочих файлов, эти общие ресурсы находятся в хранилище SSD, поэтому они достаточно производительны. Мы установили все текущие исправления, но не перешли на R2, так как у нас есть много инструментов, которые сделают это значительным шагом, и мы не можем найти никаких четких указаний на то, что это будет исправлено в R2.
Мы использовали ProcMon и другие инструменты, но на самых проблемных серверах эти инструменты даже не работают. Что касается других, то результаты, которые они предоставляют, просто показывают, что действительно существует утечка памяти в этом процессе.
Есть ли способ освободить память от этого процесса или полностью избежать ошибки? Мы не хотим перезагружаться и не можем перезапустить процесс, если он находится в состоянии ошибки. Процесс замирает.
Мы стараемся избегать регулярных перезагрузок, чтобы «исправить» эту проблему, поэтому мы будем благодарны за любые ответы.
У меня была очень похожая проблема, когда svchost снижал производительность сервера.
Решение: Оказывается, у меня был полный журнал событий. Я очистил его, и все снова заработало, как будто ничего не произошло.
(Я также рекомендую изменить размер журнала событий по умолчанию, см. Ниже)
Чтобы установить максимальный размер журнала с помощью интерфейса Windows
- Запустите программу просмотра событий.
- В дереве консоли перейдите и выберите журнал событий, которым хотите управлять.
- В меню «Действие» выберите «Свойства».
- В поле «Максимальный размер журнала (КБ)» с помощью счетчика установите желаемое значение и нажмите «ОК».
Это похоже на то, что здесь происходит, но в итоге исправить это было очень легко. Перезапуск временно решит проблему, но как только что-нибудь попытается записать в журнал, все выйдет из-под контроля и просто продолжит поглощать ресурсы.
Надеюсь это поможет!
Создать ОЗУ легко, но это не решение.
Я предлагаю Sysinternals RAMMAP или VMMAP для более глубокого исследования. С помощью этих инструментов вы сможете лучше увидеть, что происходит. очень часто это проблема с метафайлами.
Начиная с Server 2008, у нас возникает эта проблема со всеми терминальными серверами, у которых заканчивается память с невероятным потреблением памяти с течением времени при запуске приложений из общего ресурса.
Наше обходное решение - размещение этих приложений на отдельном сервере терминалов и частая очистка потребления памяти.
Мы делаем это с помощью собственного приложения командной строки на C ++, используя
SetProcessWorkingSetSize () с SeDebugPrivilege для всех процессов
Настоятельно не рекомендуется делать что-то подобное;)
>Is there a way we can free up the memory from this process ?
Невозможно внешне (должным образом) освободить выделенную память или обрабатывать ресурсы, не убивая приложение-нарушитель.
>or avoid the bug all together?
Вы испытываете утечку памяти и ресурсов. Единственный способ решить проблему - найти утечку и либо избежать ее триггера (если возможно), либо исправить утечку на уровне исходного кода; В последнем случае вам потребуется помощь Microsoft для создания патча, но, похоже, они ожидают, что вы «точно» скажете им, где на самом деле проблема.
Вы можете попытаться найти виновника, определив утечку памяти / ресурсов с помощью, например, MS Средство проверки приложений