VMware vSphere-এ VM কর্মক্ষমতা বিশ্লেষণ। পর্ব 2: স্মৃতি

পার্ট 1. CPU সম্পর্কে

এই নিবন্ধে, আমরা vSphere-এ র্যান্ডম অ্যাক্সেস মেমরির (RAM) কর্মক্ষমতা কাউন্টার সম্পর্কে কথা বলব।
মনে হচ্ছে প্রসেসরের চেয়ে মেমরির সাথে সবকিছুই আরও স্পষ্ট: যদি কোনও VM-এর কর্মক্ষমতা সমস্যা থাকে তবে সেগুলি লক্ষ্য করা কঠিন। তবে যদি তারা উপস্থিত হয় তবে তাদের মোকাবেলা করা আরও কঠিন। কিন্তু প্রথম জিনিস প্রথম.

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

ভার্চুয়াল মেশিনের র‌্যাম সেই সার্ভারের মেমরি থেকে নেওয়া হয় যার ভিএমগুলি চলছে। এটা বেশ সুস্পষ্ট :)। সার্ভারের RAM সকলের জন্য পর্যাপ্ত না হলে, ESXi RAM-এর ব্যবহার অপ্টিমাইজ করার জন্য মেমরি পুনরুদ্ধার কৌশল ব্যবহার করা শুরু করে। অন্যথায়, VM অপারেটিং সিস্টেম RAM অ্যাক্সেস ত্রুটির সাথে ক্র্যাশ হবে।

ESXi ব্যবহার করার কৌশলগুলি RAM এর লোডের উপর নির্ভর করে সিদ্ধান্ত নেয়:

স্মৃতির অবস্থা

সীমান্ত

ক্রিয়াকলাপ

উচ্চ

400% মিনিট ফ্রি

ঊর্ধ্ব সীমায় পৌঁছানোর পরে, বড় মেমরি পৃষ্ঠাগুলিকে ছোট আকারে বিভক্ত করা হয় (টিপিএস স্ট্যান্ডার্ড মোডে কাজ করে)।

পরিষ্কার

100% মিনিট ফ্রি

বড় মেমরি পৃষ্ঠাগুলিকে ছোট করে ভেঙে ফেলা হয়, টিপিএস কাজ করতে বাধ্য হয়।

কোমল

64% মিনিট ফ্রি

TPS + বেলুন

কঠিন

32% মিনিট ফ্রি

TPS + কম্প্রেস + অদলবদল

কম

16% মিনিট ফ্রি

কম্প্রেস + অদলবদল + ব্লক

উৎস

minFree হল হাইপারভাইজার কাজ করার জন্য প্রয়োজনীয় RAM।

ESXi 4.1 অন্তর্ভুক্ত করার আগে, minFree ডিফল্টরূপে স্থির করা হয়েছিল - সার্ভারের RAM এর 6% (শতাংশটি ESXi-তে Mem.MinFreePct বিকল্পের মাধ্যমে পরিবর্তন করা যেতে পারে)। পরবর্তী সংস্করণগুলিতে, সার্ভারগুলিতে মেমরির আকার বৃদ্ধির কারণে, minFree-কে হোস্ট মেমরির পরিমাণের উপর ভিত্তি করে গণনা করা শুরু হয়েছিল, একটি নির্দিষ্ট শতাংশ হিসাবে নয়।

minFree (ডিফল্ট) মান নিম্নরূপ গণনা করা হয়:

minFree-এর জন্য সংরক্ষিত মেমরির শতাংশ

মেমরি পরিসীমা

6%

0-4 জিবি

4%

4-12 জিবি

2%

12-28 জিবি

1%

অবশিষ্ট স্মৃতি

উৎস

উদাহরণস্বরূপ, 128 GB RAM সহ একটি সার্ভারের জন্য, MinFree মান হবে:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
প্রকৃত মান কয়েকশ MB দ্বারা পৃথক হতে পারে, এটি সার্ভার এবং RAM এর উপর নির্ভর করে।

minFree-এর জন্য সংরক্ষিত মেমরির শতাংশ

মেমরি পরিসীমা

128 গিগাবাইটের জন্য মান

6%

0-4 জিবি

245,76 এমবি

4%

4-12 জিবি

327,68 এমবি

2%

12-28 জিবি

327,68 এমবি

1%

অবশিষ্ট মেমরি (100 জিবি)

1024 এমবি

সাধারণত, উত্পাদনশীল স্ট্যান্ডের জন্য, শুধুমাত্র উচ্চ রাজ্যকে স্বাভাবিক হিসাবে বিবেচনা করা যেতে পারে। পরীক্ষা এবং উন্নয়ন বেঞ্চের জন্য, ক্লিয়ার/সফট স্টেট গ্রহণযোগ্য হতে পারে। যদি হোস্টের RAM 64% MinFree-এর কম হয়, তাহলে এটিতে চলমান VM-এ অবশ্যই পারফরম্যান্স সমস্যা রয়েছে।

প্রতিটি রাজ্যে, কিছু মেমরি পুনরুদ্ধার কৌশল প্রয়োগ করা হয়, টিপিএস থেকে শুরু করে, যা কার্যত VM-এর কার্যকারিতাকে প্রভাবিত করে না এবং অদলবদল দিয়ে শেষ হয়। আমি তাদের সম্পর্কে আরো বলতে হবে.

স্বচ্ছ পেজ শেয়ারিং (টিপিএস)। TPS হল, মোটামুটিভাবে বলতে গেলে, একটি সার্ভারে ভার্চুয়াল মেশিন মেমরি পৃষ্ঠাগুলির অনুলিপি।

ESXi পৃষ্ঠাগুলির হ্যাশ যোগফল গণনা এবং তুলনা করে ভার্চুয়াল মেশিন র‌্যামের অভিন্ন পৃষ্ঠাগুলি সন্ধান করে, এবং ডুপ্লিকেট পৃষ্ঠাগুলি সরিয়ে দেয়, সার্ভারের শারীরিক মেমরিতে একই পৃষ্ঠার লিঙ্কগুলির সাথে প্রতিস্থাপন করে৷ ফলস্বরূপ, শারীরিক মেমরি খরচ হ্রাস করা হয় এবং কিছু মেমরি ওভারসাবস্ক্রিপশন সামান্য বা কোন কর্মক্ষমতা হ্রাস সঙ্গে অর্জন করা যেতে পারে.

উৎস

এই প্রক্রিয়াটি শুধুমাত্র 4 KB মেমরি পৃষ্ঠাগুলির জন্য কাজ করে (ছোট পৃষ্ঠাগুলি)। হাইপারভাইজার এমনকি 2 এমবি (বড় পৃষ্ঠা) পৃষ্ঠাগুলি অনুমান করার চেষ্টা করে না: এই আকারের অভিন্ন পৃষ্ঠাগুলি খুঁজে পাওয়ার সুযোগটি খুব বেশি নয়৷

ডিফল্টরূপে, ESXi বড় পৃষ্ঠাগুলিতে মেমরি বরাদ্দ করে। বড় পৃষ্ঠাগুলিকে ছোট পৃষ্ঠাগুলিতে ভাঙ্গা শুরু হয় যখন হাই স্টেট থ্রেশহোল্ডে পৌঁছে যায় এবং যখন ক্লিয়ার স্টেটে পৌঁছে তখন বাধ্য করা হয় (হাইপারভাইজার স্টেট টেবিল দেখুন)।

আপনি যদি চান যে TPS হোস্ট RAM পূরণের জন্য অপেক্ষা না করে কাজ শুরু করুক, তাহলে Advanced Options ESXi-এ আপনাকে মান সেট করতে হবে "Mem.AllocGuestLargePage" থেকে 0 (ডিফল্ট 1)। তারপর ভার্চুয়াল মেশিনের জন্য বড় মেমরি পৃষ্ঠাগুলির বরাদ্দ অক্ষম করা হবে।

ডিসেম্বর 2014 থেকে, ESXi-এর সমস্ত রিলিজে, VM-এর মধ্যে TPS ডিফল্টরূপে অক্ষম করা হয়েছে, কারণ একটি দুর্বলতা পাওয়া গেছে যে তাত্ত্বিকভাবে একটি VM থেকে অন্য VM-এর RAM-তে অ্যাক্সেসের অনুমতি দেয়৷ বিস্তারিত এখানে. TPS দুর্বলতাকে কাজে লাগানোর ব্যবহারিক বাস্তবায়ন সম্পর্কে আমি কোনো তথ্য পাইনি।

TPS নীতি উন্নত বিকল্পের মাধ্যমে নিয়ন্ত্রিত "Mem.ShareForceSalting" ESXi তে:
0 - ইন্টার-ভিএম টিপিএস। TPS বিভিন্ন VM-এর পৃষ্ঠাগুলির জন্য কাজ করে;
1 - VMX-এ একই "sched.mem.pshare.salt" মান সহ VM-এর জন্য TPS;
2 (ডিফল্ট) - Intra-VM TPS। TPS VM এর ভিতরের পৃষ্ঠাগুলির জন্য কাজ করে।

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

মেমরি বেলুনিং VM অপারেটিং সিস্টেমের জন্য বেলুনিং টিপিএসের মতো নিরীহ এবং স্বচ্ছ কৌশল নয়। কিন্তু সঠিক প্রয়োগের সাথে, আপনি বেলুনিংয়ের সাথে বাঁচতে এবং এমনকি কাজ করতে পারেন।

ভিএমওয়্যার টুলের সাথে, বেলুন ড্রাইভার (ওরফে vmmemctl) নামে একটি বিশেষ ড্রাইভার VM এ ইনস্টল করা আছে। হাইপারভাইজার যখন ফিজিক্যাল মেমরি ফুরিয়ে যেতে শুরু করে এবং সফট স্টেটে প্রবেশ করে, তখন ESXi VM কে এই বেলুন ড্রাইভারের মাধ্যমে অব্যবহৃত RAM পুনরুদ্ধার করতে বলে। ড্রাইভার, পরিবর্তে, অপারেটিং সিস্টেম স্তরে কাজ করে এবং এটি থেকে বিনামূল্যে মেমরির অনুরোধ করে। হাইপারভাইজার দেখেন যে বেলুন ড্রাইভার কোন পৃষ্ঠাগুলি দখল করেছে, ভার্চুয়াল মেশিন থেকে মেমরি নেয় এবং হোস্টে ফেরত দেয়। ওএসের অপারেশনে কোনও সমস্যা নেই, যেহেতু ওএস স্তরে মেমরিটি বেলুন ড্রাইভার দ্বারা দখল করা হয়। ডিফল্টরূপে বেলুন ড্রাইভার ভিএম মেমরির 65% পর্যন্ত নিতে পারে।

যদি ভিএমওয়্যার সরঞ্জামগুলি ভিএম-এ ইনস্টল করা না থাকে বা বেলুনিং অক্ষম করা হয় (আমি সুপারিশ করি না, তবে আছে KB:), হাইপারভাইজার অবিলম্বে আরও কঠোর মেমরি অপসারণ কৌশলগুলিতে স্যুইচ করে। উপসংহার: নিশ্চিত করুন যে ভিএমওয়্যার সরঞ্জামগুলি ভিএম-এ রয়েছে।

VMware Tools এর মাধ্যমে OS থেকে বেলুন ড্রাইভারের অপারেশন চেক করা যেতে পারে.

মেমরি কম্প্রেশন। এই কৌশলটি ব্যবহার করা হয় যখন ESXi হার্ড অবস্থায় পৌঁছায়। নাম থেকেই বোঝা যাচ্ছে, ESXi 4KB পৃষ্ঠার RAM কে 2KB-তে সঙ্কুচিত করার চেষ্টা করে এবং এইভাবে সার্ভারের শারীরিক মেমরিতে কিছু জায়গা খালি করে। এই কৌশলটি VM RAM পৃষ্ঠাগুলির বিষয়বস্তুতে অ্যাক্সেসের সময়কে উল্লেখযোগ্যভাবে বৃদ্ধি করে, যেহেতু পৃষ্ঠাটি প্রথমে আনকম্প্রেস করা আবশ্যক। কখনও কখনও সমস্ত পৃষ্ঠাগুলি সংকুচিত করা যায় না এবং প্রক্রিয়াটি নিজেই কিছু সময় নেয়। অতএব, এই কৌশলটি অনুশীলনে খুব কার্যকর নয়।

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

সোয়াপিং কিভাবে কাজ করে তা এখানে। আপনি যখন একটি ভার্চুয়াল মেশিন চালু করেন, তখন এটির জন্য .vswp এক্সটেনশন সহ একটি ফাইল তৈরি করা হয়। এটি VM এর অসংরক্ষিত RAM এর আকারের সমান: এটি কনফিগার করা এবং সংরক্ষিত মেমরির মধ্যে পার্থক্য। যখন সোয়াপিং চলছে, তখন ESXi ভার্চুয়াল মেশিন মেমরি পৃষ্ঠাগুলি এই ফাইলে আনলোড করে এবং সার্ভারের শারীরিক মেমরির পরিবর্তে এটির সাথে কাজ শুরু করে। অবশ্যই, এই ধরনের "অপারেটিভ" মেমরি বাস্তবের তুলনায় ধীরগতির অনেকগুলি অর্ডার, এমনকি যদি .vswp দ্রুত স্টোরেজে থাকে।

বেলুনিংয়ের বিপরীতে, যখন অব্যবহৃত পৃষ্ঠাগুলি VM থেকে নেওয়া হয়, অদলবদল করে, যে পৃষ্ঠাগুলি সক্রিয়ভাবে OS দ্বারা ব্যবহৃত হয় বা VM-এর ভিতরের অ্যাপ্লিকেশনগুলি ডিস্কে চলে যেতে পারে৷ ফলস্বরূপ, ভিএম-এর কর্মক্ষমতা হিমায়িত হওয়ার পর্যায়ে নেমে আসে। VM আনুষ্ঠানিকভাবে কাজ করে এবং অন্তত এটি OS থেকে সঠিকভাবে নিষ্ক্রিয় করা যেতে পারে। আপনি যদি ধৈর্যশীল হন 😉

যদি ভিএমগুলি অদলবদল করতে যায়, এটি একটি অস্বাভাবিক পরিস্থিতি, যা সম্ভব হলে এড়ানো ভাল।

মূল VM মেমরি কর্মক্ষমতা কাউন্টার

তাই আমরা মূল পয়েন্ট পেয়েছিলাম. VM-তে মেমরির অবস্থা নিরীক্ষণ করতে, নিম্নলিখিত কাউন্টার রয়েছে:

সক্রিয় — পূর্ববর্তী পরিমাপের সময়কালে VM-এ যে পরিমাণ RAM (KB) অ্যাক্সেস পেয়েছিল তা দেখায়।

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

শেয়ারকৃত - TPS (VM-এর ভিতরে বা VM-এর মধ্যে) ব্যবহার করে কেটে নেওয়া VM RAM-এর পরিমাণ।

মঞ্জুর - ভৌত হোস্ট মেমরির পরিমাণ (KB) যা VM কে দেওয়া হয়েছিল। শেয়ার করা অন্তর্ভুক্ত.

ক্ষয়প্রাপ্ত (মঞ্জুর করা হয়েছে - শেয়ার করা) - ভৌত মেমরির পরিমাণ (KB) যা VM হোস্ট থেকে গ্রহণ করে। শেয়ার করা অন্তর্ভুক্ত নয়।

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

শূন্য — VM RAM এর পরিমাণ (KB), যাতে শূন্য থাকে। এই ধরনের মেমরি হাইপারভাইজার দ্বারা বিনামূল্যে বিবেচিত হয় এবং অন্যান্য ভার্চুয়াল মেশিনে দেওয়া যেতে পারে। গেস্ট ওএস জিরোড মেমরিতে কিছু লেখার পরে, এটি Consumed-এ যায় এবং ফিরে আসে না।

সংরক্ষিত ওভারহেড — VM র‍্যামের পরিমাণ, (KB) VM অপারেশনের জন্য হাইপারভাইজার দ্বারা সংরক্ষিত। এটি একটি ছোট পরিমাণ, তবে এটি অবশ্যই হোস্টে উপলব্ধ হতে হবে, অন্যথায় VM শুরু হবে না।

বেলুন — বেলুন ড্রাইভার ব্যবহার করে VM থেকে জব্দ করা RAM (KB) এর পরিমাণ।

কম্প্রেস - RAM এর পরিমাণ (KB) যা সংকুচিত হয়েছিল।

অদলবদল - সার্ভারে শারীরিক মেমরির অভাবের কারণে ডিস্কে সরানো RAM (KB) এর পরিমাণ।
বেলুন এবং অন্যান্য স্মৃতি পুনরুদ্ধার কৌশল কাউন্টার শূন্য।

মেমরি কাউন্টার সহ গ্রাফটি 150 গিগাবাইট র‍্যাম সহ একটি সাধারণভাবে কাজ করা VM-এর মতো দেখায়৷

নীচের গ্রাফে, ভিএম-এর স্পষ্ট সমস্যা রয়েছে। গ্রাফের অধীনে, আপনি দেখতে পাচ্ছেন যে এই VM এর জন্য, RAM এর সাথে কাজ করার জন্য বর্ণিত সমস্ত কৌশল ব্যবহার করা হয়েছিল। এই VM এর জন্য বেলুন Consumed এর থেকে অনেক বড়। আসলে, ভিএম জীবিতের চেয়ে বেশি মৃত।

ESXTOP

সিপিইউ-এর মতো, যদি আমরা হোস্টের পরিস্থিতি দ্রুত মূল্যায়ন করতে চাই, সেইসাথে 2 সেকেন্ড পর্যন্ত ব্যবধানে এর গতিশীলতা, আমাদের ESXTOP ব্যবহার করা উচিত।

মেমরি দ্বারা ESXTOP স্ক্রীনটি "m" কী দিয়ে কল করা হয় এবং এটি দেখতে এইরকম হয় (ক্ষেত্র B, D, H, J, K, L, O নির্বাচন করা হয়েছে):

নিম্নলিখিত পরামিতি আমাদের আগ্রহের হবে:

মেম ওভারকমিট গড় - হোস্টে মেমরি ওভারসাবস্ক্রিপশনের গড় মান 1, 5 এবং 15 মিনিটের জন্য। যদি এটি শূন্যের উপরে হয়, তবে এটি কী ঘটছে তা দেখার একটি উপলক্ষ, তবে সর্বদা সমস্যার সূচক নয়।

লাইনে PMEM/MB и VMKMEM/MB - সার্ভারের শারীরিক মেমরি এবং VMkernel-এ উপলব্ধ মেমরি সম্পর্কে তথ্য। এখানে আকর্ষণীয় থেকে আপনি মিনফ্রির মান দেখতে পারেন (এমবিতে), মেমরিতে হোস্টের অবস্থা (আমাদের ক্ষেত্রে, উচ্চ)।

সঙ্গতিপূর্ণভাবে NUMA/MB আপনি NUMA নোড (সকেট) দ্বারা RAM এর বিতরণ দেখতে পারেন। এই উদাহরণে, বিতরণটি অসম, যা নীতিগতভাবে খুব ভাল নয়।

নিম্নলিখিত মেমরি পুনরুদ্ধার কৌশলগুলির সাধারণ সার্ভার পরিসংখ্যান:

PSHARE/MB TPS পরিসংখ্যান;

SWAP/MB — অদলবদল ব্যবহার পরিসংখ্যান;

জিপ/এমবি — মেমরি পৃষ্ঠা কম্প্রেশন পরিসংখ্যান;

MEMCTL/MB - বেলুন ড্রাইভার ব্যবহারের পরিসংখ্যান।

পৃথক VM-এর জন্য, আমরা নিম্নলিখিত তথ্যে আগ্রহী হতে পারি। আমি ভিএম নামগুলি লুকিয়ে রেখেছিলাম যাতে দর্শকদের বিভ্রান্ত না হয় :)। যদি ESXTOP মেট্রিক vSphere-এর কাউন্টারের অনুরূপ হয়, আমি সংশ্লিষ্ট কাউন্টার দিই।

MEMSZ — VM (MB) এ কনফিগার করা মেমরির পরিমাণ।
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

প্রদান — এমবি দেওয়া হয়েছে।

টিসিএইচডি — এমবি-তে সক্রিয়।

এমসিটিএল? - VM এ বেলুন ড্রাইভার ইনস্টল করা আছে কিনা।

MCTLSZ — বেলুন থেকে এমবি।

এমসিটিএলজিটি — ESXi VM থেকে বেলুন ড্রাইভার (Memctl টার্গেট) এর মাধ্যমে যে পরিমাণ RAM (MB) নিতে চায়।

MCTLMAX - বেলুন ড্রাইভারের মাধ্যমে ESXi VM থেকে সর্বাধিক পরিমাণ RAM (MB) নিতে পারে৷

SWCUR — Swap ফাইল থেকে VM-এ বরাদ্দকৃত বর্তমান পরিমাণ RAM (MB)।

S.W.G.T. - ESXi Swap ফাইল (Swap টার্গেট) থেকে VM-কে যে পরিমাণ RAM (MB) দিতে চায়।

এছাড়াও, ESXTOP-এর মাধ্যমে, আপনি VM-এর NUMA টপোলজি সম্পর্কে আরও বিস্তারিত তথ্য দেখতে পারেন। এটি করার জন্য, D, G ক্ষেত্রগুলি নির্বাচন করুন:

এনএনএইচ – NUMA নোড যেখানে VM অবস্থিত। এখানে আপনি অবিলম্বে প্রশস্ত vm লক্ষ্য করতে পারেন, যা একটি NUMA নোডে ফিট করে না।

এনআরএমইএম - দূরবর্তী NUMA নোড থেকে VM কত মেগাবাইট মেমরি নেয়।

এনএলএমইএম - স্থানীয় NUMA নোড থেকে VM কত মেগাবাইট মেমরি নেয়।

N%L - স্থানীয় NUMA নোডে VM মেমরির শতাংশ (যদি 80% এর কম, কর্মক্ষমতা সমস্যা হতে পারে)।

হাইপারভাইজারে মেমরি

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

অদলবদল করুন

যদি একটি VM Swap-এ থাকে, তাহলে এর কর্মক্ষমতা ব্যাপকভাবে কমে যায়। হোস্টে ফ্রি RAM উপস্থিত হওয়ার পরে বেলুনিং এবং কম্প্রেশনের চিহ্নগুলি দ্রুত অদৃশ্য হয়ে যায়, তবে ভার্চুয়াল মেশিনটি সোয়াপ থেকে সার্ভার র‌্যামে ফিরে আসার কোনও তাড়াহুড়ো করে না।
ESXi 6.0-এর আগে, Swap থেকে VM বের করার একমাত্র নির্ভরযোগ্য এবং দ্রুত উপায় ছিল রিবুট করা (আরো সুনির্দিষ্টভাবে, কন্টেইনার বন্ধ/চালু করা)। ESXi 6.0 দিয়ে শুরু করে, যদিও পুরোপুরি অফিসিয়াল নয়, Swap থেকে একটি VM সরানোর একটি কার্যকরী এবং নির্ভরযোগ্য উপায় উপস্থিত হয়েছে৷ একটি সম্মেলনে, আমি CPU শিডিউলারের দায়িত্বে থাকা VMware ইঞ্জিনিয়ারদের একজনের সাথে কথা বলতে সক্ষম হয়েছিলাম। তিনি নিশ্চিত করেছেন যে পদ্ধতিটি বেশ কার্যকর এবং নিরাপদ। আমাদের অভিজ্ঞতায়, এটির সাথে কোনও সমস্যা ছিল না।

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

ESXi মেমরি ম্যানেজমেন্ট টিপস

অবশেষে, এখানে কিছু টিপস রয়েছে যা আপনাকে RAM এর কারণে VM কর্মক্ষমতা নিয়ে সমস্যা এড়াতে সহায়তা করবে:

• উত্পাদনশীল ক্লাস্টারে মেমরি অতিরিক্ত সাবস্ক্রিপশন এড়িয়ে চলুন। ক্লাস্টারে সবসময় ~20-30% ফ্রি মেমরি থাকা বাঞ্ছনীয় যাতে DRS (এবং অ্যাডমিনিস্ট্রেটরের) কৌশলে কাজ করার জায়গা থাকে এবং মাইগ্রেশনের সময় VMগুলি অদলবদলে না যায়। এছাড়াও, ত্রুটি সহনশীলতার জন্য মার্জিন সম্পর্কে ভুলবেন না। এটি অপ্রীতিকর হয়, যখন একটি সার্ভার ব্যর্থ হয় এবং HA ব্যবহার করে VM পুনরায় বুট করা হয়, কিছু মেশিনও অদলবদলে চলে যায়।
• অত্যন্ত একত্রিত পরিকাঠামোতে, হোস্ট মেমরির অর্ধেকের বেশি দিয়ে VM তৈরি করার চেষ্টা করবেন না। এটি আবার DRS কে কোন সমস্যা ছাড়াই ক্লাস্টার সার্ভার জুড়ে ভার্চুয়াল মেশিন বিতরণ করতে সাহায্য করবে। এই নিয়ম, অবশ্যই, সর্বজনীন নয় :)।
• হোস্ট মেমরি ব্যবহার অ্যালার্ম জন্য দেখুন.
• VM-এ VMware টুল ইনস্টল করতে ভুলবেন না এবং বেলুনিং বন্ধ করবেন না।
• ইন্টার-ভিএম টিপিএস সক্ষম করার এবং ভিডিআই এবং পরীক্ষার পরিবেশে বড় পৃষ্ঠাগুলি নিষ্ক্রিয় করার কথা বিবেচনা করুন।
• যদি VM পারফরম্যান্স সমস্যার সম্মুখীন হয়, তাহলে এটি একটি দূরবর্তী NUMA নোড থেকে মেমরি ব্যবহার করছে কিনা তা পরীক্ষা করে দেখুন।
• যত তাড়াতাড়ি সম্ভব অদলবদল থেকে আপনার VM বের করুন! অন্যান্য জিনিসের মধ্যে, যদি VM অদলবদল হয়, সুস্পষ্ট কারণে, স্টোরেজ সিস্টেম ক্ষতিগ্রস্ত হয়।

এটা আমার জন্য RAM সম্পর্কে সব. যারা বিস্তারিত খনন করতে চান তাদের জন্য নীচে একটি সম্পর্কিত নিবন্ধ। পরবর্তী নিবন্ধ storadzh নিবেদিত করা হবে.

দরকারী লিঙ্কhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

উত্স: www.habr.com