Использование памяти Windows 2012 Core Extreme в сервисе SVCHOST / Workstation


9

У нас есть примерно 200 серверов, Hyper V, File Cluster и IIS, которые испытывают одну и ту же проблему, при обычном использовании на сервере происходит событие, которое максимально или почти максимально использует ОЗУ на сервере. Как только это происходит, служба SVCHOST / Workstation, в частности (отсеянная путем изоляции службы Workstation от собственного SVCHOST), прекращает выпуск дескрипторов / потоков, и память, используемая этой службой, никогда не освобождается. У нас есть, в некоторых крайних случаях, сервисы рабочих станций, которые используют до 40 ГБ оперативной памяти на сервере 255 ГБ. Также в некоторых случаях можно найти более 40 миллионов ручек.

При перезагрузке проблема, конечно же, исчезает и не появляется снова, пока вся память не будет использована, скажем, процессом W3 или виртуальными машинами HyperV, после чего служба рабочей станции начнет захватывать всю оперативную память. Процесс очень медленный и может занять недели / месяцы в зависимости от объема оперативной памяти на сервере.

Как наши серверы Hyper V, так и серверы IIS имеют доступ к общим ресурсам для рабочих файлов, эти общие ресурсы находятся в хранилище SSD, поэтому они достаточно производительны. Мы установили все текущие исправления, но не перешли на R2, так как у нас есть много инструментов, которые сделают это значительным шагом и не найдут четких указаний на то, что это будет исправлено в R2.

Мы запустили ProcMon и другие инструменты, но на самых проблемных серверах эти инструменты даже не запускаются. Что касается остальных, то результаты, которые они предоставляют, просто показывают, что в этом процессе действительно наблюдается утечка памяти.

Есть ли способ, которым мы можем освободить память от этого процесса или избежать ошибки вместе? Мы не хотим перезагружаться и не можем перезапустить процесс, если он находится в состоянии ошибки. Процесс становится замороженным.

Мы стараемся избегать регулярных перезагрузок, чтобы «исправить» эту проблему, поэтому любые ответы приветствуются.


Какой у Вас вопрос?
Андрей Шульман

Да, действительно, но в лучшем случае это неоднозначно, открываются тысячи / миллионы потоков. На самых проблемных системах мы даже не можем запустить эти инструменты, они просто сбивают сервер.
Крейг,

Мы хотим найти хорошее решение для решения проблемы, кроме перезагрузки. Мы не можем остановить службы, как только эта проблема начинается.
Крейг,

KB 2811660 был установлен? На этих системах работает диспетчер серверов? support.microsoft.com/kb/2793908

Да, этот KB был установлен некоторое время назад. Кроме того, эта утечка характерна для службы рабочей станции, которую KB применяет к службе WMI.
Крейг,

Ответы:


1

У меня была очень похожая проблема, когда svchost разрушал производительность сервера.

Решение: оказывается, у меня был полный журнал событий. Я все очистил, и все снова заработало, как будто ничего не случилось.

(Я также рекомендую изменить размер журнала событий по умолчанию, см. Ниже)

Чтобы установить максимальный размер журнала с помощью интерфейса Windows
- Запустите Просмотр событий.
- В дереве консоли перейдите и выберите журнал событий, которым вы хотите управлять.
- В меню «Действие» выберите «Свойства».
- В поле «Максимальный размер журнала (КБ)» с помощью регулятора счетчика установите желаемое значение и нажмите «ОК».

Это звучит так же, как то, что происходит здесь, но в конечном итоге это было действительно легко исправить. Перезапуск временно решит проблему, но как только что-то попытается записать в журнал, все выйдет из-под контроля и просто будет поглощать ресурсы.

Надеюсь это поможет!


-1
>Is there a way we can free up the memory from this process ?

Нет никакого способа, которым вы можете (должным образом) освободить выделенную память или обработать ресурсы без уничтожения приложения-нарушителя.

>or avoid the bug all together? 

Вы испытываете утечку памяти и ресурсов. Единственный способ решить проблему - найти утечку и либо избежать ее срабатывания (если это возможно), либо устранить утечку на уровне исходного кода; В последнем случае вам нужна помощь Microsoft для производства патча, но, похоже, они ожидают, что вы скажете им «точно», где на самом деле проблема.

Вы можете попытаться найти виновника, точно определив утечку памяти / ресурсов, используя, например, MS Application Verifier.


Триггер - это файловые ресурсы, которых мы не можем избежать.
Крейг

если вы не можете избежать триггера, найдите утечку с помощью «Application Verifier» и свяжитесь с MS с этой информацией.
Пэт

Приложения, как их много, все Microsoft. Мы уже связались с ними, мы ищем более быстрое решение, так как они заявляют, что им может потребоваться недели / месяцы, чтобы разобраться с этим.
Крейг

Учитывая, что MS на самом деле не будет спешить с решением подобных проблем в устаревшей ОС, я не думаю, что вы найдете более быстрое решение. Другое дело, если вы скажете им, где находится утечка.
Пэт

У нас есть открытое дело, и мы работаем с ними уже месяц. Утечка буквально в сервисе рабочей станции.
Крэйг

-1

Создать ОЗУ легко, но нет решения.

Я предлагаю Sysinternals RAMMAP или VMMAP для более глубокого исследования. С помощью этих инструментов вы можете лучше видеть, что происходит. очень часто это проблема метафайла.

Начиная с Server 2008 у нас есть эта проблема со всеми серверами терминалов, исчерпывающими память с невероятным потреблением памяти с течением времени при запуске приложений из общего ресурса.

Наш обходной путь - размещение этих приложений на отдельном терминальном сервере и частая очистка памяти.

Мы делаем это с помощью самостоятельно разработанного приложения командной строки c ++, использующего
SetProcessWorkingSetSize () с SeDebugPrivilege для всех процессов

Настоятельно рекомендуется не делать что-то подобное;)


Почему понизить? Это именно то, о чем просили! Здесь не приятно пытаться помочь ...
Магнус
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.