VMware vSphere এ ভার্চুয়াল মেশিনের কর্মক্ষমতা বিশ্লেষণ। পার্ট 1: CPU

আপনি যদি VMware vSphere (বা অন্য কোন প্রযুক্তি স্ট্যাক) এর উপর ভিত্তি করে একটি ভার্চুয়াল পরিকাঠামো পরিচালনা করেন, আপনি সম্ভবত প্রায়শই ব্যবহারকারীদের কাছ থেকে অভিযোগ শুনতে পান: "ভার্চুয়াল মেশিনটি ধীর!" নিবন্ধগুলির এই সিরিজে আমি পারফরম্যান্স মেট্রিক্স বিশ্লেষণ করব এবং আপনাকে বলব যে এটি কী এবং কেন ধীর হয়ে যায় এবং কীভাবে এটি ধীর না হয় তা নিশ্চিত করতে হবে।

আমি ভার্চুয়াল মেশিন কর্মক্ষমতা নিম্নলিখিত দিক বিবেচনা করব:

• CPU- র,
• ফ্রেম,
• ডিস্ক,
• নেটওয়ার্ক।

আমি CPU দিয়ে শুরু করব।

কর্মক্ষমতা বিশ্লেষণ করতে আমাদের প্রয়োজন হবে:

• vCenter পারফরম্যান্স কাউন্টার - পারফরম্যান্স কাউন্টার, যেগুলির গ্রাফগুলি vSphere ক্লায়েন্টের মাধ্যমে দেখা যেতে পারে। এই কাউন্টারগুলির তথ্য ক্লায়েন্টের যেকোন সংস্করণে পাওয়া যায় (C#-এ "মোটা" ক্লায়েন্ট, ফ্লেক্স-এ ওয়েব ক্লায়েন্ট এবং HTML5-এ ওয়েব ক্লায়েন্ট)। এই নিবন্ধগুলিতে আমরা C# ক্লায়েন্টের স্ক্রিনশটগুলি ব্যবহার করব, শুধুমাত্র কারণ তারা ক্ষুদ্রাকৃতিতে আরও ভাল দেখায় :)
• ESXTOP - একটি ইউটিলিটি যা ESXi কমান্ড লাইন থেকে চলে। এর সাহায্যে, আপনি রিয়েল টাইমে পারফরম্যান্স কাউন্টারগুলির মানগুলি পেতে পারেন বা আরও বিশ্লেষণের জন্য একটি নির্দিষ্ট সময়ের জন্য এই মানগুলিকে একটি .csv ফাইলে আপলোড করতে পারেন৷ এর পরে, আমি আপনাকে এই টুল সম্পর্কে আরও বলব এবং এই বিষয়ে ডকুমেন্টেশন এবং নিবন্ধগুলির জন্য বেশ কয়েকটি দরকারী লিঙ্ক প্রদান করব।

তত্ত্ব একটি বিট

ESXi-তে, একটি পৃথক প্রক্রিয়া - VMware পরিভাষায় বিশ্ব - প্রতিটি vCPU (ভার্চুয়াল মেশিন কোর) এর অপারেশনের জন্য দায়ী। পরিষেবা প্রক্রিয়াগুলিও রয়েছে, তবে ভিএম কর্মক্ষমতা বিশ্লেষণের দৃষ্টিকোণ থেকে সেগুলি কম আকর্ষণীয়।

ESXi-তে একটি প্রক্রিয়া চারটি অবস্থার একটিতে হতে পারে:

• চালান - প্রক্রিয়াটি কিছু দরকারী কাজ করে।
• অপেক্ষা করুন - প্রক্রিয়াটি কোন কাজ করছে না (নিষ্ক্রিয়) বা ইনপুট/আউটপুটের জন্য অপেক্ষা করছে।
• কস্টপ - একটি শর্ত যা মাল্টি-কোর ভার্চুয়াল মেশিনে ঘটে। এটি ঘটে যখন হাইপারভাইজার CPU শিডিউলার (ESXi CPU Scheduler) ফিজিক্যাল সার্ভার কোরে সমস্ত সক্রিয় ভার্চুয়াল মেশিন কোরের একযোগে সঞ্চালনের সময় নির্ধারণ করতে পারে না। ভৌত জগতে, সমস্ত প্রসেসর কোর সমান্তরালভাবে কাজ করে, ভিএম-এর অভ্যন্তরে গেস্ট ওএস অনুরূপ আচরণ আশা করে, তাই হাইপারভাইজারকে তাদের ঘড়ির চক্র দ্রুত শেষ করার ক্ষমতা রাখে এমন ভিএম কোরগুলিকে ধীর করতে হবে। ESXi-এর আধুনিক সংস্করণগুলিতে, CPU শিডিউলার রিলাক্সড কো-শিডিউলিং নামে একটি প্রক্রিয়া ব্যবহার করে: হাইপারভাইজার "দ্রুততম" এবং "ধীরগতির" ভার্চুয়াল মেশিন কোরের (স্কু) মধ্যে ব্যবধান বিবেচনা করে। যদি ব্যবধান একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করে, দ্রুত কোরটি কস্টপ অবস্থায় প্রবেশ করে। যদি ভিএম কোরগুলি এই অবস্থায় অনেক সময় ব্যয় করে তবে এটি কর্মক্ষমতা সমস্যা সৃষ্টি করতে পারে।
• প্রস্তুত - প্রক্রিয়াটি এই অবস্থায় প্রবেশ করে যখন হাইপারভাইজার তার সম্পাদনের জন্য সংস্থান বরাদ্দ করতে অক্ষম হয়। উচ্চ প্রস্তুত মান VM কর্মক্ষমতা সমস্যা সৃষ্টি করতে পারে।

বেসিক ভার্চুয়াল মেশিন CPU কর্মক্ষমতা কাউন্টার

CPU 'র ব্যবহার, %. একটি নির্দিষ্ট সময়ের জন্য CPU ব্যবহারের শতাংশ দেখায়।

কিভাবে বিশ্লেষণ করবেন? যদি একটি VM ধারাবাহিকভাবে 90% এ CPU ব্যবহার করে বা 100% পর্যন্ত সর্বোচ্চ থাকে, তাহলে আমাদের সমস্যা আছে। সমস্যাগুলি কেবল VM-এর ভিতরে অ্যাপ্লিকেশনটির "ধীর" অপারেশনে নয়, নেটওয়ার্কে VM-এর অ্যাক্সেসযোগ্যতার ক্ষেত্রেও প্রকাশ করা যেতে পারে। যদি মনিটরিং সিস্টেম দেখায় যে VM পর্যায়ক্রমে বন্ধ হয়ে যায়, তাহলে CPU ব্যবহার গ্রাফের শিখরগুলিতে মনোযোগ দিন।

একটি স্ট্যান্ডার্ড অ্যালার্ম রয়েছে যা ভার্চুয়াল মেশিনের CPU লোড দেখায়:

কি করতে হবে? যদি একটি VM-এর CPU ব্যবহার ক্রমাগত ছাদের মধ্য দিয়ে যাচ্ছে, তাহলে আপনি vCPU-এর সংখ্যা বাড়ানোর কথা ভাবতে পারেন (দুর্ভাগ্যবশত, এটি সর্বদা সাহায্য করে না) বা আরও শক্তিশালী প্রসেসর সহ একটি সার্ভারে VM সরানোর বিষয়ে।

MHz এ CPU ব্যবহার

%-এ vCenter ব্যবহারের গ্রাফগুলিতে আপনি শুধুমাত্র পুরো ভার্চুয়াল মেশিনের জন্য দেখতে পারেন; পৃথক কোরের জন্য কোনও গ্রাফ নেই (Extop-এ কোরের জন্য % মান রয়েছে)। প্রতিটি কোরের জন্য আপনি MHz-এ ব্যবহার দেখতে পারেন।

কিভাবে বিশ্লেষণ করবেন? এটি ঘটে যে একটি অ্যাপ্লিকেশন একটি মাল্টি-কোর আর্কিটেকচারের জন্য অপ্টিমাইজ করা হয় না: এটি শুধুমাত্র একটি কোর 100% ব্যবহার করে এবং বাকিগুলি লোড ছাড়াই নিষ্ক্রিয়। উদাহরণস্বরূপ, ডিফল্ট ব্যাকআপ সেটিংস সহ, MS SQL শুধুমাত্র একটি কোরে প্রক্রিয়া শুরু করে। ফলস্বরূপ, ব্যাকআপটি ধীর হয়ে যায় ডিস্কগুলির ধীর গতির কারণে নয় (ব্যবহারকারী প্রাথমিকভাবে এটি সম্পর্কে অভিযোগ করেছিলেন), তবে প্রসেসরটি মোকাবেলা করতে পারে না। সমস্যাটি পরামিতি পরিবর্তন করে সমাধান করা হয়েছিল: ব্যাকআপ বেশ কয়েকটি ফাইলে (যথাক্রমে, বেশ কয়েকটি প্রক্রিয়াতে) সমান্তরালভাবে চলতে শুরু করে।

কোরগুলিতে অসম লোডের একটি উদাহরণ।

এমন একটি পরিস্থিতিও রয়েছে (উপরের গ্রাফের মতো) যখন কোরগুলি অসমভাবে লোড হয় এবং তাদের মধ্যে কিছু 100% এর শিখর থাকে। শুধুমাত্র একটি কোর লোড করার মতো, CPU ব্যবহারের জন্য অ্যালার্ম কাজ করবে না (এটি সম্পূর্ণ VM-এর জন্য), তবে কর্মক্ষমতা সমস্যা থাকবে।

কি করতে হবে? যদি একটি ভার্চুয়াল মেশিনের সফ্টওয়্যারটি কোরগুলিকে অসমভাবে লোড করে (শুধুমাত্র একটি কোর বা কোরের অংশ ব্যবহার করে), তাদের সংখ্যা বাড়ানোর কোন মানে নেই। এই ক্ষেত্রে, আরও শক্তিশালী প্রসেসর সহ একটি সার্ভারে ভিএম সরানো ভাল।

আপনি সার্ভার BIOS-এ পাওয়ার খরচ সেটিংস চেক করার চেষ্টা করতে পারেন। অনেক অ্যাডমিনিস্ট্রেটর BIOS-এ হাই পারফরম্যান্স মোড সক্ষম করে এবং এর ফলে C-স্টেট এবং P-স্টেট শক্তি সঞ্চয় প্রযুক্তি নিষ্ক্রিয় করে। আধুনিক ইন্টেল প্রসেসরগুলি টার্বো বুস্ট প্রযুক্তি ব্যবহার করে, যা অন্যান্য কোরের খরচে পৃথক প্রসেসর কোরের ফ্রিকোয়েন্সি বাড়ায়। কিন্তু এটি তখনই কাজ করে যখন শক্তি সঞ্চয় প্রযুক্তি চালু থাকে। যদি আমরা তাদের অক্ষম করি, প্রসেসর লোড করা হয় না এমন কোরের শক্তি খরচ কমাতে পারে না।

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

যদি আপনার পরিকাঠামোতে পৃথক ভিএম (বা ভিএম কোর) থাকে যার জন্য সিপিইউ ফ্রিকোয়েন্সি বাড়ানোর প্রয়োজন হয়, সঠিকভাবে বিদ্যুৎ খরচ সামঞ্জস্য করা তাদের কার্যক্ষমতা উল্লেখযোগ্যভাবে উন্নত করতে পারে।

সিপিইউ প্রস্তুত

যদি VM কোর (vCPU) প্রস্তুত অবস্থায় থাকে, তাহলে এটি কার্যকর কাজ করে না। এই অবস্থাটি ঘটে যখন হাইপারভাইজার একটি বিনামূল্যের ফিজিক্যাল কোর খুঁজে পায় না যেখানে ভার্চুয়াল মেশিনের vCPU প্রক্রিয়া বরাদ্দ করা যেতে পারে।

কিভাবে বিশ্লেষণ করবেন? সাধারণত, যদি একটি ভার্চুয়াল মেশিনের কোর 10% এর বেশি সময় প্রস্তুত অবস্থায় থাকে, আপনি কর্মক্ষমতা সমস্যাগুলি লক্ষ্য করবেন। সহজ কথায়, VM 10% এরও বেশি সময় ভৌত সম্পদ উপলব্ধ হওয়ার জন্য অপেক্ষা করে।

vCenter এ আপনি CPU রেডি সম্পর্কিত 2টি কাউন্টার দেখতে পারেন:

• প্রস্তুতি,
• প্রস্তুত.

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

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

রেডি, রেডিনেসের বিপরীতে, শতাংশে নয়, মিলিসেকেন্ডে দেখানো হয়। এটি একটি সমষ্টি টাইপ কাউন্টার, অর্থাৎ, এটি দেখায় পরিমাপের সময়কালে কতক্ষণ ভিএম কোর প্রস্তুত অবস্থায় ছিল। আপনি একটি সাধারণ সূত্র ব্যবহার করে এই মানটিকে শতাংশে রূপান্তর করতে পারেন:

(CPU প্রস্তুত সমষ্টি মান / (চার্ট ডিফল্ট আপডেটের ব্যবধান সেকেন্ডে * 1000)) * 100 = CPU প্রস্তুত %

উদাহরণস্বরূপ, নীচের গ্রাফে VM-এর জন্য, সম্পূর্ণ ভার্চুয়াল মেশিনের জন্য সর্বোচ্চ প্রস্তুত মান নিম্নরূপ হবে:

প্রস্তুত শতাংশ গণনা করার সময়, আপনার দুটি পয়েন্টে মনোযোগ দেওয়া উচিত:

• সম্পূর্ণ VM-এর জন্য প্রস্তুত মান হল কোর জুড়ে প্রস্তুতের সমষ্টি।
• পরিমাপের ব্যবধান। রিয়েল-টাইমের জন্য এটি 20 সেকেন্ড, এবং উদাহরণস্বরূপ, দৈনিক চার্টে এটি 300 সেকেন্ড।

সক্রিয় সমস্যা সমাধানের সাথে, এই সাধারণ পয়েন্টগুলি সহজেই মিস করা যেতে পারে এবং অস্তিত্বহীন সমস্যাগুলি সমাধান করার জন্য মূল্যবান সময় নষ্ট করা যেতে পারে।

নিচের গ্রাফ থেকে প্রাপ্ত ডেটার উপর ভিত্তি করে রেডি গণনা করা যাক। (324474/(20*1000))*100 = 1622% সমগ্র VM এর জন্য। আপনি যদি কোরগুলি দেখেন তবে এটি এত ভীতিকর নয়: 1622/64 = প্রতি কোর 25%। এই ক্ষেত্রে, ক্যাচটি চিহ্নিত করা বেশ সহজ: প্রস্তুত মানটি অবাস্তব। কিন্তু আমরা যদি বেশ কয়েকটি কোর সহ পুরো VM-এর জন্য 10-20% সম্পর্কে কথা বলি, তবে প্রতিটি কোরের জন্য মান স্বাভাবিক সীমার মধ্যে হতে পারে।

কি করতে হবে? একটি উচ্চ প্রস্তুত মান নির্দেশ করে যে সার্ভারে ভার্চুয়াল মেশিনের স্বাভাবিক অপারেশনের জন্য পর্যাপ্ত প্রসেসর সংস্থান নেই। এই ধরনের পরিস্থিতিতে, যা বাকি থাকে তা হল প্রসেসর (vCPU:pCPU) দ্বারা অতিরিক্ত সাবস্ক্রিপশন হ্রাস করা। স্পষ্টতই, বিদ্যমান VM-এর পরামিতি কমিয়ে বা অন্য সার্ভারে VM-এর অংশ স্থানান্তর করে এটি অর্জন করা যেতে পারে।

কো-স্টপ

কিভাবে বিশ্লেষণ করবেন? এই কাউন্টারটিও যোগফলের প্রকারের এবং প্রস্তুত হিসাবে একইভাবে শতাংশে রূপান্তরিত হয়:

(সিপিইউ কো-স্টপ সমষ্টি মান / (সেকেন্ডে চার্ট ডিফল্ট আপডেট ব্যবধান * 1000)) * 100 = CPU কো-স্টপ %

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

এই ক্ষেত্রে, লোড স্পষ্টভাবে অস্বাভাবিক :)

কি করতে হবে? যদি একটি হাইপারভাইজারে প্রচুর সংখ্যক কোর সহ একাধিক VM চলমান থাকে এবং CPU-তে অতিরিক্ত সাবস্ক্রিপশন থাকে, তাহলে কো-স্টপ কাউন্টার বাড়তে পারে, যা এই VMগুলির কার্যকারিতা নিয়ে সমস্যা সৃষ্টি করবে।

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

উচ্চ কো-স্টপের কারণে VM পারফরম্যান্সে সমস্যা এড়াতে, এই VM-এ চালিত সফ্টওয়্যার প্রস্তুতকারকের সুপারিশ এবং VM যেখানে চালিত হয় সেই শারীরিক সার্ভারের ক্ষমতা অনুসারে VM আকার নির্বাচন করুন৷

রিজার্ভে কোর যোগ করবেন না; এটি শুধুমাত্র ভিএমের জন্যই নয়, সার্ভারে তার প্রতিবেশীদের জন্যও পারফরম্যান্স সমস্যা সৃষ্টি করতে পারে।

অন্যান্য দরকারী CPU মেট্রিক্স

চালান - পরিমাপের সময়কালে কত সময় (এমএস) ভিসিপিইউ RUN অবস্থায় ছিল, অর্থাৎ, এটি আসলে দরকারী কাজ সম্পাদন করছিল।

অলস - কতক্ষণ (ms) পরিমাপের সময়কালে vCPU নিষ্ক্রিয় অবস্থায় ছিল। উচ্চ নিষ্ক্রিয় মানগুলি কোনও সমস্যা নয়, ভিসিপিইউতে "কিছুই করার নেই।"

অপেক্ষা করুন - পরিমাপের সময়কালে কতক্ষণ (ms) vCPU অপেক্ষার অবস্থায় ছিল। যেহেতু IDLE এই কাউন্টারে অন্তর্ভুক্ত করা হয়েছে, উচ্চ অপেক্ষার মানগুলিও কোনও সমস্যা নির্দেশ করে না। কিন্তু Wait বেশি হলে Wait IDLE কম হলে, এর মানে হল VM I/O ক্রিয়াকলাপ সম্পূর্ণ হওয়ার জন্য অপেক্ষা করছিল, এবং এর ফলে, হার্ড ড্রাইভ বা VM-এর যেকোনো ভার্চুয়াল ডিভাইসের পারফরম্যান্সের সাথে সমস্যা নির্দেশ করতে পারে।

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

অদলবদল অপেক্ষা করুন - পরিমাপের সময়কালে কতক্ষণ vCPU VMkernel Swap এর সাথে একটি অপারেশনের জন্য অপেক্ষা করেছিল৷ যদি এই কাউন্টারের মান শূন্যের উপরে হয় তবে VM-এর অবশ্যই কর্মক্ষমতা সমস্যা রয়েছে। আমরা RAM কাউন্টার সম্পর্কে নিবন্ধে SWAP সম্পর্কে আরও কথা বলব।

ESXTOP

যদি vCenter-এ পারফরম্যান্স কাউন্টারগুলি ঐতিহাসিক ডেটা বিশ্লেষণের জন্য ভাল হয়, তাহলে সমস্যাটির অপারেশনাল বিশ্লেষণ ESXTOP-এ আরও ভাল করা হয়। এখানে, সমস্ত মান রেডিমেড আকারে উপস্থাপিত হয় (কিছু অনুবাদ করার প্রয়োজন নেই), এবং সর্বনিম্ন পরিমাপ সময়কাল 2 সেকেন্ড।
CPU-এর জন্য ESXTOP স্ক্রীনটিকে "c" কী দিয়ে ডাকা হয় এবং দেখতে এইরকম:

সুবিধার জন্য, আপনি Shift-V টিপে শুধুমাত্র ভার্চুয়াল মেশিন প্রক্রিয়া ছেড়ে যেতে পারেন।
পৃথক VM কোরের জন্য মেট্রিক্স দেখতে, "e" টিপুন এবং আগ্রহের VM-এর GID লিখুন (নীচের স্ক্রিনশটে 30919):

আমাকে সংক্ষেপে ডিফল্টরূপে উপস্থাপিত কলামগুলি দিয়ে যেতে দিন। অতিরিক্ত কলাম "f" টিপে যোগ করা যেতে পারে।

NWLD (বিশ্বের সংখ্যা) - গ্রুপে প্রসেসের সংখ্যা। গ্রুপটি প্রসারিত করতে এবং প্রতিটি প্রক্রিয়ার মেট্রিক্স দেখতে (উদাহরণস্বরূপ, একটি মাল্টি-কোর VM-এ প্রতিটি কোরের জন্য), "e" টিপুন। যদি একটি গ্রুপে একাধিক প্রক্রিয়া থাকে, তাহলে গ্রুপের মেট্রিক মানগুলি পৃথক প্রক্রিয়াগুলির জন্য মেট্রিক্সের যোগফলের সমান।

% ব্যবহার করা হয়েছে - একটি প্রক্রিয়া বা প্রক্রিয়ার গ্রুপ দ্বারা কতগুলি সার্ভার CPU চক্র ব্যবহার করা হয়।

% চালান - পরিমাপের সময়কালে কতক্ষণ প্রক্রিয়াটি RUN অবস্থায় ছিল, যেমন দরকারী কাজ করেছে। এটি %USED থেকে আলাদা যে এটি হাইপার-থ্রেডিং, ফ্রিকোয়েন্সি স্কেলিং এবং সিস্টেমের কাজগুলিতে ব্যয় করা সময় (%SYS) বিবেচনা করে না।

%SYS - সিস্টেমের কাজগুলিতে ব্যয় করা সময়, উদাহরণস্বরূপ: প্রসেসিং, I/O, নেটওয়ার্ক অপারেশন, ইত্যাদি ব্যাহত। VM-এর একটি বড় I/O থাকলে মান বেশি হতে পারে।

OVRLP – যে ফিজিক্যাল কোরে ভিএম প্রক্রিয়া চলছে তা অন্যান্য প্রক্রিয়ার কাজে কত সময় ব্যয় করেছে।

এই মেট্রিকগুলি একে অপরের সাথে নিম্নলিখিত হিসাবে সম্পর্কিত:

% USED = % RUN + % SYS - % OVRLP।

সাধারণত %USED মেট্রিক আরও তথ্যপূর্ণ।

অপেক্ষা করুন - পরিমাপের সময়কালে প্রক্রিয়াটি কতক্ষণ অপেক্ষা করা অবস্থায় ছিল। IDLE সক্ষম করে।

% আইডিএল - পরিমাপের সময়কালে প্রক্রিয়াটি IDLE অবস্থায় ছিল কতক্ষণ।

%SWPWT - পরিমাপের সময়কালে কতক্ষণ vCPU VMkernel Swap এর সাথে একটি অপারেশনের জন্য অপেক্ষা করেছিল৷

% VMWAIT - পরিমাপের সময়কালে কতক্ষণ vCPU একটি ইভেন্টের জন্য অপেক্ষা করার অবস্থায় ছিল (সাধারণত I/O)। vCenter-এ অনুরূপ কোনো কাউন্টার নেই। উচ্চ মান VM-এ I/O এর সাথে সমস্যা নির্দেশ করে।

% WAIT = % VMWAIT + % নিষ্ক্রিয় + % SWPWT।

যদি VM VMkernel Swap ব্যবহার না করে, তাহলে পারফরম্যান্সের সমস্যাগুলি বিশ্লেষণ করার সময় %VMWAIT-এর দিকে তাকানোর পরামর্শ দেওয়া হয়, যেহেতু এই মেট্রিকটি সেই সময়টিকে বিবেচনা করে না যখন VM কিছুই করছিল না (%IDLE)।

%RDY - পরিমাপের সময়কালে প্রক্রিয়াটি প্রস্তুত অবস্থায় ছিল কতক্ষণ।

%CSTP - পরিমাপের সময়কালে প্রক্রিয়াটি কস্টপ অবস্থায় কতক্ষণ ছিল।

%MLMTD - সেট রিসোর্স সীমার কারণে পরিমাপের সময় কতক্ষণ vCPU প্রস্তুত অবস্থায় ছিল।

%WAIT + %RDY + %CSTP + %RUN = 100% – VM কোর সর্বদা এই চারটি অবস্থার একটিতে থাকে।

হাইপারভাইজারে সিপিইউ

vCenter-এ হাইপারভাইজারের জন্য CPU পারফরম্যান্স কাউন্টারও রয়েছে, কিন্তু সেগুলি আকর্ষণীয় কিছু নয় - এগুলি কেবল সার্ভারের সমস্ত VM-এর জন্য কাউন্টারগুলির সমষ্টি৷
সার্ভারে CPU স্থিতি দেখার সবচেয়ে সুবিধাজনক উপায় হল সারাংশ ট্যাবে:

সার্ভারের জন্য, পাশাপাশি ভার্চুয়াল মেশিনের জন্য, একটি স্ট্যান্ডার্ড অ্যালার্ম রয়েছে:

যখন সার্ভারের সিপিইউ লোড বেশি হয়, তখন এটিতে চলমান ভিএমগুলি কর্মক্ষমতা সমস্যা অনুভব করতে শুরু করে।

ESXTOP-এ, সার্ভার CPU লোড ডেটা স্ক্রিনের শীর্ষে উপস্থাপিত হয়। স্ট্যান্ডার্ড CPU লোড ছাড়াও, যা হাইপারভাইজারদের জন্য খুব বেশি তথ্যপূর্ণ নয়, আরও তিনটি মেট্রিক্স রয়েছে:

কোর ইউটিএল(%) - শারীরিক সার্ভার কোর লোড হচ্ছে। এই কাউন্টারটি দেখায় যে পরিমাপের সময়কালে কোরটি কত সময় কাজ করেছে।

PCPU UTIL(%) - যদি হাইপার-থ্রেডিং সক্ষম করা থাকে, তাহলে প্রতি ফিজিক্যাল কোরে দুটি থ্রেড (PCPU) থাকে। এই মেট্রিক দেখায় যে প্রতিটি থ্রেড কাজ সম্পূর্ণ করতে কত সময় নেয়।

PCPU ব্যবহার করা হয়েছে(%) – PCPU UTIL(%) এর মতোই, তবে ফ্রিকোয়েন্সি স্কেলিং (হয় শক্তি সাশ্রয়ের উদ্দেশ্যে মূল ফ্রিকোয়েন্সি হ্রাস করা বা টার্বো বুস্ট প্রযুক্তির কারণে মূল ফ্রিকোয়েন্সি বৃদ্ধি) এবং হাইপার-থ্রেডিংকে বিবেচনা করে।

PCPU_USED% = PCPU_UTIL% * কার্যকর কোর ফ্রিকোয়েন্সি / নামমাত্র কোর ফ্রিকোয়েন্সি।

এই স্ক্রিনশটে, কিছু কোরের জন্য, টার্বো বুস্টের কারণে, USED মান 100%-এর বেশি, কারণ মূল ফ্রিকোয়েন্সি নামমাত্র একের চেয়ে বেশি।

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

• কোরের জন্য CORE UTIL হবে 100%,
• উভয় থ্রেডের জন্য PCPU UTIL হবে 100%,
• উভয় থ্রেডের জন্য ব্যবহৃত PCPU 50% হবে।

যদি উভয় থ্রেড পরিমাপের সময়কালে 100% সময় কাজ না করে, তাহলে সেই সময়কালে যখন থ্রেডগুলি সমান্তরালভাবে কাজ করে, কোরগুলির জন্য ব্যবহৃত PCPU অর্ধেক ভাগ করা হয়।

ESXTOP-এ সার্ভারের CPU পাওয়ার খরচ পরামিতি সহ একটি স্ক্রিন রয়েছে। এখানে আপনি সার্ভার শক্তি সঞ্চয় প্রযুক্তি ব্যবহার করে কিনা দেখতে পারেন: C-স্টেটস এবং P-স্টেটস। "p" কী দিয়ে কল করা হয়েছে:

সাধারণ CPU কর্মক্ষমতা সমস্যা

অবশেষে, আমি ভিএম সিপিইউ পারফরম্যান্সের সাথে সমস্যার সাধারণ কারণগুলি নিয়ে যাব এবং সেগুলি সমাধানের জন্য সংক্ষিপ্ত টিপস দেব:

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

ভুল VM সাইজিং (খুব বেশি/কয়েক কোর)। আপনি যদি কয়েকটি কোর ইনস্টল করেন তবে VM-এ একটি উচ্চ CPU লোড থাকবে। যদি অনেক থাকে, একটি উচ্চ কো-স্টপ ধরুন।

সার্ভারে CPU এর বড় ওভারসাবস্ক্রিপশন। যদি VM এর উচ্চ রেডি থাকে, তাহলে CPU ওভারসাবস্ক্রিপশন কমিয়ে দিন।

বড় VM-এ ভুল NUMA টপোলজি। VM (vNUMA) দ্বারা দেখা NUMA টপোলজি সার্ভারের (pNUMA) NUMA টপোলজির সাথে মেলে। এই সমস্যার ডায়াগনস্টিকস এবং সম্ভাব্য সমাধানগুলি লেখা আছে, উদাহরণস্বরূপ, বইটিতে "VMware vSphere 6.5 হোস্ট রিসোর্স ডিপ ডাইভ". আপনি যদি আরও গভীরে যেতে না চান এবং VM-এ ইনস্টল করা OS-তে আপনার লাইসেন্সিং বিধিনিষেধ না থাকে, তাহলে VM-এ অনেকগুলি ভার্চুয়াল সকেট তৈরি করুন, এক সময়ে একটি কোর৷ আপনি অনেক হারাবেন না :)

যে CPU সম্পর্কে আমার জন্য সব. প্রশ্ন কর. পরের অংশে আমি RAM সম্পর্কে কথা বলব।

দরকারী লিঙ্কhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

উত্স: www.habr.com