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