Windows 2012 Core Extreme memory digunakan pada layanan SVCHOST / Workstation


9

Kami memiliki sekitar 200 server, Hyper V, File Cluster, dan IIS, yang semuanya mengalami masalah yang sama, suatu peristiwa terjadi pada server melalui penggunaan normal yang memaksimalkan atau mendekati memaksimalkan RAM pada server. Setelah ini terjadi, layanan SVCHOST / Workstation, khususnya (dihapus dengan mengisolasi layanan Workstation ke SVCHOST itu sendiri) berhenti melepaskan gagang / utas dan memori yang digunakan oleh layanan itu tidak pernah dirilis. Kami memiliki, dalam beberapa kasus ekstrim, layanan Workstation yang menggunakan ram sebanyak 40GB pada server 255GB. Juga menemukan lebih dari 40 juta pegangan dalam beberapa kasus.

Saat reboot, masalahnya tentu saja, hilang, dan tidak muncul lagi sampai semua memori telah digunakan, katakanlah oleh proses W3 atau HyperV VM, setelah itu, layanan Workstation mulai mengambil semua RAM. Prosesnya sangat lambat dan bisa memakan waktu berminggu-minggu / bulan tergantung pada jumlah RAM di server.

Baik server Hyper V kami dan server IIS mengakses share untuk file yang berfungsi, share ini ada di penyimpanan SSD, sehingga mereka banyak yang performan. Kami telah menginstal semua tambalan saat ini tetapi belum pindah ke R2 karena kami memiliki banyak tooling di tempat yang akan membuat ini langkah yang signifikan dan tidak dapat menemukan indikasi yang jelas bahwa ini akan diperbaiki dalam R2.

Kami telah menjalankan ProcMon dan alat-alat lain tetapi pada server yang paling bermasalah alat-alat itu bahkan tidak akan berjalan. Pada yang lain, hasil yang mereka berikan hanya menunjukkan bahwa memang ada kebocoran memori dalam proses itu.

Apakah ada cara kita dapat membebaskan memori dari proses ini atau menghindari bug bersama-sama? Kami tidak ingin harus melakukan boot ulang dan kami tidak dapat memulai kembali proses setelah itu dalam keadaan kesalahan. Prosesnya menjadi beku.

Kami berusaha menghindari melakukan reboot rutin untuk 'memperbaiki' masalah ini, jadi jawaban apa pun akan dihargai.


Apa pertanyaan Anda?
Andrew Schulman

Memang benar, tapi ini ambigu, hanya ribuan / jutaan utas yang terbuka. Pada sistem yang paling bermasalah kita bahkan tidak bisa menjalankan alat-alat itu, mereka hanya crash server.
Craig

Kami ingin mencari solusi yang baik untuk menyelesaikan masalah selain me-reboot kotak. Kami tidak dapat menghentikan layanan begitu masalah ini dimulai.
Craig

Sudahkah KB 2811660 diinstal? Apakah sistem ini menjalankan manajer server? support.microsoft.com/kb/2793908

Ya, KB ini diinstal beberapa waktu lalu. Selain itu, kebocoran ini khusus untuk layanan Workstation, bahwa KB berlaku untuk layanan WMI.
Craig

Jawaban:


1

Saya punya masalah serupa yang menakutkan di mana svchost menghancurkan kinerja server.

Solusinya: Ternyata saya punya Event Log lengkap. Saya membersihkannya dan semuanya kembali dan berjalan seperti tidak pernah terjadi.

(Saya juga merekomendasikan untuk mengubah ukuran log peristiwa dari default, lihat di bawah)

Untuk mengatur ukuran log maksimum dengan menggunakan antarmuka Windows
- Start Event Viewer.
- Di pohon konsol, navigasikan ke dan pilih log peristiwa yang ingin Anda kelola.
- Pada menu Tindakan, klik Properti.
- Dalam Ukuran log maksimum (KB), gunakan kontrol pemintal untuk menetapkan nilai yang Anda inginkan dan klik OK.

Kedengarannya persis seperti apa yang terjadi di sini, tetapi akhirnya menjadi perbaikan yang sangat mudah. Restart untuk sementara akan menyelesaikan masalah, tetapi segera setelah sesuatu mencoba menulis ke log, semuanya akan lepas kendali dan terus menghabiskan sumber daya.

Semoga ini membantu!


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

Tidak ada cara Anda dapat secara eksternal (benar) melepaskan memori yang dialokasikan atau menangani sumber daya tanpa membunuh aplikasi yang menyinggung.

>or avoid the bug all together? 

Anda mengalami kebocoran memori dan sumber daya. Satu-satunya cara Anda akan memecahkan masalah adalah menemukan kebocoran dan menghindari pemicunya (jika mungkin) atau memperbaiki kebocoran pada tingkat kode sumber; Dalam kasus terakhir Anda memerlukan bantuan Microsoft untuk memproduksi tambalan, tetapi tampaknya mereka mengharapkan Anda untuk memberi tahu mereka "persis" di mana masalahnya sebenarnya.

Anda dapat mencoba menemukan pelakunya dengan menunjukkan dengan tepat kebocoran memori / sumber daya dengan menggunakan mis. MS Application Verifier


Pemicunya adalah berbagi file, yang tidak bisa kita hindari.
Craig

jika Anda tidak dapat menghindari pelatuk kemudian temukan kebocoran dengan "Application Verifier" dan hubungi MS dengan info itu.
Pat

Aplikasi, karena ada banyak, semuanya adalah Microsoft. Kami sudah menghubungi mereka, kami mencari solusi yang lebih cepat karena mereka menyatakan mungkin butuh berminggu-minggu / bulan untuk menyelesaikannya.
Craig

Mempertimbangkan MS tidak akan terburu-buru untuk menyelesaikan masalah seperti ini pada OS tidak lancar Saya tidak berpikir Anda akan menemukan solusi yang lebih cepat. Hal yang berbeda adalah jika Anda memberi tahu mereka di mana kebocoran itu berada.
Pat

Kami memiliki kasing terbuka dan telah bekerja dengan mereka selama sebulan. Kebocoran secara harfiah ada di layanan Workstation.
Craig

-1

Membuat RAM itu mudah tetapi tidak ada solusi.

Saya sarankan Sysinternals RAMMAP atau VMMAP untuk penyelidikan lebih dalam. Dengan alat ini, Anda dapat melihat dengan lebih baik apa yang terjadi. sangat sering itu masalah metafile.

Sejak Server 2008 kami memiliki masalah ini dengan semua server terminal kehabisan memori dengan konsumsi memori yang luar biasa dari waktu ke waktu ketika memulai aplikasi dari berbagi.

Solusi kami adalah meng-hosting aplikasi itu pada Terminal Server yang terpisah dan sering membersihkan konsumsi memori.

Kami melakukan ini dengan aplikasi baris perintah c ++ yang dirancang sendiri menggunakan
SetProcessWorkingSetSize () dengan SeDebugPrivilege pada semua proses

Sangat disarankan untuk tidak melakukan sesuatu seperti ini;)


Mengapa downvote? Ini persis apa yang diminta! Dengan senang hati mencoba membantu di sini ...
Magnus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.