ভার্চুয়ালাইজড সিপিইউ কর্স বনাম থ্রেড


8

হাইপারথ্রেডিং সহ একটি নতুন কোয়াড-কোর জিয়ান সিপিইউ সহ আমরা উবুন্টু 9.10 এ একটি কেভিএম হোস্ট সিস্টেম পেয়েছি। ইন্টেলের পণ্য পৃষ্ঠাতে বিস্তারিত হিসাবে , প্রসেসরের 4 টি কোর কিন্তু 8 টি থ্রেড রয়েছে। / প্রোক / সিপুইনফো এবং উভয় তালিকার জন্য 8 টি প্রসেসরের তালিকা রয়েছে, যদিও প্রত্যেকে সিপুইনফোতে 4 টি কোর প্রযোজ্য। কেভিএম / কিউইএমইউ 8 অতিথিদের নিয়োগের জন্য উপলব্ধ ভিসিপিইউও রিপোর্ট করে।

আমার প্রশ্ন হ'ল আমি যখন ভিএম অতিথিদের ভিসিপিইউ বরাদ্দ করি তখন আমার কি প্রতি-কোর বা প্রতি থ্রেড বরাদ্দ করা উচিত? যেহেতু কেভিএম / কিউইএমইউ জানায় যে সার্ভারের 8 টি ভিসিপিইউ বরাদ্দ রয়েছে, তাই আমি কি আগে গিয়ে 4 টি সিপিইউ ব্যবহারের জন্য কোনও গেস্ট সেট করা উচিত যেখানে আমি আগে এটি 2 ব্যবহারের জন্য সেট করে রেখেছিলাম (4 টি মোট ভিসিপিইউ উপলব্ধ বলে ধরে নিলাম)? আমি অতিরিক্ত বরাদ্দ ছাড়াই হোস্ট হার্ডওয়্যার থেকে সর্বাধিক সম্ভব পেতে চাই।

আপডেট: চপ্পার 3 এর উত্তর নিঃসন্দেহে সঠিক পদ্ধতির। তবে, আমি এখনও কোনও হার্ডওয়ার বিশেষজ্ঞের কাছ থেকে শুনতে আগ্রহী যে কে থ্রেড বনাম কোরগুলির পারফরম্যান্স দিকটি ব্যাখ্যা করতে পারে ... কেউ?

উত্তর:


8

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


1
এটি বুদ্ধিমান পদ্ধতির মতো বলে মনে হচ্ছে। তবুও, আমি আগ্রহী যে কীভাবে প্রতি कोरের পরিবর্তে থ্রেডে ভিসিপিইউগুলি বরাদ্দ করা কার্য সম্পাদনকে প্রভাবিত করে। তবে আমি খুব খারাপ কিছু দেখেছি যা অতিরিক্ত বরাদ্দের ফলে ঘটতে পারে, এবং হাইপারথ্রেডহোল্ড হোস্টের মতো একই সংখ্যার ভিসিপিইউ ব্যবহার করা অতিথিদের জন্য যথেষ্ট পরিমাণে বোঝা পরিচালনা করে বলে মনে হয়, তাই আমি যথেষ্ট পরিমাণে একা চলে যাব I'll এবং কোনও সময় অ-উত্পাদিত বাক্সে পরীক্ষা করার পরিকল্পনা করুন plan
নেডম

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

1
যদিও আমি ন্যূনতম পদ্ধতির সাথে একমত, কেভিএম এই অর্থে ভিএমওয়্যার নয়। কোনও গ্যাং শিডিউলিংয়ের অর্থ ভিএম প্রতি বেশি
ভিসিপিইউ নিরীহভাবে

5

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

ভিএম-তে অ্যাপ্লিকেশনগুলি থ্রেডিংয়ের জন্য লিখিত থাকলে, তবে এটি হাইপারভাইসারের জন্য জীবনকে আরও শক্ত করে তোলে; এটি একবারে ২ বা ৪ টি সিপিইউতে সময় বরাদ্দ করতে হবে - সুতরাং আপনার যদি কোয়াড-কোর সিপিইউ এবং কোয়াড-ভিসিপিইউ ভিএম থাকে তবে কেবলমাত্র একটি ভিএম সেই সময়সীমার সময়সূচী পেতে পারে (যেখানে এটি ৪ টি পৃথক একক-ভিসিপিইউ ভিএম চালাতে পারে একবার).


@ ক্রিস, @ টেকিবি0y: ধন্যবাদ, আমি ঠিক এই ধরণের অন্তর্দৃষ্টি খুঁজছিলাম।
নেডম

এটা ঠিক সত্য নয়। যখন কোয়াড ভিসিপিউ সহ একটি ভিএমকে একটি একক ভি-কোর নির্ধারণ করতে হবে, এটি 4 টি কোর নয়, হোস্টের জন্য নির্ধারিত হয়। কমপক্ষে কেভিএমের ক্ষেত্রে এটি ঘটেছে (আমি জানি ভিএমওয়্যারের দৃষ্টিভঙ্গি কম কার্যকর, কারণ তারা গ্যাংশেডিংয়ের কাজ করে)
ডায়াসনি

5

এটি বরং কৃপণ। লোডের উপর নির্ভর করে এইচটি এইচটি 30 ~ দ্বারা কর্মক্ষমতা বাড়াতে বা এটি হ্রাস করতে পারে। সাধারণত আমি পরামর্শ দিচ্ছি যে আপনার একক ভিএম-তে শারীরিক কোরের চেয়ে বেশি ভিসিপিইউ বরাদ্দ না করা, তবে ভিএম যদি অকার্যকর হয় (এবং অবশ্যই, এই জাতীয় কোনও ভিএমকে খুব বেশি সিপিইউ প্রয়োজন হবে না), এটি হিসাবে দেওয়া যেতে পারে আপনার থ্রেড থাকায় অনেকগুলি ভিসিপিইউ রয়েছে। আপনি না সত্যিই একটি একক VM- র আরো vCPUs দিতে চেয়ে আপনি চান schedulable কোর কি আমি পেয়ে করছি হয়। এবং যে কোনও ক্ষেত্রে, @ চপ্পার 3 এর পরামর্শ সঠিক - ভিএমকে একেবারে প্রয়োজনের তুলনায় বেশি ভি-সিপিইউ দেবেন না।

সুতরাং, আপনার ভিএমগুলি কীভাবে বোঝা এবং সমালোচিত তার উপর নির্ভর করে আপনি হয় মোটেও সামগ্রিকভাবে চলেন না, শারীরিক মূল গণনাটিতে আটকে থাকবেন না বা ভিএম প্রতি থ্রেড কাউন্টের চেয়েও উপরে যাবেন না।

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

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


2

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

উপরেরটি ভিসিপিইউ বনাম পিনযুক্ত সিপিইউ সম্পর্কিত নীচের বোঝার উপর ভিত্তি করে তৈরি করা হয়েছে, তবে এই ধারণাটিও যে কেভিএম একক অতিথিকে (বা একাধিক অতিথি) অন্যদের কাছ থেকে সমস্ত আসল সিপিইউ হগ করার অনুমতি দেয় যদি আপনি এটির (/ তাদের) যথেষ্ট পরিমাণে বরাদ্দ করেন। ভিসিপিইউ ~ হোস্ট থ্রেড, অতিথি সিপিইউ সিপিইউ = হোস্ট কোর, অতিথি সিপিইউ (একই অতিথিতে মিশ্রিত ভিসিপিইউ এবং পিন করা সিপিইউ নিয়ে খেলেনি, কারণ আমার হাইপারথ্রেডিং নেই))


1
পিনযুক্ত ভিসিপিইউ হ'ল একটি ভার্চুয়াল সিপিইউ প্রক্রিয়া যা কেবলমাত্র একটি নির্দিষ্ট কোর (বা কোরগুলির একটি উপসেট) চালানোর জন্য নির্ধারিত হয়। যদি আপনি সামগ্রিকভাবে না জড়িত না হন এবং নিশ্চিত করতে চান যে ভিএমগুলি একই কোর এর সিপিইউ সময়ের জন্য বিতর্ক করছে না, আপনি এগুলি বিভিন্ন কোরগুলিতে পিন করতে পারেন। এটি NUMA পিনিং করারও একটি উপায়, যদিও আপনি আজকাল সরাসরি এটি করতে পারেন
dyasny
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.