Server Terminal R2 2008: "Tidak ada sumber daya sistem untuk menyelesaikan layanan yang diminta"

Saya bekerja dengan Server Terminal Windows 2008 R2 tidak sehat yang dikonfigurasi di lingkungan vSphere. Saat ini memiliki 4 vCPU dan 32GB RAM. Tidak ada komitmen berlebihan.

Jumlah pengguna bersamaan di server ini telah meningkat tajam dalam beberapa bulan terakhir (~ 70), dan mungkin melebihi tingkat yang disarankan. Karena aplikasi yang digunakan oleh pengguna pada sistem ini, membaginya menjadi beberapa server akan menjadi tantangan di luar cakupan pertanyaan ini.

Namun, pada titik-titik tertentu selama seminggu (dan sekarang, hampir setiap hari), login pengguna baru menghasilkan kesalahan berikut: ID Peristiwa 1500

Windows tidak dapat masuk Anda karena profil Anda tidak dapat dimuat. Periksa apakah Anda terhubung ke jaringan, dan bahwa jaringan Anda berfungsi dengan benar.

DETAIL - Sumber daya sistem tidak mencukupi untuk menyelesaikan layanan yang diminta.

Ini tetap sampai beberapa pengguna keluar, sesi terputus secara manual atau sistem reboot sepenuhnya.

Saya ingin tahu:

• Sumber daya apa yang dimaksud dengan pesan kesalahan ini? Apa yang sebenarnya terkendala?
• Apakah ada tingkat merdu atau konfigurasi OS yang dapat membantu dengan ini?
• Pengguna puas dengan kinerja, kecuali peningkatan frekuensi pesan kesalahan ini. Apakah ada hal lain yang dimainkan di sini?
• Apakah ada batasan absolut untuk jumlah pengguna yang dapat ditampung oleh server terminal? Saya melihat 150+ pengguna yang dijelaskan dalam panduan penyetelan tertentu untuk Server Terminal.

Ini sudah dipecahkan.

Saya mulai memeriksa registri karena meningkatkan sumber daya CPU dan RAM pada mesin virtual tidak menyelesaikan masalah.

Saya diarahkan ke alat dureg Microsoft untuk memperkirakan ukuran registri. Menjelajah melalui regedit, saya mengalami masalah saat membuka kunci di bawah HKEY_USERS\.Default\PRINTERS. Dengan menggunakan dureg, saya mulai menyelidiki di bawah hierarki itu.

Printer adalah masalahnya. Penyebab dan perbaikan dirinci dalam:
Ukuran kumpulan registri "HKEY_USERS.DEFAULT" terus meningkat pada server berbasis Windows Server 2008 R2 SP1

Perbaikan terbaru: http://support.microsoft.com/kb/2871131

Ini tampaknya menghentikan pertumbuhan, tetapi kunci dan registri perlu dikompresi untuk merebut kembali ruang.

Mengompresi registri bengkak: http://support.microsoft.com/kb/2498915

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

Hmm, beberapa langkah ... agak sulit dilakukan dari jarak jauh selama jam produksi. Saya mencoba menghubungi ahli Microsoft residen saya untuk menyelesaikan, tetapi dia sibuk mengejar beberapa masalah SCCM atau SCVMM di suatu tempat . Membaca melalui beberapa forum yang berhubungan dengan Citrix, saya mencatat alat yang dapat melakukan hal di atas dengan langkah-langkah yang lebih sedikit ...

Jadi saya mengambil snapshot mesin virtual, kemudian mengunduh dan menjalankan perangkat lunak kompresi registri freeware (Tweaking.com) ; meskipun suara luar biasa dari keluhan kolektif insinyur sistem Microsoft di mana-mana ...

perhatikan 1.4GB yang disimpan dalam Konfigurasi default ...

SILAKAN REBOOT!

Setelah reboot, semuanya baik-baik saja. Hitungan pengguna mencapai 86 tanpa efek buruk dan tidak ada kesalahan terkait profil. Saya sudah memonitor kumpulan registri printer dan sudah stabil.

Di Windows Server 2003 kesalahan itu adalah hasil dari kehabisan memori kernel. Karena Anda sedang berhadapan dengan Windows Server 2008 R2, saya tidak yakin seberapa dekat kaitannya dengan penyebabnya pada W2K3, tetapi saya berani bertaruh bahwa ini adalah masalah memori karena jumlah pengguna dan proses. Saya akan melihat kelelahan memori Nonpaged Pool sebagai kemungkinan penyebabnya. Selain itu, jumlah proses hampir 800, yang cukup tinggi. MS mungkin akan memberitahu Anda untuk mengurangi jumlah proses, yang hanya bisa dilakukan dengan mengurangi beban pengguna.

Artikel ini memiliki beberapa informasi yang baik mengenai penggunaan memori di Windows dan bagaimana Anda dapat melihat batas Nonpaged Pool untuk melihat apakah itu penyebab masalahnya:

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Mulai Windows Performance Monitor untuk memantau berbagai penghitung:

• Sakelar Konteks
• Entri Tabel Halaman
• Elemen GDI
• Pegangan
• ... (apa pun yang dapat Anda temukan)

Dan lihat apakah salah satu dari puncak ini ketika Anda mendapatkan login gagal.

Juga: sesuatu menyebabkan% CPU kernel tinggi pada sistem Anda - Anda harus menyelidiki itu untuk melihat apakah itu membawa Anda ke masalah terkait.

Layanan Pembersihan Sarang Profil Pengguna dapat membantu di sini karena "membantu memastikan sesi pengguna benar-benar dihentikan ketika pengguna keluar".

Nah, dari apa yang saya baca tentang perencanaan kapasitas RDS di Server 2008 R2, Anda mungkin menjalankan server terminal Anda yang buruk dengan sumber daya yang tidak mencukupi untuk jumlah pengguna yang Anda gunakan. Secara khusus, saya perhatikan bahwa Anda memiliki 80 pengguna pada 4 vCPUS, dan MS merekomendasikan 1 inti per 15 pengguna.

Dari blog technet berjudul RDS Sizing dan Pedoman Perencanaan Kapasitas :

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

• 2GB Memory (RAM) adalah batas optimal untuk setiap inti CPU. Misalnya Jika Anda memiliki RAM 4 GB maka untuk kinerja optimal harus ada CPU dual core.
• 2 CPU Dual Core tampil lebih baik daripada prosesor Quad core tunggal.
• Bandwidth yang disarankan untuk LAN dari 30 pengguna dan WAN dari 20 pengguna. Bandwidth (b) = 100 megabit per detik (Mbps) dengan Latency (l) Kurang dari 5 milidetik.
• Pada Terminal Server, 64 MB per pengguna adalah persyaratan Memori Ideal (RAM) untuk GP. Gunakan hanya + 2 GB untuk OS. Misalnya (100 pengguna * 64) + 2000 = 8,4 GB, yaitu 8GB RAM.
• Semakin banyak aplikasi yang digunakan (mis. Office, Aplikasi CAD, dll.) Akan membutuhkan lebih banyak memori per pengguna yang akan ditambahkan ke perhitungan ini di atas memori dasar 64 MB per pengguna.
• 15 sesi TS per inti CPU adalah batas kinerja optimal Terminal Server.
• Jaringan tidak boleh lebih dari 5 hop, dan latensi harus di bawah 100 ms.
• 64 kbps adalah Bandwidth Ideal per sesi pengguna. (256 warna, jaringan diaktifkan, caching bitmap saja)
• Kinerja CPU menurun jika% waktu prosesor per inti terus di atas 65%.
• Kinerja server terminal berlipat ganda ketika dijalankan pada X64 HW dan OS.

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

Unduh di sini

Saya memiliki waktu yang sangat sedikit sehingga saya hanya akan melakukan jawaban yang samar dan mudah-mudahan menyempurnakannya nanti.

Ketika saya melakukan mantra dalam tim Citrix, saya ingat kami mencoba meningkatkan level menjadi 15-20 pengguna per server, tetapi mereka menjalankan beberapa aplikasi berat. Saat ini x64 kami memuat lebih banyak pengguna, tetapi 70+ memang terdengar sangat banyak.

Perfmon counter maxing out tidak jarang beralih konteks, itu akan lantai server sementara penghitung lain seperti RAM, CPU dll terlihat bagus. Mungkin itu bisa menjadi alasan (server tidak dapat mengalokasikan sumber daya sebelum waktu habis karena pengalihan konteks yang berlebihan). Berikut adalah dua cara untuk memantau pengalihan konteks :

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

Juga Anda mungkin menemukan sesuatu yang berguna dalam panduan perencanaan kapasitas, Anda menemukan tautan untuk itu di posting blog ini .

Ketika saya dapat menarik waktu pada jawaban ini saya akan melakukannya, saya hanya akan menambahkan di sini dengan hati-hati pada semua pengukuran berbasis waktu dalam mesin virtual vSphere.

Karena bagaimana vCPU telah diabstraksi dari CPU fisik, vCPU tidak memiliki petunjuk jam berapa sekarang (satu detik virtual mungkin lebih atau kurang dari satu detik nyata (atau setidaknya fisik). Sebagai konsekuensinya, semua waktu berdasarkan penghitung perfmon (waktu CPU, sakelar konteks / detik dan sebagainya) tidak akurat (kadang-kadang bahkan sangat liar), bahkan jika mereka berfungsi sebagai indikator berbutir kasar.

Untuk memverifikasi ini, bandingkan penghitung CPU berbasis waktu asli dalam VM dengan mitranya pada host vSphere untuk VM itu. Untuk alasan ini VMware menerbitkan beberapa penghitung untuk CPU (dan Memori yang juga tidak akurat dari perspektif tamu) melalui alat VMware menjadi dua objek perfoma VMguest.

Dengan demikian nilai-nilai berdasarkan waktu yang tepat dibuat tersedia dari dalam perfmon tamu, tetapi hanya jika seseorang melihat penghitung objek yang diterbitkan VMware.

Saya hanya berpikir info dasar ini sedikit relevan karena jawaban sejauh ini berfokus pada pengukuran berdasarkan waktu dari dalam mesin virtual vSphere, di mana ini dalam beberapa kasus keadaan penting untuk analisis yang benar. Tentu saja ini juga berkaitan langsung dengan tema dari jawaban (komentar yang belum selesai) ini dan komentarnya. Mungkin bermanfaat bagi seseorang.

Segera setelah saya mendapatkan waktu saya akan mengedit tautan ke whitepapers dll yang menguraikan ini, dan path counter yang tepat \ nama. Tentu saja semua juga dapat di-googleable.

Saya akan menyarankan menerapkan WSRM (Windows System Resource Manager). Ketika ada banyak aplikasi, koneksi, layanan yang berjalan di satu host, sistem tidak tahu bahwa semua orang perlu bermain baik bersama. Windows Server secara alami mencoba menggunakan semua sumber dayanya untuk menyelesaikan semuanya setiap saat kecuali jika disadari ... masuk WSRM.

Dengan menerapkan WSRM Anda dapat menetapkan batas sumber daya dengan segala macam variasi untuk memastikan ada lapangan bermain yang merata untuk semua yang berjalan atau pengguna yang terhubung. Dari catatan Anda, ini sepertinya bukan masalah ESX / vSphere tetapi terlalu banyak pengguna yang terhubung yang terus-menerus bersaing untuk semuanya. Anda harus menguji WSRM untuk menemukan media penyeimbangan sumber daya yang bahagia di antara segalanya, tetapi juga tidak memengaruhi tingkat kinerja yang sudah biasa digunakan semua orang.

Ikhtisar WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx