X86 / x64 वर्चुअलाइजेशन में कितना ओवरहेड है?

Question

ओवरहेड कितना x86 / x64 वर्चुअलाइजेशन करता है (मैं शायद वर्चुअलबॉक्स का उपयोग कर रहा हूं, VMWare, निश्चित रूप से paravirtualization नहीं होगा) प्रत्येक ऑपरेशन के लिए इंटेल हार्डवेयर वर्चुअलाइजेशन का उपयोग करके एक Win64 होस्ट और Linux64 अतिथि है?

• विशुद्ध रूप से सीपीयू-बाउंड, उपयोगकर्ता मोड 64-बिट कोड

• विशुद्ध रूप से सीपीयू-बाउंड, उपयोगकर्ता मोड 32-बिट कोड

• हार्ड ड्राइव में फ़ाइल I / O (मैं ज्यादातर थ्रूपुट के बारे में परवाह करता हूं, विलंबता नहीं)

• नेटवर्क I / O

• थ्रेड सिंक्रोनाइज़ेशन प्राइमेटिव्स (म्यूटेक्स, सेमाफोर्स, कंडीशन वैरिएबल)

• थ्रेड संदर्भ स्विच

• परमाणु संचालन ( lockउपसर्ग का उपयोग करते हुए , तुलना-और-स्वैप जैसी चीजें)

मैं मुख्य रूप से हार्डवेयर असिस्टेड x64 केस (इंटेल और एएमडी दोनों) में दिलचस्पी रखता हूं, लेकिन बिना बाइनरी ट्रांसलेशन और x86 (यानी 32-बिट होस्ट और गेस्ट) के मामलों के बारे में सुनने में बुरा नहीं लगेगा। मुझे पैरावर्चुअलाइजेशन में कोई दिलचस्पी नहीं है।

Comments

(1) "x86" का अर्थ है 32-बिट। आप 64-बिट कोड नहीं चला पाएंगे। AMD64 (जिसे x64 के रूप में भी जाना जाता है) वर्चुअलाइजेशन की अलग-अलग सीमाएँ हैं क्योंकि इसके लिए हार्डवेयर एक्सटेंशन की आवश्यकता होती है। (2) क्या आपका मतलब है x86 वर्चुअलाइजेशन बाइनरी ट्रांसलेशन (केवल x86) या हार्डवेयर असिस्टेड वर्चुअलाइजेशन (VT)?

— स्काईवॉक

@ मीलों: मैंने सवाल स्पष्ट किया है।

— dsimcha

Answer 1

मैंने पाया कि आपके जैसे प्रश्नों का सरल और पूर्ण उत्तर नहीं है। प्रत्येक वर्चुअलाइजेशन समाधान विशिष्ट प्रदर्शन परीक्षणों पर अलग ढंग से व्यवहार करता है। इसके अलावा, डिस्क I / O थ्रूपुट जैसे परीक्षणों को कई अलग-अलग परीक्षणों (पढ़ें, लिखना, फिर से लिखना, ...) में विभाजित किया जा सकता है और परिणाम समाधान से समाधान तक, और परिदृश्य से परिदृश्य में भिन्न होंगे। यही कारण है कि डिस्क I / O के लिए सबसे तेज़ होने के रूप में एक समाधान को इंगित करना तुच्छ नहीं है, और यही कारण है कि डिस्क I / O के लिए ओवरहेड जैसे लेबल के लिए कोई पूर्ण उत्तर नहीं है।

विभिन्न बेंचमार्क परीक्षणों के बीच संबंध खोजने की कोशिश करने पर यह अधिक जटिल हो जाता है। मैंने जिन समाधानों का परीक्षण किया है उनमें से किसी का भी सूक्ष्म-संचालन परीक्षणों में अच्छा प्रदर्शन नहीं था। उदाहरण के लिए: वीएम के अंदर "गेटटाइमऑफडे ()" के लिए एक सिंगल कॉल, औसतन, हार्डवेयर की तुलना में 11.5 गुना अधिक घड़ी चक्र पूरा करने के लिए। हाइपरवाइज़र वास्तविक दुनिया के अनुप्रयोगों के लिए अनुकूलित होते हैं और माइक्रो-ऑपरेशन पर अच्छा प्रदर्शन नहीं करते हैं। यह आपके एप्लिकेशन के लिए एक समस्या नहीं हो सकती है जो वास्तविक विश्व एप्लिकेशन के रूप में बेहतर फिट हो सकती है। मेरा मतलब है कि माइक्रो-ऑपरेशन किसी भी एप्लिकेशन को समाप्त करने के लिए 1,000 से अधिक घड़ी चक्र खर्च करता है (एक 2.6 गीगाहर्ट्ज सीपीयू के लिए, 1,000 घड़ी चक्र 385 नैनोसेकंड, या 3.85e-7 सेकंड में खर्च किए जाते हैं)।

मैंने x86 अभिलेखागार के लिए डेटा सेंटर समेकन के चार मुख्य समाधानों पर व्यापक बेंचमार्क परीक्षण किया। मैंने हार्डवेयर प्रदर्शन के साथ वीएम के अंदर प्रदर्शन की तुलना करते हुए लगभग 3000 परीक्षण किए। मैंने 'ओवरहेड' को हार्डवेयर पर मापा अधिकतम प्रदर्शन के साथ वीएम (एस) के अंदर मापा जाने वाले अधिकतम प्रदर्शन का अंतर कहा है।

समाधान:

• VMWare ESXi 5
• Microsoft हाइपर- V विंडोज 2008 R2 SP1
• Citrix XenServer 6
• Red Hat Enterprise वर्चुअलाइजेशन 2.2

अतिथि OS:

• Microsoft Windows 2008 R2 64 बिट्स
• Red Hat Enterprise Linux 6.1 64 बिट्स

परीक्षण की जानकारी:

• सर्वर: 8GB रैम, 2X Intel Xeon E5440 सीपीयू, और चार गीगाबिट ईथरनेट पोर्ट के साथ 2X सन फायर X4150
• डिस्क: 6X 136GB SAS डिस्क पर गीगाबिट ईथरनेट पर iSCSI है

बेंचमार्क सॉफ्टवेयर:

• सीपीयू और मेमोरी: 32 और 64 बिट्स दोनों के लिए लिनपैक बेंचमार्क । यह सीपीयू और मेमोरी इंटेंसिव है।

• डिस्क I / O और लेटेंसी: बोनी ++

• नेटवर्क I / O: Netperf: TCP_STREAM, TCP_RR, TCP_CRR, UDP_RR और UDP_STREAM

• माइक्रो-ऑपरेशन: rdtscbench : सिस्टम कॉल, इंटर प्रोसेस पाइप संचार

औसत की गणना मापदंडों के साथ की जाती है:

• CPU और मेमोरी: AVERAGE (HPL32, HPL64)

• डिस्क I / O: AVERAGE (put_block, rewrite, get_block)

• नेटवर्क I / O: AVERAGE (tcp_crr, tcp_rr, tcp_stream, udp_rr, udp_stream)

• माइक्रो-ऑपरेशन AVERAGE (getpid (), sysconf (), gettimeofday (), malloc [1M], malloc [1G], 2pipes [], simplemath []

मेरे परीक्षण परिदृश्य के लिए, मेरे मैट्रिक्स का उपयोग करते हुए, चार वर्चुअलाइजेशन समाधानों के परिणामों के औसत हैं:

VM परत उपरि, लिनक्स अतिथि:

• सीपीयू और मेमोरी: 14.36%

• नेटवर्क I / O: 24.46%

• डिस्क I / O: 8.84%

• पढ़ने के लिए डिस्क विलंबता: 2.41 गुना धीमी

• माइक्रो-संचालन निष्पादन समय: 10.84 गुना धीमा

VM परत उपरि, Windows अतिथि:

• 32 और 64 बिट्स के लिए CPU और मेमोरी औसत: 13.06%

• नेटवर्क I / O: 35.27%

• डिस्क I / O: 15.20%

कृपया ध्यान दें कि वे मूल्य सामान्य हैं, और विशिष्ट मामलों के परिदृश्य को प्रतिबिंबित नहीं करते हैं।

कृपया पूरा लेख देखें: http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solutions

Comments

यह लेख पुराना है

— dyasny

For a 2.6 GHz CPU, 1,000 clock cycles are spent in 23 milliseconds, कि 1,000 घड़ी चक्र लेने की संख्या पाने के लिए 2,600,000 से 1,000 का एक साधारण विभाजन नहीं होना चाहिए? (जो 23 मिलीसेकंड नहीं है)

— डीवीडीवेरल

@श्री। खुश हैं, आप सही हैं। मुझे 385 नैनोसेकंड मिला: 1000/2600000000 = 0.000000385 = 385 नैनोसेकंड। क्या आप इस बात से सहमत हैं? इस पर ध्यान दिलाने के लिए धन्यवाद।

— पीटर सेना

@dyasny, मैं अद्यतित संस्करणों के साथ परीक्षणों को दोहराने के लिए हार्डवेयर की तलाश कर रहा हूं। कोई भी विचार मुझे कहां मिल सकता है?

— पीटर सेना

हार्डवेयर आसानी से एक दुकान में पाया जा सकता है

— dyasny

Answer 2

आपके प्रश्न में बहुत अधिक चर हैं, हालांकि मैं इसे कम करने की कोशिश कर सकता हूं। मान लें कि आप VMware ESX के साथ जाते हैं, तो आप सब कुछ सही करते हैं - वर्चुअलाइजेशन के लिए नवीनतम सीपीयू, पैरावर्टाइज्ड स्टोरेज और नेटवर्क ड्राइवरों के साथ वीएमवेयर टूल्स, भरपूर मेमोरी। अब मान लेते हैं कि आप इस सेटअप पर एक ही वर्चुअल मशीन चलाते हैं। मेरे अनुभव से, आपके पास सीपीयू बाउंड वर्कलोड के लिए ~ 90% सीपीयू की गति होनी चाहिए। मैं आपको नेटवर्क स्पीड के बारे में ज्यादा नहीं बता सकता, क्योंकि हम 1 जीबीपीएस लिंक का उपयोग कर रहे हैं और मैं इसे बिना किसी समस्या के संतृप्त कर सकता हूं, यह 10 जीबीपीएस लिंक के साथ अलग हो सकता है, हालांकि हमारे पास उनमें से कोई भी नहीं है। भंडारण थ्रूपुट भंडारण के प्रकार पर निर्भर करता है, मैं स्थानीय भंडारण के साथ लगभग 80% संग्रहण थ्रूपुट प्राप्त कर सकता हूं, लेकिन 1 जीबीपीएस एनएफएस के लिए यह 100% के करीब है क्योंकि नेटवर्किंग यहां अड़चन है। अन्य मैट्रिक्स के बारे में नहीं बता सकते,

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

इसके अलावा मेरे अनुभव से उच्च प्रदर्शन अनुप्रयोगों के लिए बहुत बड़ी समस्या विलंबता है और यह क्लाइंट सर्वर अनुप्रयोगों के लिए विशेष रूप से सच है। हमारे पास एक संगणना इंजन है जो 30+ ग्राहकों से अनुरोध प्राप्त करता है, कम संगणना करता है और परिणाम देता है। नंगे धातु पर यह आमतौर पर सीपीयू को 100% तक धकेलता है लेकिन VMware पर एक ही सर्वर केवल CPU को 60-80% तक लोड कर सकता है और यह मुख्य रूप से अनुरोधों / उत्तरों को संभालने में विलंबता के कारण है।

Comments

मैं अनुभव से बोल सकता हूं कि एक एकल वीएम के साथ 10GbE लिंक को संतृप्त करना बहुत मुश्किल है। हमने VMWare FT का उपयोग किया है, जो 10Gbe से अधिक के अपने दम पर 1Gbps लिंक को आसान बना सकता है और इसे संतृप्त करने के करीब नहीं आया।

— मार्क हेंडरसन

Answer 3

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

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

Comments

यह बहुत अच्छा है कि आपने Xen और KVM के लिए कुछ जानकारी प्राप्त की है ... लेकिन सबसे लोकप्रिय दो हाइपरवेर्स के बारे में क्या है ?! वे पूरी तरह से गायब हैं। और आप कई प्रकार के 2 हाइपरविजर को शामिल कर चुके हैं, कोई भी सेन SysAdmin उत्पादन के लिए उपयोग नहीं करेगा।

— क्रिस एस

नीचे मतदान हुआ। लिंक मर चुका है।

— टिम डंकली