2008 R2 टर्मिनल सर्वर: "अपर्याप्त सिस्टम संसाधन अनुरोधित सेवा को पूरा करने के लिए मौजूद हैं"


21

मैं एक अस्वास्थ्यकर विंडोज 2008 R2 टर्मिनल सर्वर के साथ काम कर रहा हूं जो vSphere वातावरण में कॉन्फ़िगर किया गया है। इसमें वर्तमान में 4 vCPU और 32GB रैम है। कोई ओवरकमिटमेंट नहीं।

इस सर्वर पर समवर्ती उपयोगकर्ता गणना हाल के महीनों (~ 70) में तेजी से बढ़ी है, और संभवतः अनुशंसित स्तर से अधिक है। इस प्रणाली पर उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले अनुप्रयोगों के कारण, इसे कई सर्वरों में विभाजित करना इस प्रश्न के दायरे से परे एक चुनौती होगी।

हालांकि, सप्ताह के दौरान कुछ बिंदुओं पर (और अब, लगभग दैनिक), नए उपयोगकर्ता लॉगऑन निम्न त्रुटियां उत्पन्न करते हैं: इवेंट आईडी 1500

Windows आपको लॉग ऑन नहीं कर सकता क्योंकि आपकी प्रोफ़ाइल लोड नहीं की जा सकती। जांचें कि आप नेटवर्क से जुड़े हैं, और यह कि आपका नेटवर्क सही ढंग से काम कर रहा है।

डीटेल - अपर्याप्त सिस्टम संसाधन अनुरोधित सेवा को पूरा करने के लिए मौजूद हैं।

यह तब तक रहता है जब तक कुछ उपयोगकर्ता लॉग ऑफ नहीं हो जाते, सत्र मैन्युअल रूप से डिस्कनेक्ट हो जाते हैं या सिस्टम पूरी तरह से रिबूट हो जाता है।

मैं जानना चाहता हूं:

  • इस त्रुटि संदेश का क्या संसाधन है? वास्तव में क्या अड़चन है?
  • क्या कोई ओएस-स्तरीय ट्यून करने योग्य या कॉन्फ़िगरेशन है जो इसके साथ मदद कर सकता है?
  • उपयोगकर्ता इस त्रुटि संदेश की बढ़ी हुई आवृत्ति को छोड़कर प्रदर्शन के साथ संतुष्ट हैं। क्या यहां कुछ और है?
  • क्या उन उपयोगकर्ताओं की संख्या की पूर्ण सीमा है जो एक टर्मिनल सर्वर समायोजित कर सकता है? मुझे टर्मिनल सर्वर के लिए कुछ ट्यूनिंग गाइड में वर्णित 150+ उपयोगकर्ता दिखाई देते हैं।

यहां छवि विवरण दर्ज करें

यहां छवि विवरण दर्ज करें


क्या यह आपकी समस्या है? । मैं यह नहीं कह सकता कि मैंने इसे Windows Server 2008 R2 सर्वर पर अनुभव किया है , लेकिन मैं 2003 और 2008 में इसमें बहुत भाग गया, इसलिए शायद यह अभी भी लागू होता है।
होपलेसएनबीबी

@ HopelessN00b इवेंट आईडी 1508 जिसे अक्सर संदर्भित किया जाता है वह इस वातावरण में प्रकट नहीं होता है। मेरे अधिकांश शोधों ने मुझे विंडोज 2003 परिवेशों की ओर अग्रसर समाधानों की ओर अग्रसर किया है, लेकिन शायद मेरा Google कौशल अभी बंद है ...
ewhite

यह 2003 के लिए है, लेकिन आप इसे प्रासंगिक
लगने

@ HopelessN00b मैंने जाँच की RegistrySizeLimit, और यह परिभाषित नहीं है।
इविहित

1
@ErikE उन रजिस्ट्री प्रविष्टियों को 2008 R2 में अनदेखा कर दिया गया
इविविट

जवाबों:


16

यह हल हो गया है।

मैंने रजिस्ट्री की जांच करना शुरू कर दिया क्योंकि वर्चुअल मशीन पर सीपीयू और रैम के संसाधन बढ़ने से समस्या हल नहीं हुई।

मुझे रजिस्ट्री के आकार का अनुमान लगाने के लिए Microsoft के dureg टूल की ओर इशारा किया गया था । Regedit के माध्यम से ब्राउज़ करते हुए, मुझे कुंजी को नीचे खोलने वाले मुद्दों का सामना करना पड़ा HKEY_USERS\.Default\PRINTERS। उपयोग करते हुए dureg, मैंने उस पदानुक्रम के तहत जांच शुरू की।


प्रिंटर की समस्या थी। कारण और फ़िक्स विस्तृत हैं:
"HKEY_USERS.DEFAULT" रजिस्ट्री हाइव का आकार Windows Server 2008 R2 SP1- आधारित सर्वर पर लगातार बढ़ता रहता है

हॉटफ़िक्स: http://support.microsoft.com/kb/2871131

यह स्पष्ट रूप से विकास को रोकता है, लेकिन चाबियाँ और रजिस्ट्री को अंतरिक्ष को पुनः प्राप्त करने के लिए संपीड़ित करने की आवश्यकता होती है।

कंपित फूला हुआ रजिस्ट्री: 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

हम्म, कुछ कदम ... थोड़े मुश्किल उत्पादन के समय के दौरान दूर करने के लिए। मैंने पूरा करने के लिए अपने निवासी Microsoft विशेषज्ञ तक पहुंचने की कोशिश की , लेकिन वह कहीं न कहीं SCCM या SCVMM समस्या का पीछा करने में व्यस्त था । कुछ Citrix से संबंधित मंचों के माध्यम से पढ़ते हुए, मैंने एक ऐसे टूल पर ध्यान दिया, जो कम चरणों के साथ ऊपर प्रदर्शन कर सकता है ...

इसलिए मैंने एक वर्चुअल मशीन स्नैपशॉट लिया, फिर डाउनलोड किया और फ्रीवेयर रजिस्ट्री कंप्रेशन सॉफ्टवेयर (Tweaking.com) चलाया ; हर जगह Microsoft सिस्टम इंजीनियरों के सामूहिक कराहने की भारी आवाज़ के बावजूद ...

डिफ़ॉल्ट कॉन्फ़िगरेशन में सहेजे गए 1.4GB पर ध्यान दें ... Tucows

कृपया दुबारा शुरू करें!

रिबूट के बाद, सब ठीक था। उपयोगकर्ता संख्या 86 बिना किसी बुरे प्रभाव और बिना प्रोफ़ाइल-संबंधी त्रुटियों के साथ पहुंच गई। मैंने प्रिंटर रजिस्ट्री हाइव की निगरानी की है और इसे स्थिर रखा है।


क्या RDP प्रिंटर पुनर्निर्देशन को अक्षम करके इसे रोका जा सकता था? कभी-कभी क्लाइंट्स के पास भयानक प्रिंट ड्राइवर होंगे जो आरडीपी के लिए जो भी सर्वर होते हैं उनकी नकल करते हैं। बेशक, एक टर्मिनल सर्वर के लिए आपको RDP प्रिंटर पुनर्निर्देशन की आवश्यकता हो सकती है ...

1
@kce इस वातावरण में सभी ग्राहक पतले ग्राहक थे, शायद 2 या 3 पीसी को छोड़कर। ग्राहक पर GPO के बजाय TS पर स्थानीय प्रिंटर स्थापित करने के साथ एक समस्या भी हो सकती है - वितरित प्रिंटर ... लेकिन हॉटफ़िक्स में उल्लिखित बग एक मुद्दा था।
ewwhite

निदान, हॉटफिक्स और उपकरण के लिए धन्यवाद! मैं इस मुद्दे को एक बार फिर से याद कर रहा हूं, लेकिन फिर एक असंबंधित कुल भ्रष्टाचार हुआ, इसलिए मैंने बस सब कुछ पुनः स्थापित किया। अगर मैं भविष्य में इसी तरह की समस्या का अनुभव करता हूं, तो मैं निश्चित रूप से अपने एवरनोट में इसे बुकमार्क करूंगा। फिर से धन्यवाद!
पेपोलुआन

अभिलेखों के लिए, मैंने ऊपर किया है और इसे हल कर दिया है, लेकिन अब मैं एक और रजिस्ट्री ब्लोटिंग का सामना कर रहा हूं: HKU\.DEFAULT\Software\Hewlett-Packardऔर HKU\.DEFAULT\Software\Lexmarkदोनों मिलकर DEFAULT रजिस्ट्री फ़ाइल के लगभग 1.2GB तक बना रहे हैं!
ईटीएल

3

Windows Server 2003 में वह त्रुटि कर्नेल मेमोरी थकावट का परिणाम थी। क्योंकि आप Windows Server 2008 R2 के साथ काम कर रहे हैं, मुझे यकीन नहीं है कि समस्या का कारण W2K3 में कितनी बारीकी से संबंधित है, लेकिन मैं शर्त लगाता हूं कि यह उपयोगकर्ताओं और प्रक्रियाओं की संख्या के कारण एक स्मृति मुद्दा है। मैं संभावित कारण के रूप में नॉनपेजेड पूल मेमोरी थकावट पर एक नज़र डालूंगा। इसके अलावा, भविष्यवाणियों की संख्या लगभग 800 है, जो काफी अधिक है। एमएस शायद आपको प्रक्रियाओं की संख्या कम करने के लिए कहेंगे, जो केवल उपयोगकर्ता भार को कम करके किया जा सकता है।

इस लेख में विंडोज में मेमोरी के उपयोग के बारे में कुछ अच्छी जानकारी है और आप यह देखने के लिए कि क्या समस्या का कारण है, यह देखने के लिए नॉनपेजेड पूल की सीमा को देख सकते हैं:

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


2
800 प्रक्रियाएं बहुत अधिक हैं!? लेकिन लिनक्स में ... :
ewhite

800 से अधिक प्रक्रियाओं के लिनक्स के उच्च होने की शिकायत करने से पहले, मॉनिटर को प्रोसेस करने के लिए "थ्रेड्स" कॉलम जोड़ें और देखें कि उनमें से कितने आप देखते हैं ... लिनक्स और विंडोज में प्रक्रियाएं अलग-अलग पक्षी हैं। उनकी तुलना करना कर्नेल डिज़ाइन दोनों के लिए अनुचित है।
मार्क

2

विभिन्न काउंटरों की निगरानी के लिए Windows प्रदर्शन मॉनिटर शुरू करें:

  • प्रसंग स्विच
  • पृष्ठ तालिका प्रविष्टियाँ
  • GDI तत्व
  • हैंडल
  • … (जो भी आप पा सकते हैं)

और देखें कि क्या आपको असफल लॉगिन मिलने पर इनमें से एक चोटियाँ हैं।

इसके अलावा: कुछ आपके सिस्टम पर उच्च कर्नेल CPU% पैदा कर रहा है - आपको इसकी जांच करनी चाहिए कि क्या यह आपको संबंधित समस्या की ओर ले जाता है।


उपयोगकर्ता प्रोफ़ाइल हाइव क्लीनअप सेवा यहाँ से बाहर मदद मिल सकती है के रूप में यह "सुनिश्चित करने के लिए उपयोगकर्ता सत्र पूरी तरह से समाप्त कर दिया जाता है जब कोई उपयोगकर्ता बंद लॉग में मदद करता है"।


क्या मैं अभी और vCPU जोड़ सकता हूँ?
इविविट

अधिक प्रसंस्करण शक्ति जोड़ने से उच्च कर्नेल% उपयोग ठीक नहीं होगा, यह सिर्फ इसे मास्क करेगा। साथ ही, यह सीधे आपकी लॉगिन विफलताओं का स्रोत नहीं है।
मिकीबी

जो मैं नीचे पाने की कोशिश कर रहा हूँ ...
ewhite

UPHClean उपयोगिता कार्यक्षमता को मूल रूप से उपयोगकर्ता प्रोफ़ाइल क्लीनअप सेवा के माध्यम से w2k8 और उसके बाद से प्रदान की जाती है।
एरिक

@ewwhite यहाँ एक Microsoft आलेख है जो W2k3 TS सर्वर पर PTE थकावट का उल्लेख करता है । यह देखने के लिए कि क्या आपके साथ हो रहा है, कुछ परफ़ॉर्म काउंटरों को फेंकने लायक हो सकता है।
होपलेसनब

1

खैर, मैंने आरडीएस क्षमता नियोजन के बारे में सर्वर 2008 आर 2 में पढ़ा है, आप केवल अपने घटिया टर्मिनल सर्वर को अपर्याप्त संसाधनों पर चला सकते हैं जो आपके द्वारा उपयोग किए जा रहे उपयोगकर्ताओं की संख्या के लिए है। विशेष रूप से, मुझे लगता है कि आपके पास 4 वीसीपीयूएस पर 80 उपयोगकर्ता हैं, और एमएस प्रति 15 उपयोगकर्ताओं में 1 कोर की सिफारिश करता है।

आरडीएस साइजिंग एंड कैपेसिटी प्लानिंग गाइडेंस नामक तकनीकी ब्लॉग से :

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:

  • 2 जीबी मेमोरी (रैम) सीपीयू के प्रत्येक कोर के लिए इष्टतम सीमा है। उदा। यदि आपके पास 4 जीबी रैम है तो इष्टतम प्रदर्शन के लिए दोहरी कोर सीपीयू होना चाहिए।
  • 2 डुअल कोर सीपीयू बेहतर प्रदर्शन करता है तो सिंगल क्वाड कोर प्रोसेसर।
  • 30 उपयोगकर्ताओं के लैन और 20 उपयोगकर्ताओं के वान के लिए अनुशंसित बैंडविड्थ। बैंडविड्थ (बी) = 100 मेगाबिट्स प्रति सेकंड (एमबीपीएस) के साथ लेटेंसी (एल) 5 मिलीसेकंड से कम।
  • टर्मिनल सर्वर पर 64 एमबी प्रति उपयोगकर्ता GP के लिए आइडियल मेमोरी (RAM) की आवश्यकता है, OS Eg के लिए + 2 GB (100 उपयोगकर्ता * 64) + 2000 = 8.4 GB अर्थात 8GB RAM का उपयोग करें।
  • उपयोग किए जाने वाले अधिक एप्लिकेशन (यानी ऑफिस, सीएडी एप्स और आदि) को प्रति उपयोगकर्ता 64 एमबी बेस मेमोरी से अधिक इस गणना में जोड़ा जाना चाहिए।
  • सीपीयू कोर प्रति 15 टीएस सत्र एक टर्मिनल सर्वर की इष्टतम प्रदर्शन सीमा है।
  • नेटवर्क में 5 से अधिक हॉप्स नहीं होने चाहिए, और विलंबता 100ms से कम होनी चाहिए।
  • 64 केबीपीएस प्रति उपयोगकर्ता सत्र के लिए आदर्श बैंडविड्थ है। (256 रंग, स्विच्ड नेटवर्क, बिटमैप कैशिंग केवल)
  • यदि CPU का कोर प्रोसेसर प्रति% लगातार 65% से ऊपर है, तो CPU प्रदर्शन कम हो जाता है।
  • टर्मिनल सर्वर का प्रदर्शन दोगुना हो जाता है जब वह X64 HW और OS पर चल रहा होता है।

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

यहाँ से डाउनलोड करें


1

मेरे पास बहुत कम समय है इसलिए मैं बस एक स्केच जवाब दूंगा और उम्मीद है कि इसे बाद में बाहर कर दिया जाएगा।

जब मैं Citrix टीमों में मंत्र कर रहा था तो मुझे याद है कि हम प्रति सर्वर 15-20 उपयोगकर्ताओं के स्तर की कोशिश कर रहे थे, लेकिन उन लोगों के पास कुछ भारी ऐप थे। इन दिनों x64 में हम अधिक उपयोगकर्ताओं को लोड करते हैं, लेकिन 70+ बहुत कुछ ध्वनि करता है।

परफ़ॉर्म काउंटर को अधिकतम करना शायद ही कभी संदर्भ स्विचिंग नहीं था, यह एक सर्वर को फ़्लिप करेगा, जबकि अन्य काउंटर जैसे रैम, सीपीयू आदि अच्छे दिखते थे। संभवतः यह एक कारण हो सकता है (अत्यधिक संदर्भ स्विचिंग के कारण समय से पहले सर्वर संसाधनों को आवंटित नहीं कर सकता है)। संदर्भ स्विचिंग की निगरानी करने के दो तरीके यहां दिए गए हैं :

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.

साथ ही आपको क्षमता नियोजन गाइड में कुछ उपयोग मिल सकता है, आपको इस ब्लॉग पोस्ट में इसका लिंक मिल जाएगा ।

जब मैं इस उत्तर पर समय खींच सकता हूँ तो मैं ऐसा करूँगा, मैं अभी यहाँ एक सबस्क्रिप्शन वर्चुअल मशीन के भीतर हर समय आधारित माप में सावधानी से फेंक रहा हूँ।

वीसीपीयू को भौतिक सीपीयू से कैसे अलग किया गया है, इसके कारण वीसीपीयू के पास यह संकेत नहीं है कि यह समय क्या है (एक आभासी दूसरा एक वास्तविक (या कम से कम भौतिक) सेकंड से अधिक या कम हो सकता है। परिणामस्वरूप, सभी समय आधारित। परफ्यूम काउंटर (सीपीयू समय, संदर्भ स्विच / सेकंड और इतने पर) गलत हैं (कभी-कभी बेतहाशा ऐसा भी), भले ही वे बहुत मोटे अनाज संकेतक के रूप में सेवा कर सकते हैं।

इसे सत्यापित करने के लिए, VM के भीतर किसी भी मूल समय आधारित CPU काउंटर की तुलना उस VM के vSphere होस्ट पर उसके समकक्ष के साथ करें। इस कारण से वीएमवेयर ने वीएमवेयर टूल्स के जरिये सीपीयू (और मेमोरी जो अतिथि दृष्टिकोण से भी गलत है) के लिए कुछ काउंटरों को दो VMguest परफ़ॉर्म ऑब्जेक्ट में प्रकाशित करता है।

इस प्रकार सही समय आधारित मूल्य अतिथि इत्र के भीतर से उपलब्ध कराए जाते हैं, लेकिन केवल अगर VMware प्रकाशित वस्तुओं के काउंटरों को देखता है।

मैंने अभी इस मूल जानकारी को थोड़ा प्रासंगिक माना है क्योंकि अब तक के उत्तर एक vSphere वर्चुअल मशीन के भीतर से समय आधारित मापों पर ध्यान केंद्रित कर रहे हैं, जहां यह कुछ मामलों में सही विश्लेषण के लिए एक महत्वपूर्ण परिस्थिति है। यह भी निश्चित रूप से इस विशेष (अधूरा) उत्तर और इसकी टिप्पणियों के विषय से संबंधित है। यह किसी के काम आ सकता है।

जैसे ही मुझे समय मिलता है मैं व्हाइटपैप्स आदि के लिंक को संपादित करूंगा जो इस पर विस्तृत है, और सटीक काउंटर पाथ्स / नाम हैं। स्वाभाविक रूप से यह सब googleable भी है।


क्या आप सुझाव दे रहे हैं कि मुझे संदर्भ-स्विचिंग को कम करने की आवश्यकता है? Procmon के माध्यम से रिपोर्ट किए गए आंकड़े ऑनलाइन देखे गए अन्य उदाहरणों की तुलना में बहुत कम थे। लेकिन क्या इसे अतिरिक्त हार्डवेयर / सीपीयू संसाधनों द्वारा काउंटर नहीं किया जा सकता है?
इविहित

मैं सुझाव दे रहा हूं कि आप देखें कि क्या यह आपके मुद्दे के लिए प्रासंगिक हो सकता है। यदि आपने इसे मापा है और यह राशि आपके शोध के अनुसार कम लगती है तो यह स्पष्ट रूप से नहीं है। सिस्टम में जोड़े गए प्रत्येक प्रोसेसर के लिए सहिष्णुता का स्तर रैखिक रूप से बढ़ता है। हालांकि मुझे विश्वास नहीं है कि एक पूर्ण सीमा स्तर है, लेकिन सिद्धांत रूप में इसे प्रति (स्वस्थ) प्रणाली के आधार पर किया जाना चाहिए।
एरिक

यह ब्लॉग पोस्ट वर्चुअलाइजेशन के नजरिए से सिर्फ सादा रोचक था, भले ही प्रासंगिक न हो: professionalvmware.com/2010/11/context-switching-some-resources और जैसा कि इस लिंक किए गए दस्तावेज़ में देखा गया है, वर्चुअलाइज्ड मल्टीकोर संदर्भ स्विचिंग की लागत का अनुमान मुश्किल है : blog.tsunanet.net/2010/11/…
ErikE

0

मैं सुझाव दूंगा कि WSRM (विंडोज सिस्टम रिसोर्स मैनेजर) को लागू किया जाए। जब एक टन ऐप, कनेक्शन, सेवाएं एक होस्ट पर चल रही होती हैं, तो सिस्टम को नहीं पता होता है कि सभी को एक साथ अच्छा खेलना होगा। Windows सर्वर स्वाभाविक रूप से सभी संसाधनों को हर समय पूरा करने के लिए उपयोग करने की कोशिश करता है जब तक कि उसे जागरूक नहीं किया जाता ... WSRM दर्ज करें।

WSRM को लागू करने से आप सभी प्रकार की विविधताओं के द्वारा संसाधन सीमा निर्धारित कर सकते हैं ताकि यह सुनिश्चित हो सके कि सब कुछ चल रहा है या उपयोगकर्ताओं से जुड़ा हुआ है। आपके नोटों से ऐसा नहीं लगता कि यह ESX / vSphere मुद्दा है, बल्कि बहुत से जुड़े हुए उपयोगकर्ता हैं जो लगातार हर चीज के लिए प्रतिस्पर्धा कर रहे हैं। आपको सब कुछ के बीच संतुलन साधने के एक खुशहाल माध्यम को खोजने के लिए WSRM का परीक्षण करना होगा, लेकिन प्रदर्शन के स्तर को भी प्रभावित नहीं करना होगा जो हर किसी के आदी हो गए हैं।

WSRM ओवरव्यू: http://technet.microsoft.com/en-us/library/cc732553.aspx


धन्यवाद। मेरे पास पहले से ही प्रति सत्र प्रोफ़ाइल के साथ WSRM स्थापित है ।
एवहाइट

मुझे यकीन नहीं है कि डब्लूएसआरएम अंतर्निहित समस्या को कम कर सकता है, जो कि मेरी आंत बताती है कि किसी प्रकार की मेमोरी थकावट है (और उसी समस्या पर आधारित है और W2K3 में त्रुटि संदेश कुछ प्रकार की कर्नेल मेमोरी थकावट है)।
जोकेवेटी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.