ভার্চুয়ালবক্স: শারীরিক সিপিইউ সংখ্যার চেয়ে বেশি ভার্চুয়াল সিপিইউ করাকে দেওয়া কি খারাপ ধারণা?


41

আমার যেমন হাইপার-থ্রেডিং সক্ষম সিপিইউ রয়েছে তাই আমি আশ্চর্য হয়েছি, নিম্নলিখিত সতর্কতার সূত্র ধরে যেমন শারীরিক সিপিইউ কোরের সংখ্যার চেয়ে বেশি ভার্চুয়াল সিপিইউ কোর সরবরাহ করা কি খারাপ ধারণা?

ভার্চুয়ালবক্স সতর্কতা

প্রতিলিপি:

হোস্ট সিস্টেমের ফিজিক্যাল সিপিইউগুলির সংখ্যার চেয়ে ভার্চুয়াল মেশিনে আরও ভার্চুয়াল সিপিইউ বরাদ্দ করা হয়। এটি আপনার ভার্চুয়াল মেশিনের কার্যকারিতা হ্রাস করতে পারে। অনুগ্রহ করে ভার্চুয়াল সিপিইউগুলির সংখ্যা হ্রাস করার বিষয়টি বিবেচনা করুন।

এই বিষয়টিতে কেউ যুক্তি রাখতে পারেন?

EDIT1:

প্রশ্নে থাকা সিপিইউ হ'ল ইনটেল কোর আই 7-4700 এইচকিউ, আরক ইন্টেল , সিপিইউ বেঞ্চমার্ক

EDIT2:

ধরা যাক, এইচডিডি (কোনও এসএসডি পরিবর্তে), এবং / বা লো র‌্যামের মতো (এখানে 16 vm.swappinessজিবি , সর্বনিম্ন , এই ভিএম এর জন্য 4 গিগাবাইট) মতো কোনও অপ্রচলিত এইচডাব্লু নেই and


2
সতর্কতাটি যথাযথভাবে সঠিক, এবং রিয়েল-টাইম পারফরম্যান্স গুরুত্বহীন না হলে বা ভার্চুয়াল মেশিনে কেবলমাত্র একটি ন্যূনতম (সফ্টওয়্যার) বোঝা চাপানো এড়াতে হবে না। সুতরাং
agc

যেমন ওয়ারিং বলে। ভিএম-তে কম সিপিইউ সহ জিনিসগুলি আসলে দ্রুততর হতে পারে।
রুই এফ রিবেইরো

আপনার কখনই লাল লাইনে যাওয়া উচিত নয়। 4 টি প্রকৃত এইচটি-সক্ষম সক্ষম কোর সিপিইউতে 4 "কোর" ব্যবহার করা ঠিক আছে। র‌্যামের জন্য, আপনার র‌্যামের 50% কাজটি করা উচিত, এমনকি যদি সবুজ অংশ এর বাইরে থাকে।
সিলগ্যাল্যাড

ভার্চুয়ালবক্সে, "কোর" সমস্ত থ্রেড, সুতরাং আপনার যদি 4 টি কোর এবং হাইপারথ্রেডিং সহ সিপিইউ থাকে তবে এটি 8 টি "কোর" এর মতো, তাই আপনি যদি একা চালনা করেন তবে আপনি বাস্তবে একটি ভিএমতে 4 টি ভার্চুয়াল কোর সেট আপ করতে পারেন; আমি সব সময় এটিই করি এবং এটি দুর্দান্ত কাজ করে।
সেপ্টেম্বর

আমার কী প্রমাণ করতে হবে? লাল রেখাটি আমার জন্য 4 "কোর" এর বেশি, আমি কখনই এর বাইরে যাই না এবং একই সাথে আমি কখনই 2 ভিএম চালাতে পারি না। আপনি যদি ভিএমকে সমস্ত সিপিইউ দিয়ে আপনার পিসি ক্রাশ করার ঝুঁকি পছন্দ করেন এবং আপনি ভিএম এর বাইরে কিছু না করেন তবে ঠিক আছে।
সিলগাল্যাড

উত্তর:


30

হার্ডওয়্যার / ওএস / সফটওয়্যার

হোস্ট : লিনাক্স মিন্ট 18 দারুচিনি 64-বিট (সম্পূর্ণ আপডেট); কার্নেল সংস্করণ 4.4.0-47-জেনেরিক

অতিথি : উইন্ডোজ 8.1 প্রো 64-বিট (সম্পূর্ণ আপডেট)

প্রসেসর : ইন্টেল কোর i7-4700HQ , (6 এমবি ক্যাশে, 4 শারীরিক কোর বা 8 হাইপার-থ্রেডিং ব্যবহার করে), সিপিইউ বেঞ্চমার্ক

ভার্চুয়ালবক্স : সংস্করণ 5.1.10 r112026 (Qt5.5.1)

অতিথি সংযোজন : ইনস্টল এবং আপ টু ডেট

বেঞ্চমার্ক সরঞ্জাম # 1 : WinRAR সংস্করণ 5.40 চূড়ান্ত 64-বিট bit

বেঞ্চমার্ক সরঞ্জাম # 2 : ভেরাক্রিপ্ট সংস্করণ 1.19 চূড়ান্ত 64৪-বিট


প্রস্তুতি

উভয় ক্ষেত্রেই আমি সিপিইউ, র‌্যাম, ডিস্ক ড্রাইভ স্থির স্থানে শূন্য-পয়েন্ট হিটের আগ পর্যন্ত বুটের পরে অপেক্ষা করছিলাম।


পদ্ধতি

  1. আসল ভার্চুয়াল মেশিনটিকে দুটি একই ধরণের জন্য ক্লোনিং করা হচ্ছে।
  2. আমার কাছে দ্বিতীয় পাসের জন্য, যেহেতু রিবুট অক্ষম অ্যান্টিভাইরাস এই উত্তরটির নীচে চিহ্নিত করেছে এবং একটি বিটা থেকে চূড়ান্ত সংস্করণে উইনআরআর আপডেট করেছে updated
  3. আমি আগে যেমন নির্দেশিত করেছি তেমন প্রস্তুতিও করেছি।
  4. ভার্চুয়াল মেশিনটি অগ্রভাগে চলেছিল, অন্য কোনও সিপিইউয়ের ক্ষুধার্ত অ্যাপ্লিকেশন চলমান ছাড়াই, পরীক্ষার প্রভাব না পড়ার উদ্দেশ্যে আমি যা করতে পারি তা অক্ষম করে রেখেছি।
  5. সিস্টেমের ভিতরে বা বাইরে সম্ভাব্য ক্যাচিং অন্তর্ভুক্ত করতে, ফলস্বরূপ আমি একই পরীক্ষায় দু'বার দৌড়েছি। সুবিধা প্রায় কেউই হচ্ছে না।

ফলাফল

WinRAR

  1. 4 কোর => 7.5 মিনিট ( সংক্ষিপ্ত সময় ভাল)

    4 কোরের সাথে উইনআরআর সক্ষম হয়েছে

    4 টি কোর সহ উইনআরআর সক্ষম হয়েছে, 1.5 গিগাবাইট 7.5 মিনিটে প্রক্রিয়া করা হয়েছে ।

  2. 8 টি কোর => 4.5 মিনিট ( স্বল্প সময়ের চেয়ে ভাল)

    8 কোরের সাথে উইনআরআর সক্ষম হয়েছে

    WinRAR দিয়ে 8 কোর সক্ষম করা থাকে, 1.5GiB প্রক্রিয়াকৃত 4.5 মিনিট।


VeraCrypt

  1. 4 কোর => গতি 2.6 GiB / s ( উচ্চতর গতি ভাল)

    4 টি কোর সক্ষম সহ ভেরাক্রিপ্ট

    4 টি কোর সক্ষম, ভেরিক্রিপ্ট এইচডাব্লু- এক্সেল্রেটেড এইএস (এইএস-এনআই) গতি 2.6 জিবি / এস।

  2. 8 টি কোর => গতি 3.9 জিআইবি / গুলি ( উচ্চতর গতি আরও ভাল)

    8 টি কোর সক্ষম সহ ভেরাক্রিপ্ট

    8 টি কোর সক্ষম, ভেরিক্রিপ্ট এইচডাব্লু- এক্সেল্রেটেড এইএস (এইএস-এনআই) গতি 3.9 জিআইবি / এস।


উপসংহার

আমি প্রয়োজন হিসাবে অনেক পরীক্ষা চালাতে পারে। তবে আমি অনুমান করি যে এই দুটি, যার মধ্যে একটি বরং জটিল সংক্ষেপণ পরীক্ষা, দ্বিতীয়টি বরং জটিল এনক্রিপশন পরীক্ষার একটি সেট, বিন্দুটি কী হবে।

উভয় মানদণ্ডই একটি স্পষ্ট পার্থক্য দেখায়। আমি বিশ্বাস করার কোনও কারণ দেখতে পাচ্ছি না, যে তাদের ফলাফলগুলি সঠিক নয়, আমি যেমন একটি কঠোর প্রস্তুতি এবং পদ্ধতি অনুসরণ করেছি, তদুপরি, এই পরীক্ষাগুলি র‌্যামে I / O বাধা ছাড়ার জন্য ঘটেছে। আমার দৃষ্টিকোণ থেকে, প্রশ্নে উল্লিখিত সতর্কতাটি কিছু শর্তে প্রযোজ্য হতে পারে, তবে অবশ্যই সেগুলি সমস্ত নয়। এই চমত্কার উল্লেখযোগ্য ফলাফলগুলি আপনার সাথে ভাগ করে নেওয়ার পরে, আমি আপনার সাথে আমার একমত হওয়ার জন্য নিশ্চিত যে এই সতর্কতাটি সম্ভবত আধুনিক ভার্চুয়ালবক্স সংস্করণের সাথে হাইপার-থ্রেডিং বৈশিষ্ট্যযুক্ত আধুনিক সিপিইউগুলিতে খুব গুরুত্বের সাথে নেওয়া উচিত নয় । নিশ্চিত করার জন্য একটি জিনিস: আপনি স্থায়ীভাবে এই সেটিংটি প্রয়োগ করার সিদ্ধান্ত নেওয়ার আগে, আমাকে শব্দের জন্য গ্রহণ করবেন না এবং নিজের অবস্থার অধীনে এটি পরীক্ষা করবেন না।


আপনি কি এটিকে একই ভিএম-তে চালানো হয়েছে কোরগুলি পরিবর্তিত করে, বা দুটি পৃথক (তবে অভিন্ন) ভিএম? যদি একই ভিএম, অতিথি ওএস ক্যাশিং অ্যালগরিদমগুলির সম্ভাব্য প্রভাবটি বাতিল করার জন্য আপনি কি পরে অন্য ক্রমে আবার চেষ্টা করেছিলেন?
ওয়াইল্ডকার্ড

মজা করার জন্য একটি আসল সিপিইউ বার্ন পরীক্ষা চালানোর চেষ্টা করুন।
সিলগ্যাল্যাড

অন্তত এক ঘন্টার জন্য প্রাইম 95 এর মতো কিছু। এবং একই সাথে হোস্টে ওয়েব ব্রাউজ করার চেষ্টা করুন। আমি যেমন বলেছি, ঠিক আছে যদি আপনি হোস্টটিতে কিছু না করেন বা একসাথে একাধিক ভিএম না চালান। এটি যদি খারাপ হয় তবে সীমাটি ভার্চুয়ালবক্সে একটি সতর্কতার পরিবর্তে প্রয়োগ করা হত।
সিলগ্যাল্যাড

আর একটি জিনিস আপনি চেষ্টা করতে পারেন তবে এটি আরও কঠিন হতে পারে। স্ক্র্যাচ ভিএম থেকে একটি ভদ্রলোক বা লিনাক্স ইনস্টল করুন এবং যখন এটি নিবিড়ভাবে সংকলন করা হয় তখন জিনিসগুলি কীভাবে চলে তা পরীক্ষা করে দেখুন। অথবা কোনও ভিএম-এ ক্রোমিয়াম তৈরির চেষ্টা করুন।
সিলগ্যাল্যাড

@ ভ্লাস্টিমিল সম্পূর্ণরূপে একমত আমার ক্ষেত্রে আমি সি ++ সংকলনের জন্য ভিএম ব্যবহার করি (যা একটি সিপিইউ বাউন্ডড টাস্ক) এবং আমি 16-কোর সিপিইউ পাওয়ার একমাত্র কারণটি ছিল দ্রুত সংকলন করতে সক্ষম হওয়া। সেই সতর্কবাণীটি যথাযথ ব্যাখ্যা ছাড়াই সম্পূর্ণ বোকামি এবং এই ভুল সিদ্ধান্তের দিকে নিয়ে যায় যেমন "ভিএম-তে কম সিপিইউ দিয়ে জিনিসগুলি সম্ভবত দ্রুততর হতে পারে"
পাভেল পি

16

একজন ওএস ডিজাইনার হিসাবে আমি পরিমাপের ফলাফলের সাথে সম্পূর্ণ সম্মত। বিষয়টি নিয়ে অন্য কোথাও বুলশিটের পরিমাণ উত্পাদন করা অবিশ্বাস্য।

এইচডাব্লু দ্বারা সম্পাদন করা যেতে পারে এমন সমান্তরাল থ্রেড / প্রক্রিয়া সংখ্যা হিসাবে লজিকাল কোরের সংখ্যাটি দেখুন। এটি সদৃশ একটি সিপিইউ কোর এর রেজিস্টার এবং নির্দেশ পয়েন্টার সদৃশ দ্বারা অর্জন করা হয়। সিপিইউ কোর নিজেই সিদ্ধান্ত নিয়েছে যে কোন থ্রেড (নির্দেশ নির্দেশিকা) ব্যবহার করা উচিত। এটি অন্যান্য থ্রেডটি ব্যবহার করার সিদ্ধান্ত নেবে কারণ বর্তমান থ্রেডের নির্দেশাবলী ক্যাশে পাওয়া যায় না এবং উদাহরণস্বরূপ মেমরি বা এল 3 ক্যাশে থেকে এনে নেওয়া দরকার। এই প্রক্রিয়াটি নির্দেশাবলী / সেকেন্ডে বা সিপিইউ কার্য সম্পাদনে 10% -30% সম্ভাব্য উন্নতি তৈরি করবে।

আপনি যদি একটি থ্রেড দিয়ে একটি একক অ্যাপ্লিকেশন চালান, আপনি এই সুবিধাটি কাটাতে সক্ষম হবেন না, তবে আপনি যদি উদাহরণস্বরূপ কোনও পুরানো এইচটি পেন্টিয়ামের উপর দুটি উচ্চ লোড অ্যাপ্লিকেশন চালনা করেন তবে আপনি সেই সুবিধাটি কাটাতে সক্ষম হবেন। অবশ্যই একই অ্যাপ্লিকেশনগুলির ক্ষেত্রে সত্য, এর পরে আরও একটি থ্রেড রয়েছে। আমার লিনাক্স সিস্টেমে 200 টি থ্রেড রয়েছে, তাই প্রকৃত লোডের উপর নির্ভরশীল কিছু সুবিধা সর্বদা উপস্থিত থাকে। এই সমস্ত মন্তব্য ভার্চুয়ালাইজেশন ছাড়াই প্রযোজ্য।

ভার্চুয়ালবক্স কেবল প্রতিটি ভার্চুয়াল মেশিনের (ভিএম) জন্য সমান্তরালভাবে চলতে পারে এমন থ্রেডের সংখ্যাকে সীমাবদ্ধ করে, তবে হোস্ট প্রসেস শিডিয়ুলারটি লজিকাল প্রসেসর (গুলি) এবং এভাবে শারীরিক প্রসেসর (গুলি) পরিবর্তন করবে, যার উপর ভিএম প্রসেসগুলি গতিশীলভাবে চলমান। যদি আপনি কোনও ভিএম-তে একটি উচ্চ লোড অ্যাপ্লিকেশন পরিচালনা করেন, অতিরিক্ত লজিক্যাল কোরগুলি আপনাকে 10% -30% এর একই সুবিধা দেয়। লোডটি একক বহু-থ্রেডযুক্ত অ্যাপ্লিকেশন বা বিভিন্ন অ্যাপ্লিকেশনগুলির একটি সেট হতে পারে।

ভিটি-এক্স বা এএমডি-ভি সহ আধুনিক সিস্টেমে লজিক্যাল কোরগুলির সংখ্যা বাড়িয়ে তোলার জন্য কোনও পারফরম্যান্স জরিমানা নেই, কারণ একই সাথে আরও ভার্চুয়াল মেশিন চালানোর জন্য কোনও পারফরম্যান্স পারফরম্যান্স নেই। আপনার সীমাটি আপনার সিপিইউ চিপের পারফরম্যান্স, সুতরাং আপনি প্রতিটি ভিএমকে কমিয়ে না দিয়ে একই সাথে 3 ভিএম-তে ভিডিও রেন্ডার করতে পারবেন না, কারণ তাদের একই শারীরিক সিপিইউ ভাগ করতে হবে।

আপনার হোস্ট সিস্টেমটি আপত্তিজনক হয়ে উঠতে পারে, যদি আপনি উপস্থিত সমস্ত লজিকাল কোর সহ কোনও ভিএম-তে ভিডিও রেন্ডার করেন তবে আপনি যদি আপনার হোস্টটিতে সেই রেন্ডারিং অ্যাপটি চালান তবে আপনার প্রায় একই সমস্যা হতে পারে। কমপক্ষে ভিএম-তে আপনার একটি পছন্দ আছে এবং আপনি সর্বোচ্চ সিপিইউ লোডটিকে 80% -90% সীমাবদ্ধ করে বা এই কারণে কোরের সংখ্যা হ্রাস করে সমাধান করতে পারেন।


0

আমার সেরা দুটি সেন্ট হ'ল সমস্ত কর / থ্রেড কখনই ব্যবহার না করা, হোস্টের জন্য কেবল এক বা দু'টিকে দেওয়া।

সুতরাং আপনার ক্ষেত্রে, অতিথিকে একটি ছয়টি কোর দিন, কখনই নয় কোনও প্রথম মাপের কোর (কারণ আপনার হোস্টে কেবল 8 টি থ্রেড রয়েছে)।

হোস্টে উপলভ্য থ্রেডের সংখ্যা (কোরের সাথে বিভ্রান্ত না হওয়ার জন্য) যদি হয়:

  • <2, আরও ভাল ভার্চুয়াল মেশিন ব্যবহার না করা
  • যদি 2, মনো-কোর মোডে ভার্চুয়াল মেশিন ব্যবহার করুন বা ঝুঁকি নিয়ে ডুয়াল কোর অতিথি ব্যবহার করুন
  • যদি> 2, আরও ভাল একটি সূত্র ব্যবহার করুন

দু'টিরও বেশি থ্রেডের জন্য আমি এই সূত্রটি ব্যবহার করতে চাই:

  • এন = হোস্টের জন্য থ্রেডের সংখ্যা
  • এম = আমি চালাতে চাই একত্রে ভার্চুয়াল মেশিনের সংখ্যা (সমান ভারসাম্য ধরে নেওয়া, প্রতিটি অতিথির জন্য অতিথির সমান সংখ্যক)
  • সূত্র = (এন -১) / এম হোস্টের কেবল 4 টি থ্রেড বা তার চেয়ে কম থাকলে
  • সূত্র = (এন -২) / এম হোস্টের 4 টির বেশি থ্রেড থাকলে

আমার এক্সপ্রেরেন্স আমাকে বলে যে এ জাতীয় সূত্রের সীমা অতিক্রম না করা খুব মসৃণ এবং কম ঝুঁকিপূর্ণ।

সতর্কতা: অতিথির চালনার সময় অতিথি কোরগুলির সংখ্যা পরিবর্তন করার অনুমতি নেই তবে এটিতে সিপিইউ ব্যবহারের পরিমাণ 100% থেকে কমিয়ে 75% বা 50% করারও অনুমতি দেওয়া হয়েছে, অতিথির কম নয় ব্যর্থ হতে পারে।

তাই মাঝে মাঝে আমি 8 টি থ্রেড হোস্টের জন্য 2 অতিথিকে 6 টি ছয়টি কোর দেওয়ার প্রবণতা করি (সূত্রের সংখ্যাটি যেমন দুটি অতিথির পরিবর্তে কেবলমাত্র একজন অতিথি), তবে তাদের CPU গতির 50% সীমাবদ্ধ করে রাখি (সুতরাং উভয় অতিথি 1 ব্যবহার করতে পারবেন) সিপিইউ / / এর সময়ের 2), তবে যখনই আমি জানি অতিথিরা এমন অ্যাপ্লিকেশনগুলি চালাবেন যা ইমেজ তুলনা / জয়েন্ট ইত্যাদির মতো সমান্তরাল একের বেশি অনুপাতযুক্ত থাকে etc.


1
আপনি নিজেই এই সূত্রগুলি তৈরি করেছিলেন? অথবা আপনি উদ্ধৃতি যুক্ত করতে পারেন?
লিনাক্সসিকিউরিটিফ্রাইক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.