2008 R2 Terminal Server: “İstenen hizmeti tamamlamak için yeterli sistem kaynağı yok”

VSphere ortamında yapılandırılmış sağlıksız bir Windows 2008 R2 Terminal Server ile çalışıyorum. Şu anda 4 vCPU ve 32 GB RAM var. Fazla taahhüt yok.

Bu sunucudaki eşzamanlı kullanıcı sayısı son aylarda (~ 70) keskin bir şekilde arttı ve muhtemelen önerilen düzeyin üzerinde. Bu sistemdeki kullanıcılar tarafından kullanılan uygulamalar nedeniyle, bunu birden çok sunucuya bölmek bu sorunun kapsamı dışında bir zorluk olacaktır.

Ancak, haftanın belirli noktalarında (ve şimdi, neredeyse her gün), yeni kullanıcı oturum açma işlemleri aşağıdaki hataları üretir: Olay Kimliği 1500

Profiliniz yüklenemediğinden Windows oturum açamıyor. Ağa bağlı olduğunuzdan ve ağınızın düzgün çalıştığından emin olun.

DETAY - İstenen hizmeti tamamlamak için yeterli sistem kaynağı yok.

Bu, bazı kullanıcılar oturumu kapatana, oturumların manuel olarak bağlantısı kesilene veya sistem tamamen yeniden başlatılıncaya kadar aynı kalır.

Bilmek isterdim:

• Bu hata mesajı hangi kaynaklara atıfta bulunuyor? Aslında ne kısıtlı?
• Bu konuda yardımcı olabilecek bir işletim sistemi düzeyinde ayarlanabilir veya yapılandırma var mı?
• Kullanıcılar, bu hata iletisinin artan sıklığı dışında, performansı olan içeriklerdir. Burada oynayan başka bir şey var mı?
• Terminal sunucusunun alabileceği kullanıcı sayısında mutlak bir sınır var mı? Terminal Sunucuları için belirli ayar kılavuzlarında açıklanan 150'den fazla kullanıcı görüyorum.

Bu çözüldü.

Sanal makinedeki artan CPU ve RAM kaynakları sorunu çözmediği için kayıt defterini incelemeye başladım.

Kayıt defterinin boyutunu tahmin etmek için Microsoft'un dureg aracına işaret ettim . Regedit aracılığıyla göz atarken, altındaki anahtarları açarken sorunlarla karşılaştım HKEY_USERS\.Default\PRINTERS. Kullanarak dureg, o hiyerarşi altında araştırma yapmaya başladım.

Sorun yazıcılardı. Nedeni ve düzeltmesi ayrıntılı olarak açıklanmaktadır:
Windows Server 2008 R2 SP1 tabanlı bir sunucuda "HKEY_USERS.DEFAULT" kayıt defteri kovanının boyutu sürekli artmaktadır

Düzeltme: http://support.microsoft.com/kb/2871131

Bu görünüşe göre büyümeyi durduruyor, ancak alanın geri kazanılması için anahtarların ve kayıt defterinin sıkıştırılması gerekiyor.

Şişirilmiş kayıt defterini sıkıştırma: 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, birkaç adım ... üretim saatlerinde uzaktan yapmak biraz zor. Tamamlamak için yerleşik Microsoft uzmanımla iletişime geçmeye çalıştım , ancak bir yerde bazı SCCM veya SCVMM sorununu takip etmekle meşguldü . Citrix ile ilgili forumlardan bazılarını okurken, yukarıdakileri daha az adımla gerçekleştirebilecek bir aracı not ettim ...

Bu yüzden sanal bir makine anlık görüntüsü aldım, sonra indirip ücretsiz kayıt defteri sıkıştırma yazılımı çalıştırdım (Tweaking.com) ; her yerde Microsoft sistem mühendislerinin kolektif inilti seslerine rağmen ...

1.4GB varsayılan yapılandırmaya kaydedildi ...

LÜTFEN YENİDEN BAŞLATIN!

Yeniden başlatmanın ardından her şey yolundaydı. Kullanıcı sayısı, hiçbir olumsuz etki ve profile bağlı hata olmadan 86'ya ulaştı. Yazıcı kayıt defteri kovanını izledim ve sabit tutuldu.

Windows Server 2003'te bu hata çekirdek bellek tükenmesinin bir sonucuydu. Windows Server 2008 R2 ile uğraştığınız için sorunun nedeninin W2K3'teki nedenle ne kadar yakından ilişkili olduğundan emin değilim, ancak kullanıcı ve işlem sayısı nedeniyle bir bellek sorunu olduğuna eminim. Disk belleği olmayan havuz bellek tükenmesine olası neden olarak bir göz atın. Buna ek olarak, işlem sayısı neredeyse 800'dür ve bu oldukça yüksektir. MS muhtemelen yalnızca kullanıcı yükünü azaltarak yapılabilecek işlem sayısını azaltmanızı söyler.

Bu makalede, Windows'ta bellek kullanımı ve sorunun nedeni olup olmadığını görmek için Disk belleği olmayan havuz sınırını nasıl görüntüleyebileceğinizle ilgili bazı iyi bilgiler bulunur:

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

Çeşitli sayaçları izlemek için Windows Performans İzleyicisi'ni başlatın:

• Bağlam Anahtarları
• Sayfa Tablosu Girişleri
• GDI öğeleri
• Kolları
• … (Ne bulabilirsiniz?)

Ve başarısız bir giriş aldığınızda bu zirvelerden birinin olup olmadığını görün.

Ayrıca: bir şey sisteminizde% yüksek çekirdek CPU'ya neden oluyor - bunun sizi ilgili bir soruna götürüp götürmediğini görmek için araştırmalısınız.

Kullanıcı profili yığını temizleme planın "kullanıcı oturumu kapattığında kullanıcı oturumları tamamen sonlandırılır sağlamaya yardımcı olur" şeklinde hizmet burada yardım edebilir.

Sunucu 2008 R2'deki RDS kapasite planlaması hakkında okuduğum kadarıyla, kötü terminal sunucunuzu, kullandığınız kullanıcı sayısı için yetersiz kaynaklarda çalıştırıyor olabilirsiniz. Özellikle, 4 vCPUS üzerinde 80 kullanıcınız olduğunu fark ediyorum ve MS 15 kullanıcı başına 1 çekirdek öneriyor.

RDS Boyutlandırma ve Kapasite Planlama Kılavuzu adlı teknoloji blogundan :

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 Bellek (RAM) bir CPU'nun her bir çekirdeği için en uygun sınırdır. 4 GB RAM'iniz varsa, optimum performans için Çift çekirdekli CPU olmalıdır.
• 2 Çift Çekirdekli CPU, tek Dört çekirdekli işlemciden daha iyi performans gösterir.
• 30 kullanıcının LAN ve 20 kullanıcının WAN için önerilen bant genişliği. Bant genişliği (b) = Gecikme (l) 5 milisaniyeden az olan saniyede 100 megabit (Mbps).
• Terminal Sunucusunda GP için Kullanıcı başına 64 MB gereksinimi idealdir OS için yalnızca + 2 GB kullanın Eg (100 kullanıcı * 64) + 2000 = 8.4 GB yani 8GB RAM.
• Kullanılan daha fazla uygulama (yani Office, CAD Uygulamaları vb.), Kullanıcı başına 64 MB temel bellek üzerinden bu hesaplamaya kullanıcı başına daha fazla bellek eklenmesini gerektirecektir.
• CPU çekirdeği başına 15 TS oturumu, Terminal Sunucusunun optimum performans sınırıdır.
• Ağın 5 atlamadan fazla olmaması ve gecikmenin 100 ms'nin altında olması gerekir.
• 64 kbps kullanıcı oturumu başına İdeal Bant Genişliğidir. (256 renk, anahtarlamalı ağ, yalnızca bitmap önbelleğe alma)
• Çekirdek başına% işlemci süresi sürekli olarak% 65'in üzerindeyse CPU performansı düşer.
• Terminal sunucularının performansı, bir X64 HW ve işletim sisteminde çalışırken iki katına çıkar.

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

Buradan indir

Çok az zamanım var, bu yüzden sadece kabataslak bir cevap vereceğim ve umarım sonradan ettim.

Citrix ekiplerinde büyüler yaparken sunucu başına 15-20 kullanıcıyı seviyelendirmeye çalıştığımızı hatırlıyorum, ancak bazı ağır uygulamalar çalışıyor. Bu günlerde x64 daha fazla kullanıcı yüklüyor, ancak 70+ çok fazla ses çıkarıyor.

Perfmon sayacı maxing out nadiren bağlam anahtarlama değildi, RAM, CPU vb gibi diğer sayaçlar iyi görünüyordu iken bir sunucu zemin olacaktır. Muhtemelen bu bir sebep olabilir (sunucu, aşırı bağlam geçişi nedeniyle zaman aşımına uğramadan kaynak ayıramaz). Bağlam değiştirmeyi izlemenin iki yolu şunlardır :

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.

Ayrıca kapasite planlama kılavuzunda bir şeyler bulabilirsiniz, bu blog gönderisinde bir bağlantı bulabilirsiniz .

Bu cevaba zaman ayırabildiğimde, bunu vSphere sanal makinesindeki tüm zaman bazlı ölçümlere dikkat ederek ekleyeceğim.

VCPU'nun fiziksel CPU'lardan nasıl soyutlandığına bağlı olarak, vCPU'nun saatin kaç olduğu hakkında bir ipucu yoktur (bir sanal saniye bir gerçek (veya en azından fiziksel) saniyeden daha fazla veya daha az olabilir. perfmon sayaçlar (CPU zamanı, bağlam anahtarları / sn vb.) çok kaba taneli göstergeler olarak hizmet etseler bile yanlıştır (bazen çok çılgınca).

Bunu doğrulamak için, VM içindeki yerel zaman tabanlı CPU sayacını o VM için vSphere ana bilgisayarındaki karşılığıyla karşılaştırın. Bu nedenle VMware, VMware araçları aracılığıyla CPU (ve konuk açısından da yanlış olan Bellek) için bazı sayaçları iki VMguest perfmon nesnesine yayınlar.

Böylece, doğru zaman tabanlı değerler konuk perfmonu içinden kullanılabilir, ancak yalnızca VMware tarafından yayınlanan nesne sayaçlarına bakarsanız.

Şimdiye kadar verilen cevaplar vSphere sanal makinesinden zaman bazlı ölçümlere odaklandığından, bu temel bilgilerin biraz alakalı olduğunu düşündüm, bu bazı durumlarda doğru analiz için çok önemli bir durumdur. Ayrıca elbette doğrudan bu özel (bitmemiş) cevabın teması ve yorumları ile ilgilidir. Birisi için yararlı olabilir.

Zaman alır almaz, bu konuyu ayrıntılandıran teknik incelemelere vb. Bağlantılarda ve tam sayaç yollarında \ isimleri düzenleyeceğim. Doğal olarak hepsi de googleable.

WSRM (Windows Sistem Kaynağı Yöneticisi) uygulamasını öneririm. Bir ana bilgisayarda çalışan bir ton uygulama, bağlantı, hizmet olduğunda, sistem herkesin birlikte iyi oynaması gerektiğini bilmez. Windows Server, doğal olarak farkında olunmadıkça her şeyi tamamlamak için tüm kaynaklarını kullanmaya çalışır ... WSRM'ye girin.

WSRM'yi uygulayarak, çalışan her şey veya bağlı kullanıcılar için eşit bir oyun alanı olduğundan emin olmak için her türlü varyasyona göre kaynak sınırları belirleyebilirsiniz. Notlarınızdan bu bir ESX / vSphere sorunu değil, her şey için sürekli rekabet eden çok sayıda bağlı kullanıcı gibi görünüyor. Her şey arasında kaynakları dengelemek için mutlu bir ortam bulmak için WSRM'yi test etmeniz gerekecek, aynı zamanda herkesin alıştığı performans seviyelerini etkilemeyeceksiniz.

WSRM Genel Bakış: http://technet.microsoft.com/en-us/library/cc732553.aspx