VM მუშაობის ანალიზი VMware vSphere-ში. ნაწილი 2: მეხსიერება

ნაწილი 1. CPU-ს შესახებ

ამ სტატიაში ვისაუბრებთ vSphere-ში შემთხვევითი წვდომის მეხსიერების (RAM) შესრულების მრიცხველებზე.
როგორც ჩანს, მეხსიერებით ყველაფერი უფრო ნათელია, ვიდრე პროცესორთან: თუ VM-ზე მუშაობის პრობლემები წარმოიქმნება, ძნელია არ შეამჩნიო ისინი. მაგრამ თუ ისინი გამოჩნდებიან, ბევრად უფრო რთულია მათთან გამკლავება. მაგრამ პირველ რიგში.

ცოტა თეორია

ვირტუალური მანქანების ოპერატიული მეხსიერება აღებულია სერვერის მეხსიერებიდან, რომელზედაც მუშაობს VM-ები. ეს სავსებით აშკარაა :). თუ სერვერის ოპერატიული მეხსიერება ყველასთვის საკმარისი არ არის, ESXi იწყებს მეხსიერების მელიორაციის ტექნიკის გამოყენებას. წინააღმდეგ შემთხვევაში, VM ოპერაციული სისტემები დაიშლება RAM წვდომის შეცდომებით.

ESXi წყვეტს რომელი ტექნიკის გამოყენებას RAM-ის დატვირთვის მიხედვით:

მეხსიერების სტატუსი

საზღვრის

აქტიურობა

მაღალი

მინუს 400% უფასოა

ზედა ლიმიტის მიღწევის შემდეგ, დიდი მეხსიერების გვერდები იყოფა პატარებად (TPS მუშაობს სტანდარტულ რეჟიმში).

წმინდა

მინუს 100% უფასოა

დიდი მეხსიერების გვერდები იყოფა პატარებად, TPS იძულებულია.

რბილი

მინუს 64% უფასოა

TPS + Balloon

Hard

მინუს 32% უფასოა

TPS + შეკუმშვა + გაცვლა

დაბალი

მინუს 16% უფასოა

შეკუმშვა + გაცვლა + დაბლოკვა

წყარო

minFree არის ოპერატიული მეხსიერება, რომელიც საჭიროა ჰიპერვიზორის მუშაობისთვის.

ESXi 4.1-მდე ჩათვლით, minFree დაფიქსირდა ნაგულისხმევად - სერვერის ოპერატიული მეხსიერების 6% (პროცენტის შეცვლა შესაძლებელია ESXi-ზე Mem.MinFreePct ოფციის მეშვეობით). მოგვიანებით ვერსიებში, სერვერებზე მეხსიერების ზრდის გამო, minFree დაიწყო გამოთვლა ჰოსტის მეხსიერების ოდენობის საფუძველზე და არა როგორც ფიქსირებული პროცენტული მნიშვნელობა.

minFree მნიშვნელობა (ნაგულისხმევი) გამოითვლება შემდეგნაირად:

მეხსიერების პროცენტი დაცულია minFree-სთვის

მეხსიერების დიაპაზონი

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

დარჩენილი მეხსიერება

წყარო

მაგალითად, სერვერისთვის 128 GB ოპერატიული მეხსიერებით, MinFree მნიშვნელობა იქნება შემდეგი:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
რეალური მნიშვნელობა შეიძლება განსხვავდებოდეს რამდენიმე ასეული მბ-ით, რაც დამოკიდებულია სერვერზე და RAM-ზე.

მეხსიერების პროცენტი დაცულია minFree-სთვის

მეხსიერების დიაპაზონი

ღირებულება 128 GB

6%

0-4 GB

245,76 MB

4%

4-12 GB

327,68 MB

2%

12-28 GB

327,68 MB

1%

დარჩენილი მეხსიერება (100 GB)

1024 MB

როგორც წესი, პროდუქტიული სტენდებისთვის, მხოლოდ მაღალი მდგომარეობა შეიძლება ჩაითვალოს ნორმალურად. ტესტირებისა და განვითარების სკამებისთვის, Clear/Soft მდგომარეობები შეიძლება იყოს მისაღები. თუ ჰოსტზე ოპერატიული მეხსიერება 64%-ზე ნაკლებია MinFree, მაშინ მასზე მომუშავე VM-ებს ნამდვილად აქვთ მუშაობის პრობლემები.

თითოეულ სახელმწიფოში გამოიყენება მეხსიერების აღდგენის გარკვეული ტექნიკა, დაწყებული TPS-დან, რომელიც პრაქტიკულად არანაირ გავლენას არ ახდენს VM მუშაობაზე, Swapping-მდე. მათ შესახებ უფრო მეტს გეტყვით.

გვერდის გამჭვირვალე გაზიარება (TPS). TPS არის, უხეშად რომ ვთქვათ, სერვერზე ვირტუალური მანქანების RAM გვერდების დუბლირება.

ESXi ეძებს იდენტური ვირტუალური მანქანის ოპერატიული მეხსიერების გვერდებს გვერდების ჰეშის ჯამის დათვლით და შედარების გზით და შლის დუბლიკატ გვერდებს, ანაცვლებს მათ სერვერის ფიზიკურ მეხსიერებაში იმავე გვერდის მითითებით. შედეგად, ფიზიკური მეხსიერების მოხმარება მცირდება და მეხსიერების ჭარბი გამოწერა შეიძლება მიღწეული იყოს ეფექტურობის გავლენის გარეშე.

წყარო

ეს მექანიზმი მუშაობს მხოლოდ 4 KB ზომის მეხსიერების გვერდებზე (პატარა გვერდებზე). ჰიპერვიზორი არც კი ცდილობს 2 მბ ზომის გვერდების დუბლიკატს (დიდი გვერდები): ამ ზომის იდენტური გვერდების პოვნის შანსი დიდი არ არის.

ნაგულისხმევად, ESXi გამოყოფს მეხსიერებას დიდ გვერდებზე. დიდი გვერდების დაყოფა პატარა გვერდებად იწყება, როდესაც მიიღწევა მაღალი მდგომარეობის ბარიერი და იძულებულია, როდესაც მიიღწევა Clear მდგომარეობა (იხ. ჰიპერვიზორის მდგომარეობის ცხრილი).

თუ გსურთ, რომ TPS-მა დაიწყოს მუშაობა ჰოსტის RAM-ის შევსების მოლოდინის გარეშე, თქვენ უნდა დააყენოთ მნიშვნელობა Advanced Options ESXi-ში. "Mem.AllocGuestLargePage" 0-მდე (ნაგულისხმევი 1). შემდეგ ვირტუალური მანქანებისთვის დიდი მეხსიერების გვერდების გამოყოფა გამორთული იქნება.

2014 წლის დეკემბრიდან, ყველა ESXi გამოშვებაში, TPS VM-ებს შორის ნაგულისხმევად გამორთულია, რადგან აღმოჩნდა დაუცველობა, რომელიც თეორიულად საშუალებას აძლევს ერთ VM-ს წვდომა იყოს სხვა VM-ის RAM-ზე. დეტალები აქ. მე არ შემხვედრია ინფორმაცია TPS დაუცველობის გამოყენების პრაქტიკული განხორციელების შესახებ.

TPS პოლიტიკა კონტროლდება გაფართოებული ვარიანტის მეშვეობით "Mem.ShareForceSalting" ESXi-ზე:
0 - Inter-VM TPS. TPS მუშაობს სხვადასხვა VM-ების გვერდებზე;
1 – TPS VM-ებისთვის იგივე „sched.mem.pshare.salt“ მნიშვნელობით VMX-ში;
2 (ნაგულისხმევი) – Intra-VM TPS. TPS მუშაობს გვერდებზე VM-ში.

ნამდვილად აზრი აქვს დიდი გვერდების გამორთვას და Inter-VM TPS-ის ჩართვას სატესტო სკამებზე. ეს ასევე შეიძლება გამოყენებულ იქნას სტენდებისთვის დიდი რაოდენობით მსგავსი VM-ებით. მაგალითად, სტენდებზე VDI-ით, ფიზიკურ მეხსიერებაში დაზოგვამ შეიძლება მიაღწიოს ათეულ პროცენტს.

მეხსიერების ბურთით გაფრენა. Balooning აღარ არის ისეთი უვნებელი და გამჭვირვალე ტექნიკა VM ოპერაციული სისტემისთვის, როგორც TPS. მაგრამ თუ სწორად გამოიყენებთ, შეგიძლიათ იცხოვროთ და იმუშაოთ Balloning-ით.

Vmware Tools-თან ერთად VM-ზე დამონტაჟებულია სპეციალური დრაივერი, სახელწოდებით Balloon Driver (aka vmmemctl). როდესაც ჰიპერვიზორი იწყებს ფიზიკური მეხსიერების ამოწურვას და შედის Soft მდგომარეობაში, ESXi სთხოვს VM-ს გამოუყენებელი ოპერატიული მეხსიერების აღდგენა ამ Balloon Driver-ის მეშვეობით. დრაივერი, თავის მხრივ, მუშაობს ოპერაციული სისტემის დონეზე და ითხოვს მისგან თავისუფალ მეხსიერებას. ჰიპერვიზორი ხედავს ფიზიკური მეხსიერების რომელ გვერდებს აქვს დაკავებული Balloon Driver, იღებს მეხსიერებას ვირტუალური მანქანიდან და უბრუნებს მას ჰოსტს. OS-ის მუშაობასთან დაკავშირებით არანაირი პრობლემა არ არის, რადგან OS დონეზე მეხსიერება ოკუპირებულია Balloon Driver-ის მიერ. ნაგულისხმევად, Balloon Driver-ს შეუძლია დაიკავოს VM მეხსიერების 65%-მდე.

თუ VMware Tools არ არის დაინსტალირებული VM-ზე ან Balloning გამორთულია (მე ამას არ გირჩევთ, მაგრამ არის KB:), ჰიპერვიზორი დაუყოვნებლივ გადადის მეხსიერების მოხსნის უფრო მკაცრ ტექნიკაზე. დასკვნა: დარწმუნდით, რომ VMware Tools არის VM-ზე.

Balloon Driver-ის მუშაობის შემოწმება შესაძლებელია OS-დან VMware Tools-ის საშუალებით.

მეხსიერების შეკუმშვა. ეს ტექნიკა გამოიყენება, როდესაც ESXi აღწევს მძიმე მდგომარეობას. როგორც სახელი გვთავაზობს, ESXi ცდილობს შეკუმშოს ოპერატიული მეხსიერების 4KB გვერდი 2KB-ში, რითაც ათავისუფლებს გარკვეულ ადგილს სერვერის ფიზიკურ მეხსიერებაში. ეს ტექნიკა მნიშვნელოვნად ზრდის VM RAM გვერდების შინაარსზე წვდომის დროს, რადგან გვერდი ჯერ უნდა იყოს დეკომპრესიული. ზოგჯერ ყველა გვერდის შეკუმშვა შეუძლებელია და თავად პროცესს გარკვეული დრო სჭირდება. ამიტომ, ეს ტექნიკა პრაქტიკაში არც თუ ისე ეფექტურია.

მეხსიერების გაცვლა. მეხსიერების შეკუმშვის ხანმოკლე ფაზის შემდეგ, ESXi თითქმის გარდაუვლად (თუ VM არ გადავიდა სხვა ჰოსტებზე ან არ არის გამორთული) გადადის Swapping-ზე. და თუ დარჩა ძალიან ცოტა მეხსიერება (დაბალი მდგომარეობა), მაშინ ჰიპერვიზორი ასევე წყვეტს მეხსიერების გვერდების გამოყოფას VM-ზე, რამაც შეიძლება გამოიწვიოს პრობლემები VM-ის სტუმრის OS-ში.

ასე მუშაობს Swapping. როდესაც ჩართავთ ვირტუალურ მანქანას, მისთვის იქმნება ფაილი .vswp გაფართოებით. ის ზომით უდრის VM-ის არარეზერვირებული ოპერატიული მეხსიერების: ეს არის განსხვავება კონფიგურირებულ და რეზერვირებულ მეხსიერებას შორის. როდესაც Swapping მუშაობს, ESXi ცვლის ვირტუალური მანქანის მეხსიერების გვერდებს ამ ფაილში და იწყებს მასთან მუშაობას სერვერის ფიზიკური მეხსიერების ნაცვლად. რა თქმა უნდა, ასეთი "RAM" მეხსიერება რამდენიმე რიგით ნელია ვიდრე რეალურ მეხსიერებაში, მაშინაც კი, თუ .vswp არის სწრაფ შენახვაზე.

Balooning-ისგან განსხვავებით, როდესაც გამოუყენებელი გვერდები აღებულია VM-დან, Swapping გვერდები, რომლებსაც აქტიურად იყენებენ OS ან VM-ის შიგნით არსებული აპლიკაციები, შეიძლება გადავიდეს დისკზე. შედეგად, VM-ის შესრულება იკლებს გაყინვამდე. VM ფორმალურად მუშაობს და, მინიმუმ, შეიძლება სწორად გამორთოთ OS-დან. თუ მოთმინება გაქვთ 😉

თუ VM-ები წავიდნენ Swap-ზე, ეს არის გადაუდებელი სიტუაცია, რომლის თავიდან აცილება უმჯობესია, თუ ეს შესაძლებელია.

ძირითადი ვირტუალური მანქანების მეხსიერების მუშაობის მრიცხველები

ასე რომ მივედით მთავარზე. VM-ის მეხსიერების მდგომარეობის მონიტორინგისთვის არის შემდეგი მრიცხველები:

აქტიური — აჩვენებს ოპერატიული მეხსიერების რაოდენობას (KB), რომელზედაც წვდომა იყო VM წინა გაზომვის პერიოდში.

გამოყენება - იგივეა რაც აქტიური, მაგრამ VM-ის კონფიგურირებული ოპერატიული მეხსიერების პროცენტულად. გამოითვლება შემდეგი ფორმულის გამოყენებით: აქტიური ÷ ვირტუალური მანქანის კონფიგურირებული მეხსიერების ზომა.
მაღალი გამოყენება და აქტიური, შესაბამისად, ყოველთვის არ არის VM მუშაობის პრობლემების მაჩვენებელი. თუ VM აგრესიულად იყენებს მეხსიერებას (ყოველ შემთხვევაში, მასზე წვდომა აქვს), ეს არ ნიშნავს, რომ მეხსიერება არ არის საკმარისი. პირიქით, ეს არის მიზეზი, რომ გადავხედოთ რა ხდება OS-ში.
არსებობს სტანდარტული სიგნალიზაცია მეხსიერების გამოყენებისთვის VM-ებისთვის:

გაიზიარა - VM ოპერატიული მეხსიერების რაოდენობა, რომელიც ამოღებულია TPS-ის გამოყენებით (VM-ში ან VM-ებს შორის).

გაცემული - ჰოსტის ფიზიკური მეხსიერების რაოდენობა (KB), რომელიც გამოყოფილი იყო VM-ზე. რთავს გაზიარებას.

მოხმარებული (Granted - Shared) - ფიზიკური მეხსიერების რაოდენობა (KB), რომელსაც VM მოიხმარს ჰოსტისგან. არ შეიცავს გაზიარებულს.

თუ VM მეხსიერების ნაწილი მოცემულია არა ჰოსტის ფიზიკური მეხსიერებიდან, არამედ სვოპ ფაილიდან, ან მეხსიერება აღებულია VM-დან Balloon Driver-ის მეშვეობით, ეს თანხა არ არის გათვალისწინებული გაცემული და მოხმარებული.
მაღალი მინიჭებული და მოხმარებული ღირებულებები სრულიად ნორმალურია. ოპერაციული სისტემა თანდათან იღებს მეხსიერებას ჰიპერვიზორისგან და არ აბრუნებს მას. დროთა განმავლობაში, აქტიურად გაშვებულ VM-ში, ამ მრიცხველების მნიშვნელობები უახლოვდება კონფიგურირებული მეხსიერების რაოდენობას და რჩება იქ.

Zero — VM RAM-ის რაოდენობა (KB), რომელიც შეიცავს ნულებს. ასეთი მეხსიერება ჰიპერვიზორის მიერ განიხილება თავისუფლად და შეიძლება მიეცეს სხვა ვირტუალურ მანქანებს. მას შემდეგ, რაც სტუმარი OS დაწერს რაიმეს ნულოვან მეხსიერებაში, ის გადადის Consumed-ში და არ ბრუნდება უკან.

რეზერვირებული ზედნადები — VM RAM-ის ოდენობა, (KB) ჰიპერვიზორის მიერ რეზერვირებული VM ოპერაციისთვის. ეს მცირე თანხაა, მაგრამ ის ხელმისაწვდომი უნდა იყოს ჰოსტზე, წინააღმდეგ შემთხვევაში VM არ დაიწყება.

Balloon — ოპერატიული მეხსიერების რაოდენობა (KB) ამოღებული VM-დან Balloon Driver-ის გამოყენებით.

შეკუმშული - შეკუმშული ოპერატიული მეხსიერების რაოდენობა (KB).

გადაცვალეს — ოპერატიული მეხსიერების რაოდენობა (KB), რომელიც სერვერზე ფიზიკური მეხსიერების ნაკლებობის გამო გადავიდა დისკზე.
ბუშტებისა და მეხსიერების აღდგენის სხვა ტექნიკის მრიცხველები ნულის ტოლია.

ასე გამოიყურება გრაფიკი ნორმალურად მომუშავე VM-ის მეხსიერების მრიცხველებით 150 GB ოპერატიული მეხსიერებით.

ქვემოთ მოცემულ გრაფიკში VM-ს აშკარა პრობლემები აქვს. გრაფიკის ქვემოთ ხედავთ, რომ ამ VM-სთვის გამოყენებულია RAM-თან მუშაობის ყველა აღწერილი ტექნიკა. ბუშტი ამ VM-ისთვის გაცილებით დიდია ვიდრე მოხმარებული. სინამდვილეში, VM უფრო მკვდარია, ვიდრე ცოცხალი.

ESXTOP

როგორც CPU-ს შემთხვევაში, თუ გვსურს სწრაფად შევაფასოთ სიტუაცია ჰოსტზე, ისევე როგორც მისი დინამიკა 2 წამამდე ინტერვალით, უნდა გამოვიყენოთ ESXTOP.

ESXTOP მეხსიერების ეკრანი გამოიძახება "m" ღილაკით და ასე გამოიყურება (არჩეულია ველები B,D,H,J,K,L,O):

ჩვენთვის საინტერესო იქნება შემდეგი პარამეტრები:

Mem overcommit საშ — მეხსიერების გადაჭარბებული გამოწერის საშუალო მნიშვნელობა ჰოსტზე 1, 5 და 15 წუთის განმავლობაში. თუ ის ნულზე მაღლა დგას, მაშინ ეს არის იმის მიზეზი, რომ გადავხედოთ რა ხდება, მაგრამ არა ყოველთვის პრობლემების მაჩვენებელი.

ხაზებში PMEM/MB и VMKMEM/MB — ინფორმაცია სერვერის ფიზიკური მეხსიერების და VMkernel-ისთვის ხელმისაწვდომი მეხსიერების შესახებ. აქ საინტერესო ნივთებს შორის შეგიძლიათ ნახოთ minfree მნიშვნელობა (MB-ში), მასპინძელი მდგომარეობა მეხსიერებაში (ჩვენს შემთხვევაში მაღალი).

Ხაზში NUMA/MB თქვენ შეგიძლიათ ნახოთ RAM-ის განაწილება NUMA კვანძებში (სოკეტებში). ამ მაგალითში განაწილება არათანაბარია, რაც პრინციპში არც თუ ისე კარგია.

ქვემოთ მოცემულია სერვერის ზოგადი სტატისტიკა მეხსიერების აღდგენის ტექნიკისთვის:

PSHARE/MB — ეს არის TPS სტატისტიკა;

SWAP/MB — სვოპ გამოყენების სტატისტიკა;

ZIP/MB — მეხსიერების გვერდის შეკუმშვის სტატისტიკა;

MEMCTL/MB — Balloon Driver-ის გამოყენების სტატისტიკა.

ინდივიდუალური VM-ებისთვის შეიძლება დავინტერესდეთ შემდეგი ინფორმაცია. ვიმ-ების სახელები დავმალე, რომ მაყურებელი არ დაბნეულიყო :). თუ ESXTOP მეტრიკა მსგავსია vSphere-ის მრიცხველის, მე მივაწოდებ შესაბამის მრიცხველს.

MEMSZ - VM-ზე კონფიგურირებული მეხსიერების რაოდენობა (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + ხელუხლებელი.

გრანტი - მინიჭებული MB-ში.

TCHD — აქტიურია MByte-ში.

MCTL? — დამონტაჟებულია თუ არა Balloon Driver VM-ზე.

MCTLSZ — ბუშტი MB-მდე.

MCTLGT — ოპერატიული მეხსიერების რაოდენობა (MBytes), რომელიც ESXi-ს სურს ამოიღოს VM-დან Balloon Driver-ის მეშვეობით (Memctl Target).

MCTLMAX - ოპერატიული მეხსიერების მაქსიმალური რაოდენობა (მბაიტი), რომელიც ESXi-ს შეუძლია ამოიღოს VM-დან Balloon Driver-ის მეშვეობით.

SWCUR — Swap ფაილიდან VM-ისთვის გამოყოფილი ოპერატიული მეხსიერების მიმდინარე რაოდენობა (MBytes).

S.W.G.T. — ოპერატიული მეხსიერების რაოდენობა (მბაიტი), რომელიც ESXi-ს სურს გადასცეს VM-ს Swap ფაილიდან (Swap Target).

თქვენ ასევე შეგიძლიათ ნახოთ უფრო დეტალური ინფორმაცია VM-ის NUMA ტოპოლოგიის შესახებ ESXTOP-ის საშუალებით. ამისათვის აირჩიეთ ველები D, G:

ᲞᲐᲢᲐᲠᲐ – NUMA კვანძი, რომელზედაც მდებარეობს VM. აქ შეგიძლიათ დაუყოვნებლივ შეამჩნიოთ ფართო vm, რომელიც არ ჯდება ერთ NUMA კვანძზე.

NRMEM - რამდენ მეგაბაიტს იღებს VM დისტანციური NUMA კვანძიდან.

NLMEM - რამდენ მეგაბაიტს იღებს VM ადგილობრივი NUMA კვანძიდან.

N%L – VM მეხსიერების პროცენტი ადგილობრივ NUMA კვანძზე (თუ 80%-ზე ნაკლებია, შეიძლება წარმოიშვას მუშაობის პრობლემები).

მეხსიერება ჰიპერვიზორზე

თუ ჰიპერვიზორის CPU მრიცხველები, როგორც წესი, არ არის განსაკუთრებული ინტერესი, მაშინ მეხსიერების შემთხვევაში სიტუაცია საპირისპიროა. მეხსიერების მაღალი გამოყენება VM-ზე ყოველთვის არ მიუთითებს მუშაობის პრობლემაზე, მაგრამ მეხსიერების მაღალი გამოყენება ჰიპერვიზორზე იწვევს მეხსიერების მართვის ტექნიკას და იწვევს VM-ის მუშაობასთან დაკავშირებულ პრობლემებს. თქვენ უნდა აკონტროლოთ მასპინძელი მეხსიერების გამოყენების სიგნალიზაცია და თავიდან აიცილოთ VM-ები Swap-ში მოხვედრისგან.

გაცვლა

თუ VM დაიჭირეს Swap-ში, მისი შესრულება მნიშვნელოვნად შემცირდება. Balloning და შეკუმშვის კვალი სწრაფად ქრება მას შემდეგ, რაც უფასო ოპერატიული მეხსიერება გამოჩნდება ჰოსტზე, მაგრამ ვირტუალური მანქანა არ ჩქარობს Swap-დან სერვერის RAM-ში დაბრუნებას.
ESXi 6.0-მდე VM-ის Swap-დან ამოღების ერთადერთი საიმედო და სწრაფი გზა იყო გადატვირთვა (უფრო ზუსტად, კონტეინერის გამორთვა/ჩართვა). ESXi 6.0-დან დაწყებული, თუმცა არა მთლად ოფიციალური, გამოჩნდა VM-ის Swap-დან ამოღების სამუშაო და საიმედო გზა. ერთ-ერთ კონფერენციაზე მე შევძელი საუბარი VMware-ის ერთ-ერთ ინჟინერთან, რომელიც პასუხისმგებელია CPU Scheduler-ზე. მან დაადასტურა, რომ მეთოდი საკმაოდ ეფექტური და უსაფრთხოა. ჩვენი გამოცდილებით, არც მასში იყო პრობლემები.

რეალური ბრძანებები VM-ის Swap-დან ამოღებისთვის აღწერილი დუნკან ეპინგი. მე არ გავიმეორებ დეტალურ აღწერას, მე უბრალოდ მივცემ მისი გამოყენების მაგალითს. როგორც სკრინშოტზე ხედავთ, მითითებული ბრძანების შესრულებიდან გარკვეული პერიოდის შემდეგ, VM-ზე Swap ქრება.

რჩევები ESXi-ზე RAM-ის მართვისთვის

დაბოლოს, აქ არის რამდენიმე რჩევა, რომელიც დაგეხმარებათ თავიდან აიცილოთ პრობლემები VM-ის მუშაობასთან დაკავშირებით RAM-ის გამო:

• მოერიდეთ RAM-ის ზედმეტ გამოწერას პროდუქტიულ კლასტერებში. მიზანშეწონილია ყოველთვის გქონდეთ კლასტერში თავისუფალი მეხსიერების ~20-30%, რათა DRS-ს (და ადმინისტრატორს) ჰქონდეს მანევრირების ადგილი და VM-ები არ გადავიდნენ Swap-ზე მიგრაციის დროს. ასევე, არ დაივიწყოთ ხარვეზების ტოლერანტობის ზღვარი. არასასიამოვნოა, როდესაც, როდესაც ერთი სერვერი იშლება და VM გადაიტვირთება HA-ს გამოყენებით, ზოგიერთი მანქანა ასევე მიდის Swap-ზე.
• უაღრესად კონსოლიდირებულ ინფრასტრუქტურებში, ეცადეთ, არ შექმნათ VM-ები, რომელთა მეხსიერების ნახევარზე მეტი მასპინძელი მეხსიერებაა. ეს კვლავ დაეხმარება DRS-ს, უპრობლემოდ გაანაწილოს ვირტუალური მანქანები კლასტერულ სერვერებზე. ეს წესი, რა თქმა უნდა, არ არის უნივერსალური :).
• გაუფრთხილდით მასპინძლის მეხსიერების გამოყენების სიგნალიზაციას.
• არ დაგავიწყდეთ VMware Tools-ის დაყენება VM-ზე და არ გამორთოთ Balooning.
• განვიხილოთ Inter-VM TPS-ის ჩართვა და დიდი გვერდების გამორთვა VDI-სა და სატესტო გარემოში.
• თუ VM-ს აქვს მუშაობის პრობლემები, შეამოწმეთ იყენებს თუ არა ის მეხსიერებას დისტანციური NUMA კვანძიდან.
• რაც შეიძლება სწრაფად ამოიღეთ VM-ები Swap-დან! სხვა საკითხებთან ერთად, თუ VM არის Swap-ში, შენახვის სისტემა ზარალდება აშკარა მიზეზების გამო.

ეს ყველაფერია ჩემთვის რაც შეეხება RAM-ს. ქვემოთ მოცემულია დაკავშირებული სტატიები მათთვის, ვისაც სურს უფრო ღრმად ჩასვლა. შემდეგი სტატია დაეთმობა storaj-ს.

სასარგებლო ბმულები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