Використання оперативної пам'яті Windows 2012 Core Extreme у службі SVCHOST / Workstation


9

У нас приблизно 200 серверів, Hyper V, файловий кластер та IIS, у яких виникає одна і та ж проблема, на сервері відбувається звичайна подія за допомогою звичайного використання, що забезпечує максимальну або близьку до максимальної оперативної пам'яті на сервері. Як тільки це станеться, служба SVCHOST / Workstation, спеціально (відсипавшись шляхом ізоляції служби Workstation до власної SVCHOST), перестає випускати ручки / потоки, і пам'ять, яка використовується цією службою, ніколи не звільняється. У деяких екстремальних випадках у нас є сервіси Workstation, які на сервері 255 ГБ використовують 40 ГБ оперативної пам’яті. Також в деяких випадках знаходять понад 40 мільйонів ручок.

При перезавантаженні проблема, звичайно, відходить, і не з’являється знову, поки не буде використана вся пам'ять, скажімо, за допомогою процесу W3 або віртуальних машин HyperV, після цього служба Workstation почне захоплювати всю ОЗУ. Процес дуже повільний і може зайняти тижні / місяці залежно від обсягу оперативної пам’яті на сервері.

Як наші сервери Hyper V, так і сервери IIS отримують доступ до спільних файлів для роботи файлів. Ці спільні файли зберігаються на SSD-накопичувачі, тому вони є достатніми. Ми встановили всі поточні виправлення, але не перейшли на R2, оскільки у нас є багато інструментів, що зробить це значним кроком і не може знайти чітких ознак того, що це буде виправлено в R2.

Ми запустили ProcMon та інші інструменти, але на найбільш проблемних серверах ці інструменти навіть не запускаються. З іншого боку, результати, які вони надають, просто показують, що в цьому процесі дійсно є витік пам'яті.

Чи є спосіб ми звільнити пам'ять від цього процесу або уникнути помилок разом? Нам не потрібно перезавантажуватись, і ми не можемо перезапустити процес, коли він перебуває у стані помилки. Процес стає замороженим.

Ми намагаємось уникати регулярних перезавантажень, щоб "виправити" цю проблему, тому будь-які відповіді будуть вдячні.


Яке Ваше запитання?
Ендрю Шульман

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

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

Встановлено KB 2811660? У цих системах працює менеджер сервера? support.microsoft.com/kb/2793908

Так, цей КБ був встановлений деякий час тому. Крім того, цей витік характерний для служби Workstation, що 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


Тригером є спільний доступ до файлів, якого ми не можемо уникнути.
Крейг

якщо ви не можете уникнути тригера, знайдіть витік за допомогою "Verifier Application" і зв’яжіться з MS з цією інформацією.
Пат

Програми, як їх багато, - це Microsoft. Ми вже зв’язалися з ними, шукаємо швидшого рішення, оскільки вони заявляють, що це може зайняти кілька тижнів / місяців, щоб вирішити це.
Крейг

Зважаючи на те, що MS не дуже поспішатиме вирішувати подібні речі на поточній ОС, я не думаю, що ви знайдете швидше рішення. Інша річ, якщо ви скажете їм, де знаходиться витік.
Пт

Ми маємо відкриту справу і працюємо з ними вже місяць. Витік буквально знаходиться в службі Workstation.
Крейг

-1

Створення оперативної пам’яті просто, але рішення не має рішення.

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

Починаючи з Server 2008, у нас виникла ця проблема з усіма термінальними серверами, що не вистачало пам’яті з неймовірним споживанням пам’яті з часом при запуску програм із спільного доступу.

Наше вирішення - це розміщення програм на окремому сервері терміналів і часто очищення споживання пам'яті.

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

Настійно рекомендую не робити подібного;)


Чому зворотний голос? Це саме те, що просили! Тут не приємно намагатися допомогти ...
Магнус
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.