Vmware वर्कस्टेशन मेरे सभी रैम का उपयोग करता है


4

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

क्या किसी को पता है कि जब मैं एक अतिथि वर्चुअल मशीन चलाता हूं तो अपने सभी रैम का उपयोग करने से वीएमवेयर वर्कस्टेशन को कैसे रोकना है?

मुझे VirtualBox के साथ समस्या नहीं है और मैंने VMware वर्कस्टेशन को फिर से स्थापित करने की कोशिश की है और समस्या बनी रहती है। मैं इसका उपयोग करना बंद कर दूंगा लेकिन कुछ परियोजनाएं हैं जिनके लिए मुझे VMware का उपयोग करने की आवश्यकता है।

यहाँ आगे विवरण हैं:

जब मैं free -mटर्मिनल में दौड़ता हूं जब VMware वर्कस्टेशन खुला होता है, लेकिन कोई गेस्ट रनिंग (VM को फायर करने से पहले):

             total       used       free     shared    buffers     cached
Mem:         15945       3370      12575        198         23        696
-/+ buffers/cache:       2650      13295
Swap:        19072         74      18998

विंडोज 10 अतिथि शुरू करने और कुछ मिनट तक चलने के बाद, अगर मैं free -mअपने मेजबान में दौड़ता हूं तो मुझे यह मिलेगा:

             total       used       free     shared    buffers     cached
Mem:         15945      15694        251       2182         66      12158
-/+ buffers/cache:       3468      12477
Swap:        19072         74      18998

जब मैं विंडोज 10 अतिथि को बंद करता हूं और free -mफिर से चलाता हूं :

             total       used       free     shared    buffers     cached
Mem:         15945      13499       2446        197         67      10209
-/+ buffers/cache:       3223      12722
Swap:        19072         74      18998

अपनी रैम वापस पाने के लिए मुझे दौड़ना होगा: sync && echo 3 | sudo tee /proc/sys/vm/drop_cachesऔर फिर मैं दौड़ता free -mहूँ जो मुझे मिलता है:

             total       used       free     shared    buffers     cached
Mem:         15945       3312      12633        198          2        642
-/+ buffers/cache:       2667      13278
Swap:        19072         74      18998

सिस्टम होस्ट और गेस्ट स्पेक्स

//////////////////////////////////////
System Host:
Ubuntu 14.04LTS
VMware Workstation 12 Pro Version: 12.1.1 build-3770994
///////////////////////////////////////

//////////////////////////////////////
VM Guest:
Windows10
RAM: 1984MB
Processors: 1
DisplayRAM: 1GB
///////////////////////////////////////

//////////////////////////////////////
Motherboard:
ASUS AMD M5 A97 R2.0
///////////////////////////////////////

///////////////////////////////////////
CPU:
AM3+ AMD FX 8320 8-Core 
3.5GHz 16MB Total Cache, (5GHz Max)
///////////////////////////////////////

///////////////////////////////////////
Graphics Card:
ZOTAC Nvidia Geforce GT 730
4GB DDR3 64-bit HDCP
DUAL-Link DVI, HDMI, VGA
///////////////////////////////////////

///////////////////////////////////////
RAM: 16GB
Kingston Hyperx 
2x8GB Memory Sticks 
1866 DDR3 240-pin
///////////////////////////////////////

////////////////////////////////////////
POWER SUPPLY:
EVGA 1000w PS
1000GQ
80+ Gold series
///////////////////////////////////////

अपडेट, 19 सितंबर 16

(ध्यान दें कि यह @granjow द्वारा अतिरिक्त जानकारी है, जो उम्मीद है कि ओपी के अनुभव का प्रतिनिधित्व करता है।)

कुछ स्पष्टीकरण जोड़ने के लिए, समस्या यह नहीं है कि "मुक्त मेमोरी" कॉलम में संख्या छोटी है और हम इस संख्या के बारे में सिर्फ नाखुश हैं क्योंकि बड़ी संख्या में अच्छे हैं। समस्या यह है कि सिस्टम का प्रदर्शन वास्तव में भयानक है।

समस्या स्वयं इस प्रकार प्रकट होती है: VM और कुछ कार्यक्रमों को शुरू करने के बाद, मुफ्त मेमोरी ड्रॉप की मात्रा, जिसकी उम्मीद की जानी है। VMware द्वारा उपयोग की जाने वाली मेमोरी कॉन्फ़िगर की गई सीमा (यानी 4 जीबी के बजाय 10 जीबी, कुल 8 जीबी की भौतिक रैम के साथ) से कहीं अधिक बढ़ जाती है। कुछ बिंदु पर, अतिथि और मेजबान दोनों कई अवसरों पर> 10 एस के लिए ठंड शुरू करते हैं: उदाहरण के लिए वेबस्टॉर्म (अतिथि) में फ़ाइलों में नेविगेट करना, एक नया ब्राउज़र टैब या टर्मिनल टैब खोलना या केवल Alt-Tab (होस्ट) दबाकर।

जब उन अवसरों पर CPU लोड का अवलोकन किया जाता है, तब तक अतिथि CPU उपयोग 100% तक चला जाता है, जब तक कि सिस्टम फ़्रीज नहीं हो जाता है, लेकिन कोई भी कार्य कार्य प्रबंधक में व्यस्त नहीं दिखाई दे रहा है। असल में, मैं रैम से बाहर चल रहे सिस्टम के विशिष्ट लक्षणों का निरीक्षण कर सकता हूं और डिस्क को कैश के रूप में उपयोग कर सकता हूं। वीएमवेयर लॉग का अवलोकन करते समय, अक्सर किकिंग में बैलूनिंग के बारे में एक पंक्ति होती है, जिसे वीएमवेयर का बहुत ही बुद्धिमान तंत्र कहा जाता है जो अतिथि द्वारा मुक्त की गई मेमोरी को प्रबंधित और रिलीज करता है।

हम मेजबान मशीन के खराब चश्मे के बारे में बात नहीं कर रहे हैं, क्योंकि

  • बिल्कुल वही वीएम प्रदर्शन के मुद्दों का सामना किए बिना विंडोज 10 पर बिल्कुल उसी हार्डवेयर पर सुचारू रूप से चल रहा है
  • एक ही वीएम, उबंटू पर वर्चुअलबॉक्स में आयातित, विंडोज 10 पर वीएमवेयर के साथ समान रूप से अच्छी तरह से चलता है, जिसमें htop / glances लगभग 4.6 जीबी की निरंतर मेमोरी उपयोग दिखा रहा है, और बिल्कुल भी जमा नहीं होता है।

3
जब तक मैं कुछ याद नहीं कर रहा हूँ, ऐसा लगता है कि मेमोरी केवल कैश के लिए उपयोग की जाती है? बिल्कुल ऐसा ही होना चाहिए! मुक्त स्मृति व्यर्थ स्मृति है।
डैनियल बी

1
सिस्टम और वीएम के लिए आप किस प्रकार की भौतिक मेमोरी का उपयोग कर रहे हैं? यह क्या हो रहा है इसके आधार पर, आपका I / O प्रदर्शन सिर्फ अपर्याप्त हो सकता है, खासकर यदि आप अभी भी एक अतिथि ऑपरेटिंग सिस्टम स्थापित करने में व्यस्त हैं। अगर वास्तव में अतिथि स्थापित है और सिर्फ बेकार है तो एक मुद्दे के रूप में नहीं होना चाहिए।
सेठ

1
@ साइमनए.इगस्टर मुझे नहीं पता। शायद सीपीयू बहुत व्यस्त है, हो सकता है कि निश्चित ड्राइव (यांत्रिक?) बहुत व्यस्त हो।
डैनियल बी

1
भौतिक स्मृति से मतलब है जैसे आप HDD / SSD से भाग रहे हैं। यदि आप अभी भी व्यस्त या कुछ और काम में व्यस्त हैं तो आपको अपने वीएम में हकलाने की सूचना नहीं है। यही कारण है कि मैंने पूछा कि जब भी विंडोज़ मशीन बेकार या व्यस्त थी। यह पूरी बैंडविड्थ का उपयोग करने में व्यस्त हो सकता है HDD को कुछ फ़ाइलों या समान को अनपैक करने के लिए प्रस्ताव देना होगा। यदि यह निष्क्रिय है और ऐसा होता है तो शायद वर्कस्टेशन के पुराने निर्माण की कोशिश करें या VMWare से संपर्क करने पर विचार करें?
सेठ

1
आप बाद में RAM को सहेज नहीं सकते। अपने RAM का उपयोग करना अच्छा है क्योंकि केवल एक चीज जिसे आप उपयोग करने के अलावा अन्य कर सकते हैं वह है इसे बर्बाद करना। यदि आपके पास कोई प्रदर्शन समस्या है, तो हमें उसके बारे में बताएं, जितना आप कर सकते हैं। (। जब यह होता है क्या बनाता है यह दूर इतने पर जाना विशेष रूप से क्या धीमी है और?।)
डेविड Schwartz

जवाबों:


1

आप कुछ नहीं पर चिंता कर रहे हैं। अप्रयुक्त राम बर्बाद राम है। इस तरह के रूप में आपका सिस्टम समझदारी से कैश के लिए बचे हुए राम का उपयोग करेगा , आवश्यकतानुसार चीजों को गति देगा।

शीर्ष एक अच्छा उपकरण - यह आपको कुछ उपयोगी जानकारी देता है, लेकिन एक अधिक समग्र दृष्टिकोण की आवश्यकता हो सकती है - iotop या इसी तरह के उपकरण यह दिखा सकते हैं। मेरा संदेह यह है कि इसका भंडारण धीमा है, और वर्चुअलबॉक्स और वीएमवेयर आईओ और राम उपयोग को अलग तरह से संभालते हैं। एक 'फिक्स' ssd और / या VM का उपयोग करने के लिए मुख्य सिस्टम की तुलना में अलग स्टोरेज को चलाने के लिए हो सकता है अगर वह मदद करता है। मैं अपने सिस्टम को एक SSD और मेरे VMs को एक बड़ी, 7200 आरपीएम डिस्क से चलाता हूं, हालांकि मैंने इसके लिए एक एसएसडी प्राप्त किया है।


धन्यवाद; मैंने IO को iotop / glances के साथ देखने की कोशिश की, हालांकि यह तब भी जमा देता है जब सिस्टम जमा देता है, इसलिए मुझे अब तक कुछ भी नहीं मिला। भंडारण के बारे में, मैंने ओपी के प्रश्न में अधिक विवरण जोड़ दिए हैं, सिस्टम वास्तव में एक एसएसडी का उपयोग कर रहा है (जो बहुत अच्छा है क्योंकि आप निलंबित कर सकते हैं और फिर से शुरू कर सकते हैं जैसे कि कुछ कार्यालय प्रोग्राम खुले और बंद होते हैं: -] (लेकिन शायद एक एसएसडी पर विचार करें जो कई आर / डब्ल्यू संचालन के लिए बनाया गया है, ट्रिपल कोशिकाओं (टीएलसी) के साथ सस्ता एसएसडी शायद अधिक खतरनाक हैं।
साइमन ए। यूगस्टर

1

किसी भी बिंदु पर आपका सिस्टम वास्तव में मेमोरी के बाहर कहीं भी नहीं चलता है। कोई कार्रवाई की आवश्यकता नहीं है।

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

कैश्ड डेटा को अनदेखा करते हुए उपयोग में आने वाली भौतिक मेमोरी की वास्तविक मात्रा और अनुप्रयोगों के लिए उपलब्ध, को -/+ buffers/cacheपंक्ति में सूचीबद्ध किया गया है । आपके सिस्टम में VM को चलाने के दौरान लगभग 12 GB प्रयोग करने योग्य मेमोरी शेष थी, लेकिन इसका अधिकांश उपयोग कैश्ड डेटा के लिए किया गया था। यह व्यवहार सामान्य है, और आपको इस बारे में कुछ भी करने की आवश्यकता नहीं है। वास्तव में, कैश को मैन्युअल रूप से फ्लश करना (के साथ sync && echo 3 | sudo tee /proc/sys/vm/drop_caches) सिस्टम के प्रदर्शन को नीचा दिखाएगा क्योंकि सिस्टम को रैम में कॉपी को पुनः प्राप्त करने के बजाय डेटा को पढ़ने के लिए डिस्क तक पहुंच की आवश्यकता होगी।

आपका धीमा सिस्टम प्रदर्शन उच्च डिस्क लोड के कारण होने की संभावना है जब वीएम चल रहा है। यदि आप एक यांत्रिक हार्ड ड्राइव का उपयोग कर रहे हैं, तो SSD के उन्नयन पर विचार करें।

लिनक्स डेटा को मुफ्त मेमोरी में कैसे उपयोग करता है, इस बारे में अधिक जानकारी "लिनक्स ने मेरी रैम खा ली!"


यह (और जर्नीमैन गीक के) जवाब क्यों दिया गया था?
bwDraco

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

1

ओएस और विभिन्न विन्यासों की कई पुन: स्थापना के बाद, मैंने जो पोस्ट किया था वह मेरे मदरबोर्ड, रैम या सीपीयू तक सीमित था।

मैंने उसी धीमे ड्राइव (रास्ते में एक SSD) को एक और धीमे सिस्टम (6 वीं जीन इंटेल i5, 2.3GHz / 2.8GHz प्रोसेसर) में इस्तेमाल किया, एक ही OS के साथ, और एक ही मात्रा में RAM लेकिन अलग-अलग स्टिक और अनुभव नहीं किया अब और समस्या। उपयोगकर्ता जो इस 2 महीने पुरानी पोस्ट पर इतना ध्यान लाने के लिए इनाम पोस्ट करता है, वह अपने हार्डवेयर पर कुछ अच्छी तरह से परीक्षण चलाना चाह सकता है।


यह दिलचस्प है। तो उबंटू + वीएमवेयर को फिर से स्थापित करने के बाद, आप समस्या को पुन: उत्पन्न कर सकते हैं, लेकिन तब नहीं जब आप एक अलग मेनबोर्ड में बदलते हैं?
बजे साइमन ए। यूजस्टर

1
यह सही है, मैं ubuntu (दोस्त और kde जायके) और vmware के कई पुन: स्थापित करने के साथ इस मुद्दे को पुन: पेश करने में सक्षम था। जब मैंने दूसरे मदरबोर्ड पर स्विच किया, तो मुझे उम्मीद थी कि यह मुद्दा बना रहेगा क्योंकि मुझे लगा कि लिनक्स होस्ट पर vmware की समस्या होनी चाहिए। मेरे आश्चर्य के लिए सभी समस्याएं दूर हो गईं और जो एकमात्र चर बदले गए वे एक अलग मदरबोर्ड, रैम और सीपीयू थे। ओडली पर्याप्त रूप से, पुराना हार्डवेयर वर्तमान में बिना किसी समस्या के kvm / qemu हाइपरवाइजर के साथ एक CentOS7 नास का समर्थन कर रहा है।
jtlindsey

शायद यह हार्डवेयर और इस मेजबान प्रणाली के साथ एक VMware समस्या है? मेरा समाधान अब VMware के बजाय VirtualBox का उपयोग करना है।
साइमन ए। युगस्टर

0

यह समस्या मेरी मशीन (32GB RAM) पर भी होती है। VMWare सभी रैम को भरता है और थोड़े समय के बाद सिस्टम नाटकीय रूप से धीमा हो जाता है।

VMWare "कैश रैम" को भरता है - यह अप्रयुक्त रैम है जो इसे कैश के रूप में उपयोग करता है। जैसा कि bwDraco लिखते हैं, सैद्धांतिक रूप से इसके लिए किसी कार्रवाई की आवश्यकता नहीं होनी चाहिए।

दुर्भाग्य से यह व्यवहार में सच नहीं है। यह समस्या VMWare 10 से शुरू हुई, पहले के संस्करणों में यह समस्या नहीं थी।

इसके साथ जांच की जा सकती है htop। "मेम" के लिए पीले रंग की पट्टी देखें। यदि यह येलो बार (कैश रैम का उपयोग) सही पर है, तो कैश भरा हुआ है और मशीन धीमा हो जाती है।

मैं इस समस्या का कारण नहीं जानता, लेकिन मेरे पास एक समाधान है जो अच्छी तरह से काम करता है:

क्रोन जॉब का उपयोग करके मैं हर तीन मिनट में इस कमांड को निष्पादित करता हूं:

sh  -c  "sync; echo 3 > /proc/sys/vm/drop_chaces"

यह VMWare कैश को साफ करता है और मशीन बिना किसी प्रदर्शन के मुद्दों के साथ आसानी से चलती है।

एक संभावित व्याख्या यह हो सकती है कि VMWare सभी कैश रैम खाती है और लिनक्स कर्नेल के लिए अधिक कैश नहीं है। VMWare इस मेमोरी को कभी जारी नहीं करता है लेकिन लिनक्स को तेजी से काम करने के लिए कुछ कैश की भी आवश्यकता होती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.