ການວິເຄາະປະສິດທິພາບ VM ໃນ VMware vSphere. ສ່ວນທີ 2: ຄວາມຈໍາ

ສ່ວນທີ 1. ກ່ຽວກັບ CPU

ໃນບົດຄວາມນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບຕົວນັບການປະຕິບັດຫນ່ວຍຄວາມຈໍາການເຂົ້າເຖິງແບບສຸ່ມ (RAM) ໃນ vSphere.
ມັນເບິ່ງຄືວ່າກັບຫນ່ວຍຄວາມຈໍາທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງກວ່າກັບໂປເຊດເຊີ: ຖ້າບັນຫາການປະຕິບັດເກີດຂື້ນໃນ VM, ມັນຍາກທີ່ຈະບໍ່ສັງເກດເຫັນພວກມັນ. ແຕ່ຖ້າພວກເຂົາປາກົດ, ມັນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະຈັດການກັບພວກມັນ. ແຕ່ສິ່ງທໍາອິດທໍາອິດ.

ບິດຂອງທິດສະດີ

RAM ຂອງເຄື່ອງ virtual ແມ່ນເອົາມາຈາກຫນ່ວຍຄວາມຈໍາຂອງເຄື່ອງແມ່ຂ່າຍທີ່ VMs ກໍາລັງແລ່ນ. ນີ້ແມ່ນຂ້ອນຂ້າງຈະແຈ້ງ :). ຖ້າ RAM ຂອງເຄື່ອງແມ່ຂ່າຍບໍ່ພຽງພໍສໍາລັບທຸກຄົນ, ESXi ເລີ່ມໃຊ້ເຕັກນິກການລວບລວມຫນ່ວຍຄວາມຈໍາ. ຖ້າບໍ່ດັ່ງນັ້ນ, ລະບົບປະຕິບັດການ VM ຈະຂັດຂ້ອງກັບຄວາມຜິດພາດໃນການເຂົ້າເຖິງ RAM.

ESXi ຕັດສິນໃຈວ່າຈະໃຊ້ເຕັກນິກໃດຂຶ້ນກັບການໂຫຼດ RAM:

ສະຖານະຄວາມຈໍາ

ຊາຍແດນ

ການກະທໍາ

ສູງ

400% ຂອງ minFree

ຫຼັງຈາກເຖິງຂອບເຂດຈໍາກັດເທິງ, ຫນ້າຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່ຖືກແບ່ງອອກເປັນຂະຫນາດນ້ອຍ (TPS ດໍາເນີນການໃນຮູບແບບມາດຕະຖານ).

ຈະແຈ້ງ

100% ຂອງ minFree

ຫນ້າຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່ຖືກແບ່ງອອກເປັນຂະຫນາດນ້ອຍ, TPS ຖືກບັງຄັບ.

ຄີອ່ອນ

64% ຂອງ minFree

TPS + ປູມເປົ້າ

Hard

32% ຂອງ minFree

TPS + ບີບອັດ + ສະຫຼັບ

ຕ່ໍາ

16% ຂອງ minFree

ບີບອັດ + ສະຫຼັບ + ບລັອກ

ແຫຼ່ງຂໍ້ມູນ

minFree ແມ່ນ RAM ທີ່ຕ້ອງການສໍາລັບ hypervisor ເພື່ອດໍາເນີນການ.

ເຖິງ ESXi 4.1 ລວມ, minFree ໄດ້ຖືກແກ້ໄຂໂດຍຄ່າເລີ່ມຕົ້ນ - 6% ຂອງ RAM ຂອງເຄື່ອງແມ່ຂ່າຍ (ອັດຕາສ່ວນສາມາດປ່ຽນແປງໄດ້ຜ່ານທາງເລືອກ Mem.MinFreePct ໃນ ESXi). ໃນຮຸ່ນຕໍ່ມາ, ເນື່ອງຈາກການຂະຫຍາຍຕົວຂອງຫນ່ວຍຄວາມຈໍາໃນເຄື່ອງແມ່ຂ່າຍ, minFree ໄດ້ເລີ່ມຕົ້ນທີ່ຈະຄິດໄລ່ໂດຍອີງໃສ່ຈໍານວນຫນ່ວຍຄວາມຈໍາຂອງເຈົ້າພາບ, ແລະບໍ່ແມ່ນຄ່າອັດຕາສ່ວນຄົງທີ່.

ຄ່າ minFree (ຄ່າເລີ່ມຕົ້ນ) ຖືກຄິດໄລ່ດັ່ງນີ້:

ເປີເຊັນຂອງຄວາມຊົງຈໍາທີ່ສະຫງວນໄວ້ສໍາລັບ minFree

ຊ່ວງຄວາມຈຳ

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

ຄວາມຊົງຈໍາທີ່ຍັງເຫຼືອ

ແຫຼ່ງຂໍ້ມູນ

ສໍາລັບຕົວຢ່າງ, ສໍາລັບເຄື່ອງແມ່ຂ່າຍທີ່ມີ 128 GB ຂອງ RAM, ຄ່າ MinFree ຈະເປັນດັ່ງຕໍ່ໄປນີ້:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
ມູນຄ່າຕົວຈິງອາດຈະແຕກຕ່າງກັນສອງສາມຮ້ອຍ MB, ຂຶ້ນກັບເຄື່ອງແມ່ຂ່າຍແລະ 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

ໂດຍປົກກະຕິ, ສໍາລັບຜະລິດຕະພັນທີ່ຢືນຢູ່, ພຽງແຕ່ລັດສູງສາມາດຖືວ່າເປັນເລື່ອງປົກກະຕິ. ສໍາລັບການທົດສອບແລະການພັດທະນາ benches, Clear / Soft states ອາດຈະຍອມຮັບໄດ້. ຖ້າ RAM ໃນໂຮດມີຫນ້ອຍກວ່າ 64% MinFree, ຫຼັງຈາກນັ້ນ VMs ທີ່ແລ່ນຢູ່ເທິງມັນແນ່ນອນປະສົບບັນຫາການປະຕິບັດ.

ໃນແຕ່ລະລັດ, ເຕັກນິກການເກັບຄືນຄວາມຊົງຈໍາບາງຢ່າງແມ່ນຖືກນໍາໃຊ້, ເລີ່ມຕົ້ນຈາກ TPS, ເຊິ່ງເກືອບບໍ່ມີຜົນຕໍ່ການປະຕິບັດຂອງ VM, ໄປຫາ Swapping. ຂ້ອຍຈະບອກເຈົ້າເພີ່ມເຕີມກ່ຽວກັບພວກມັນ.

ການແບ່ງປັນໜ້າໂປ່ງໃສ (TPS). TPS ແມ່ນ, ເວົ້າປະມານ, ການຊໍ້າຊ້ອນຂອງຫນ້າ RAM ຂອງເຄື່ອງຈັກ virtual ໃນເຄື່ອງແມ່ຂ່າຍ.

ESXi ຄົ້ນຫາຫນ້າ RAM ຂອງເຄື່ອງ virtual ທີ່ຄ້າຍຄືກັນໂດຍການນັບແລະການປຽບທຽບ hash sum ຂອງຫນ້າ, ແລະເອົາຫນ້າທີ່ຊ້ໍາກັນ, ແທນທີ່ພວກມັນດ້ວຍການອ້າງອີງເຖິງຫນ້າດຽວກັນໃນຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍຂອງເຄື່ອງແມ່ຂ່າຍ. ດັ່ງນັ້ນ, ການບໍລິໂພກຄວາມຊົງຈໍາທາງກາຍະພາບແມ່ນຫຼຸດລົງແລະການຈອງຫນ່ວຍຄວາມຈໍາຫຼາຍເກີນໄປສາມາດບັນລຸໄດ້ໂດຍເກືອບບໍ່ມີຜົນກະທົບດ້ານການປະຕິບັດ.

ແຫຼ່ງຂໍ້ມູນ

ກົນໄກນີ້ເຮັດວຽກພຽງແຕ່ສໍາລັບຫນ້າຫນ່ວຍຄວາມຈໍາຂອງ 4 KB ໃນຂະຫນາດ (ຫນ້າຂະຫນາດນ້ອຍ). hypervisor ບໍ່ໄດ້ພະຍາຍາມແຍກຫນ້າທີ່ມີຂະຫນາດ 2 MB (ຫນ້າຂະຫນາດໃຫຍ່): ໂອກາດທີ່ຈະຊອກຫາຫນ້າດຽວກັນຂອງຂະຫນາດນີ້ແມ່ນບໍ່ຍິ່ງໃຫຍ່.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ESXi ຈັດສັນຫນ່ວຍຄວາມຈໍາໃຫ້ກັບຫນ້າຂະຫນາດໃຫຍ່. ການແບ່ງໜ້າໃຫຍ່ອອກເປັນໜ້ານ້ອຍໆເລີ່ມຕົ້ນເມື່ອຮອດເກນສະຖານະສູງ ແລະຖືກບັງຄັບເມື່ອເຖິງສະຖານະ Clear (ເບິ່ງຕາຕະລາງລັດ hypervisor).

ຖ້າທ່ານຕ້ອງການ TPS ເລີ່ມຕົ້ນເຮັດວຽກໂດຍບໍ່ຕ້ອງລໍຖ້າ RAM ຂອງເຈົ້າພາບເຕັມ, ທ່ານຈໍາເປັນຕ້ອງກໍານົດຄ່າໃນ Advanced Options ESXi. “Mem.AllocGuestLargePage” ເຖິງ 0 (ຄ່າເລີ່ມຕົ້ນ 1). ຫຼັງຈາກນັ້ນ, ການຈັດສັນຫນ້າຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່ສໍາລັບເຄື່ອງ virtual ຈະຖືກປິດໃຊ້ງານ.

ນັບຕັ້ງແຕ່ເດືອນທັນວາ 2014, ໃນການປ່ອຍ ESXi ທັງຫມົດ, TPS ລະຫວ່າງ VMs ຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ, ເນື່ອງຈາກຄວາມອ່ອນແອທີ່ພົບເຫັນວ່າທາງທິດສະດີອະນຸຍາດໃຫ້ VM ຫນຶ່ງເຂົ້າເຖິງ RAM ຂອງ VM ອື່ນ. ລາຍລະອຽດຢູ່ທີ່ນີ້. ຂ້າພະເຈົ້າບໍ່ໄດ້ພົບເຫັນຂໍ້ມູນກ່ຽວກັບການປະຕິບັດຕົວຈິງຂອງການຂຸດຄົ້ນຄວາມອ່ອນແອຂອງ TPS.

ນະໂຍບາຍ TPS ຖືກຄວບຄຸມຜ່ານທາງເລືອກຂັ້ນສູງ “Mem.ShareForceSalting” ໃນ ESXi:
0 - Inter-VM TPS. TPS ເຮັດວຽກສໍາລັບຫນ້າຂອງ VMs ທີ່ແຕກຕ່າງກັນ;
1 – TPS ສໍາລັບ VMs ທີ່ມີຄ່າ “sched.mem.pshare.salt” ດຽວກັນໃນ VMX;
2 (ຄ່າເລີ່ມຕົ້ນ) – Intra-VM TPS. TPS ເຮັດວຽກສໍາລັບຫນ້າພາຍໃນ VM.

ມັນແນ່ນອນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະປິດການທໍາງານຂອງຫນ້າເວັບຂະຫນາດໃຫຍ່ແລະເປີດໃຊ້ Inter-VM TPS ຢູ່ໃນບ່ອນນັ່ງທົດສອບ. ນີ້ຍັງສາມາດຖືກນໍາໃຊ້ສໍາລັບການຢືນທີ່ມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງ VMs ທີ່ຄ້າຍຄືກັນ. ສໍາລັບຕົວຢ່າງ, ກ່ຽວກັບການຢືນຢູ່ກັບ VDI, ເງິນຝາກປະຢັດໃນຄວາມຊົງຈໍາທາງດ້ານຮ່າງກາຍສາມາດບັນລຸສິບເປີເຊັນ.

ປູມເປົ້າຄວາມຊົງຈໍາ. ປູມເປົ້າບໍ່ແມ່ນເຕັກນິກທີ່ບໍ່ເປັນອັນຕະລາຍ ແລະໂປ່ງໃສສຳລັບລະບົບປະຕິບັດການ VM ເປັນ TPS ອີກຕໍ່ໄປ. ແຕ່ຖ້າຖືກນໍາໃຊ້ຢ່າງຖືກຕ້ອງ, ທ່ານສາມາດດໍາລົງຊີວິດແລະແມ້ກະທັ້ງເຮັດວຽກກັບ Ballooning.

ຮ່ວມກັນກັບ Vmware Tools, ໄດເວີພິເສດທີ່ເອີ້ນວ່າ Balloon Driver (aka vmmemctl) ຖືກຕິດຕັ້ງຢູ່ໃນ VM. ເມື່ອ hypervisor ເລີ່ມຕົ້ນຫມົດຄວາມຊົງຈໍາທາງກາຍະພາບແລະເຂົ້າສູ່ສະຖານະ Soft, ESXi ຂໍໃຫ້ VM ຖອນຄືນ RAM ທີ່ບໍ່ໄດ້ໃຊ້ໂດຍຜ່ານ Balloon Driver ນີ້. ໄດເວີ, ໃນທາງກັບກັນ, ເຮັດວຽກຢູ່ໃນລະດັບລະບົບປະຕິບັດການແລະຮ້ອງຂໍຄວາມຈໍາຟຣີຈາກມັນ. hypervisor ເບິ່ງວ່າຫນ້າໃດຂອງຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍທີ່ Balloon Driver ໄດ້ຄອບຄອງ, ເອົາຫນ່ວຍຄວາມຈໍາຈາກ virtual machine ແລະສົ່ງຄືນໃຫ້ເຈົ້າພາບ. ບໍ່ມີບັນຫາກັບການເຮັດວຽກຂອງ OS, ເພາະວ່າໃນລະດັບ OS ຫນ່ວຍຄວາມຈໍາຖືກຄອບຄອງໂດຍ Balloon Driver. ໂດຍຄ່າເລີ່ມຕົ້ນ, Balloon Driver ສາມາດເອົາເຖິງ 65% ຂອງຫນ່ວຍຄວາມຈໍາ VM.

ຖ້າ VMware Tools ບໍ່ໄດ້ຕິດຕັ້ງຢູ່ໃນ VM ຫຼື Ballooning ຖືກປິດໃຊ້ງານ (ຂ້ອຍບໍ່ແນະນໍາມັນ, ແຕ່ມີ KB:), hypervisor ທັນທີປ່ຽນໄປສູ່ເຕັກນິກທີ່ເຂັ້ມງວດຫຼາຍສໍາລັບການຖອນຄວາມຊົງຈໍາ. ສະຫຼຸບ: ໃຫ້ແນ່ໃຈວ່າ VMware Tools ຢູ່ໃນ VM.

ການເຮັດວຽກຂອງ Balloon Driver ສາມາດກວດສອບໄດ້ຈາກ OS ຜ່ານ VMware Tools.

ການບີບອັດຫນ່ວຍຄວາມຈໍາ. ເຕັກນິກນີ້ຖືກນໍາໃຊ້ເມື່ອ ESXi ມາຮອດສະຖານະແຂງ. ດັ່ງທີ່ຊື່ແນະນໍາ, ESXi ພະຍາຍາມບີບອັດຫນ້າ 4KB ຂອງ RAM ເຂົ້າໄປໃນ 2KB, ດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ພື້ນທີ່ຫວ່າງຢູ່ໃນຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍຂອງເຄື່ອງແມ່ຂ່າຍ. ເຕັກນິກນີ້ເພີ່ມເວລາເຂົ້າເຖິງເນື້ອຫາຂອງຫນ້າ VM RAM ຢ່າງຫຼວງຫຼາຍ, ເພາະວ່າຫນ້າເວັບທໍາອິດຕ້ອງໄດ້ຮັບການບີບອັດ. ບາງຄັ້ງບໍ່ແມ່ນຫນ້າທັງຫມົດສາມາດຖືກບີບອັດແລະຂະບວນການຂອງມັນເອງໃຊ້ເວລາບາງເວລາ. ດັ່ງນັ້ນ, ເຕັກນິກນີ້ບໍ່ມີປະສິດທິພາບຫຼາຍໃນການປະຕິບັດ.

ການແລກປ່ຽນຄວາມຊົງຈໍາ. ຫຼັງຈາກໄລຍະສັ້ນໆຂອງການບີບອັດຫນ່ວຍຄວາມຈໍາ, ESXi ເກືອບຈະຫຼີກລ່ຽງບໍ່ໄດ້ (ຖ້າ VMs ບໍ່ໄດ້ຍ້າຍໄປຢູ່ໃນໂຮດອື່ນຫຼືບໍ່ໄດ້ປິດ) ປ່ຽນເປັນ Swapping. ແລະຖ້າມີຫນ່ວຍຄວາມຈໍາຫນ້ອຍຫຼາຍ (ລັດຕ່ໍາ), hypervisor ຍັງຢຸດເຊົາການຈັດສັນຫນ້າຫນ່ວຍຄວາມຈໍາໃຫ້ກັບ VM, ເຊິ່ງສາມາດເຮັດໃຫ້ເກີດບັນຫາໃນ OS ແຂກຂອງ VM.

ນີ້ແມ່ນວິທີການ Swapping ເຮັດວຽກ. ເມື່ອທ່ານເປີດເຄື່ອງສະເໝືອນຈິງ, ໄຟລ໌ທີ່ມີນາມສະກຸນ .vswp ແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບມັນ. ມັນມີຂະຫນາດເທົ່າກັບ RAM ທີ່ບໍ່ໄດ້ສະຫງວນຂອງ VM: ນີ້ແມ່ນຄວາມແຕກຕ່າງລະຫວ່າງຫນ່ວຍຄວາມຈໍາທີ່ຖືກຕັ້ງຄ່າແລະສະຫງວນໄວ້. ເມື່ອ Swapping ກໍາລັງເຮັດວຽກ, ESXi ແລກປ່ຽນຫນ້າຫນ່ວຍຄວາມຈໍາເຄື່ອງ virtual ເຂົ້າໄປໃນໄຟລ໌ນີ້ແລະເລີ່ມເຮັດວຽກກັບມັນແທນທີ່ຈະເປັນຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍຂອງເຄື່ອງແມ່ຂ່າຍ. ແນ່ນອນ, ຫນ່ວຍຄວາມຈໍາ "RAM" ດັ່ງກ່າວແມ່ນມີຄໍາສັ່ງຫຼາຍຂະຫນາດຊ້າກວ່າຫນ່ວຍຄວາມຈໍາທີ່ແທ້ຈິງ, ເຖິງແມ່ນວ່າ .vswp ຢູ່ໃນບ່ອນເກັບຂໍ້ມູນໄວ.

ບໍ່ເຫມືອນກັບ Ballooning, ເມື່ອຫນ້າເວັບທີ່ບໍ່ໄດ້ໃຊ້ຖືກເອົາມາຈາກ VM, ດ້ວຍຫນ້າ Swapping ທີ່ຖືກນໍາໃຊ້ຢ່າງຈິງຈັງໂດຍ OS ຫຼືແອັບພລິເຄຊັນພາຍໃນ VM ສາມາດຖືກຍ້າຍໄປໃສ່ແຜ່ນດິດ. ດັ່ງນັ້ນ, ການປະຕິບັດຂອງ VM ຫຼຸດລົງເຖິງຈຸດຂອງ freezing. VM ກໍາລັງເຮັດວຽກຢ່າງເປັນທາງການແລະຢ່າງຫນ້ອຍມັນສາມາດຖືກປິດໃຊ້ງານຢ່າງຖືກຕ້ອງຈາກ OS. ຖ້າເຈົ້າອົດທົນ😉

ຖ້າ VMs ໄດ້ໄປຫາ Swap, ນີ້ແມ່ນສະຖານະການສຸກເສີນທີ່ຫຼີກເວັ້ນໄດ້ດີທີ່ສຸດຖ້າເປັນໄປໄດ້.

ຕົວນັບການປະຕິບັດຫນ່ວຍຄວາມຈໍາຂອງເຄື່ອງ virtual ພື້ນຖານ

ດັ່ງນັ້ນພວກເຮົາໄດ້ໄປຫາສິ່ງຕົ້ນຕໍ. ເພື່ອຕິດຕາມສະຖານະຄວາມຊົງຈໍາຂອງ VM, ມີຕົວນັບຕໍ່ໄປນີ້:

ການເຄື່ອນໄຫວ — ສະ​ແດງ​ໃຫ້​ເຫັນ​ຈໍາ​ນວນ RAM (KB​) ທີ່ VM ເຂົ້າ​ເຖິງ​ໃນ​ໄລ​ຍະ​ການ​ວັດ​ແທກ​ທີ່​ຜ່ານ​ມາ​.

ການນໍາໃຊ້ — ຄື​ກັນ​ກັບ​ການ​ເຄື່ອນ​ໄຫວ​, ແຕ່​ວ່າ​ເປັນ​ເປີ​ເຊັນ​ຂອງ RAM ການ​ຕັ້ງ​ຄ່າ​ຂອງ VM ໄດ້​. ຄິດໄລ່ໂດຍໃຊ້ສູດຕໍ່ໄປນີ້: active ÷ virtual machine configured memory size.
ການນໍາໃຊ້ສູງແລະການເຄື່ອນໄຫວ, ຕາມລໍາດັບ, ບໍ່ແມ່ນຕົວຊີ້ວັດຂອງບັນຫາການປະຕິບັດ VM ສະເຫມີ. ຖ້າ VM ຮຸກຮານໃຊ້ຫນ່ວຍຄວາມຈໍາ (ຢ່າງຫນ້ອຍເຂົ້າເຖິງມັນ), ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າບໍ່ມີຫນ່ວຍຄວາມຈໍາພຽງພໍ. ແທນທີ່ຈະ, ນີ້ແມ່ນເຫດຜົນທີ່ຈະເບິ່ງສິ່ງທີ່ເກີດຂື້ນໃນ OS.
ມີສັນຍານເຕືອນມາດຕະຖານສໍາລັບການນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາສໍາລັບ VMs:

ແບ່ງປັນ — ຈໍາ​ນວນ​ຂອງ VM RAM deduplicated ໂດຍ​ນໍາ​ໃຊ້ TPS (ພາຍ​ໃນ VM ຫຼື​ລະ​ຫວ່າງ VMs​)​.

ອະນຸຍາດ — ຈໍາ​ນວນ​ຂອງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ (KB​) ທີ່​ໄດ້​ຖືກ​ຈັດ​ສັນ​ໃຫ້ VM​. ເປີດໃຊ້ການແບ່ງປັນ.

ບໍລິໂພກ (ອະນຸຍາດ - ແບ່ງປັນ) - ຈໍານວນຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍ (KB) ທີ່ VM ບໍລິໂພກຈາກເຈົ້າພາບ. ບໍ່ລວມເອົາ Shared.

ຖ້າສ່ວນຫນຶ່ງຂອງຫນ່ວຍຄວາມຈໍາ VM ບໍ່ໄດ້ຖືກມອບໃຫ້ມາຈາກຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍຂອງເຈົ້າພາບ, ແຕ່ຈາກໄຟລ໌ swap, ຫຼືຫນ່ວຍຄວາມຈໍາຖືກນໍາມາຈາກ VM ຜ່ານ Balloon Driver, ຈໍານວນນີ້ຈະບໍ່ຖືກພິຈາລະນາໃນອະນຸຍາດໃຫ້ແລະບໍລິໂພກ.
ຄຸນ​ຄ່າ​ສູງ​ແລະ​ການ​ບໍ​ລິ​ໂພກ​ແມ່ນ​ປົກ​ກະ​ຕິ​ຫມົດ​. ລະບົບປະຕິບັດການຄ່ອຍໆເອົາຫນ່ວຍຄວາມຈໍາຈາກ hypervisor ແລະບໍ່ໃຫ້ມັນກັບຄືນມາ. ເມື່ອເວລາຜ່ານໄປ, ໃນ VM ທີ່ເຮັດວຽກຢ່າງຫ້າວຫັນ, ມູນຄ່າຂອງຕົວນັບເຫຼົ່ານີ້ເຂົ້າຫາຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ຖືກຕັ້ງຄ່າ, ແລະຍັງຄົງຢູ່ທີ່ນັ້ນ.

Zero — ຈໍາ​ນວນ​ຂອງ VM RAM (KB​)​, ເຊິ່ງ​ປະ​ກອບ​ດ້ວຍ​ສູນ​. ໜ່ວຍຄວາມຈຳດັ່ງກ່າວຖືວ່າບໍ່ເສຍຄ່າໂດຍ hypervisor ແລະສາມາດມອບໃຫ້ກັບເຄື່ອງ virtual ອື່ນໆ. ຫຼັງຈາກ OS ແຂກໄດ້ຂຽນບາງສິ່ງບາງຢ່າງໃຫ້ກັບຫນ່ວຍຄວາມຈໍາສູນ, ມັນຈະເຂົ້າໄປໃນ Consumed ແລະບໍ່ກັບຄືນ.

ຈອງລ່ວງໜ້າ — ຈໍາ​ນວນ​ຂອງ VM RAM​, (KB​) ສະ​ຫງວນ​ໂດຍ hypervisor ສໍາ​ລັບ​ການ​ດໍາ​ເນີນ​ງານ VM​. ນີ້ແມ່ນຈໍານວນນ້ອຍໆ, ແຕ່ວ່າມັນຕ້ອງມີຢູ່ໃນເຈົ້າພາບ, ຖ້າບໍ່ດັ່ງນັ້ນ VM ຈະບໍ່ເລີ່ມຕົ້ນ.

ປູມເປົ້າ — ຈໍາ​ນວນ RAM (KB​) ອອກ​ຈາກ VM ໂດຍ​ນໍາ​ໃຊ້ Balloon Driver​.

ບີບອັດ — ຈໍາ​ນວນ RAM (KB​) ທີ່​ໄດ້​ຖືກ​ບີບ​ອັດ​.

ໄດ້ແລກປ່ຽນແລ້ວ — ຈໍາ​ນວນ RAM (KB​)​, ຊຶ່ງ​ເນື່ອງ​ຈາກ​ການ​ຂາດ​ຄວາມ​ຊົງ​ຈໍາ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ​ໃນ​ເຄື່ອງ​ແມ່​ຂ່າຍ​, ໄດ້​ຍ້າຍ​ໄປ disk​.
ປູມເປົ້າ ແລະ ເຕັກນິກການຍຶດຄືນຄວາມຈຳອື່ນໆແມ່ນສູນ.

ນີ້ແມ່ນສິ່ງທີ່ກາຟເບິ່ງຄືກັບຕົວນັບຫນ່ວຍຄວາມຈໍາຂອງ VM ທີ່ເຮັດວຽກປົກກະຕິທີ່ມີ 150 GB ຂອງ RAM.

ໃນກາຟຂ້າງລຸ່ມນີ້, VM ມີບັນຫາທີ່ຊັດເຈນ. ຂ້າງລຸ່ມນີ້ກຣາຟທ່ານສາມາດເບິ່ງວ່າສໍາລັບ VM ນີ້, ເຕັກນິກການອະທິບາຍທັງຫມົດສໍາລັບການເຮັດວຽກກັບ RAM ໄດ້ຖືກນໍາໃຊ້. ປູມເປົ້າສໍາລັບ VM ນີ້ແມ່ນໃຫຍ່ກວ່າການບໍລິໂພກ. ໃນຄວາມເປັນຈິງ, VM ແມ່ນຕາຍຫຼາຍກ່ວາມີຊີວິດຢູ່.

ESXTOP

ເຊັ່ນດຽວກັນກັບ CPU, ຖ້າພວກເຮົາຕ້ອງການປະເມີນສະຖານະການໃນເຈົ້າພາບຢ່າງໄວວາ, ເຊັ່ນດຽວກັນກັບການເຄື່ອນໄຫວຂອງມັນທີ່ມີໄລຍະຫ່າງເຖິງ 2 ວິນາທີ, ພວກເຮົາຄວນໃຊ້ ESXTOP.

ໜ້າຈໍໜ່ວຍຄວາມຈຳ ESXTOP ຖືກເອີ້ນຂຶ້ນດ້ວຍປຸ່ມ “m” ແລະມີລັກສະນະນີ້ (ຊ່ອງຂໍ້ມູນ B,D,H,J,K,L,O ເລືອກ):

ຕົວກໍານົດການຕໍ່ໄປນີ້ຈະມີຄວາມສົນໃຈກັບພວກເຮົາ:

mem overcommit avg — ມູນ​ຄ່າ​ສະ​ເລ່ຍ​ຂອງ​ການ​ສະ​ຫມັກ​ຈໍາ​ນວນ​ຫຼາຍ​ເກີນ​ໄປ​ໃນ​ເຈົ້າ​ພາບ​ສໍາ​ລັບ 1, 5 ແລະ 15 ນາ​ທີ​. ຖ້າມັນຢູ່ເຫນືອສູນ, ນີ້ແມ່ນເຫດຜົນທີ່ຈະເບິ່ງສິ່ງທີ່ເກີດຂື້ນ, ແຕ່ບໍ່ແມ່ນຕົວຊີ້ວັດຂອງບັນຫາສະເຫມີ.

ໃນສາຍ PMEM/MB и VMKMEM/MB — ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ຄວາມ​ຊົງ​ຈໍາ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ແລະ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ທີ່​ມີ​ຢູ່​ໃນ VMkernel​. ໃນບັນດາສິ່ງທີ່ຫນ້າສົນໃຈທີ່ນີ້ທ່ານສາມາດເບິ່ງມູນຄ່າ minfree (ໃນ MB), ສະຖານະເຈົ້າພາບໃນຫນ່ວຍຄວາມຈໍາ (ໃນກໍລະນີຂອງພວກເຮົາ, ສູງ).

ໃນແຖວ NUMA/MB ທ່ານສາມາດເບິ່ງການແຜ່ກະຈາຍຂອງ RAM ໃນທົ່ວ NUMA nodes (sockets). ໃນຕົວຢ່າງນີ້, ການແຈກຢາຍແມ່ນບໍ່ສະເຫມີພາບ, ເຊິ່ງໃນຫຼັກການແມ່ນບໍ່ດີຫຼາຍ.

ຕໍ່ໄປນີ້ແມ່ນສະຖິຕິທົ່ວໄປຂອງເຊີບເວີສຳລັບເຕັກນິກການຍຶດໜ່ວຍຄວາມຈຳຄືນໃໝ່:

PSHARE/MB — ເຫຼົ່ານີ້ແມ່ນສະຖິຕິ TPS;

SWAP/MB - ສະ​ຖິ​ຕິ​ການ​ນໍາ​ໃຊ້​ສະ​ຫຼັບ​;

ZIP/MB — ສະ​ຖິ​ຕິ​ການ​ບີບ​ອັດ​ຫນ້າ​ຄວາມ​ຊົງ​ຈໍາ​;

MEMCTL/MB - ສະ​ຖິ​ຕິ​ການ​ນໍາ​ໃຊ້ Balloon Driver​.

ສໍາລັບ VMs ສ່ວນບຸກຄົນ, ພວກເຮົາອາດຈະມີຄວາມສົນໃຈໃນຂໍ້ມູນຕໍ່ໄປນີ້. ຂ້ອຍເຊື່ອງຊື່ຂອງ VMs ເພື່ອບໍ່ໃຫ້ຜູ້ຊົມສັບສົນ :). ຖ້າ ESXTOP metric ແມ່ນຄ້າຍຄືກັນກັບຕົວນັບໃນ vSphere, ຂ້ອຍຈະໃຫ້ຕົວນັບທີ່ສອດຄ້ອງກັນ.

MEMSZ — ຈໍາ​ນວນ​ຂອງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ທີ່​ກໍາ​ນົດ​ໄວ້​ໃນ VM (MB​)​.
MEMSZ = GRANT + MCTLSZ + SWCUR + ບໍ່ໄດ້ສໍາຜັດ.

ອະນຸມັດ — ໄດ້​ຮັບ​ໃນ MB​.

TCHD - ມີການເຄື່ອນໄຫວຢູ່ໃນ MBytes.

MCTL? — ບໍ່ວ່າ Balloon Driver ຖືກຕິດຕັ້ງຢູ່ໃນ VM.

MCTLSZ - ປູມເປົ້າໃສ່ MB.

MCTLGT — ຈໍານວນ RAM (MBytes) ທີ່ ESXi ຕ້ອງການເອົາອອກຈາກ VM ຜ່ານ Balloon Driver (Memctl Target).

MCTLMAX — ຈໍານວນສູງສຸດຂອງ RAM (MBytes) ທີ່ ESXi ສາມາດເອົາອອກຈາກ VM ຜ່ານ Balloon Driver.

SWCUR — ຈໍາ​ນວນ RAM (MBytes​) ປະ​ຈຸ​ບັນ​ໄດ້​ຈັດ​ສັນ​ໃຫ້ VM ຈາກ​ໄຟລ​໌ Swap​.

S.W.G.T. — ຈໍານວນ RAM (MBytes) ທີ່ ESXi ຕ້ອງການໃຫ້ VM ຈາກໄຟລ໌ Swap (Swap Target).

ທ່ານຍັງສາມາດເບິ່ງຂໍ້ມູນລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບ NUMA topology ຂອງ VM ຜ່ານ ESXTOP. ເພື່ອເຮັດສິ່ງນີ້, ເລືອກຊ່ອງຂໍ້ມູນ D, G:

ຂະຫນາດນ້ອຍ – NUMA nodes ທີ່ VM ຕັ້ງຢູ່. ໃນທີ່ນີ້ທ່ານສາມາດສັງເກດເຫັນ vm ກວ້າງໄດ້ທັນທີ, ເຊິ່ງບໍ່ເຫມາະສົມກັບຫນຶ່ງ NUMA node.

NRMEM – ໜ່ວຍຄວາມຈຳຈັກເມກາໄບທີ່ VM ໃຊ້ເວລາຈາກ NUMA node ໄລຍະໄກ.

NLMEM – ຫນ່ວຍຄວາມຈໍາຈັກ megabytes ທີ່ VM ໃຊ້ເວລາຈາກ node NUMA ທ້ອງຖິ່ນ.

N%L – ເປີເຊັນຂອງຫນ່ວຍຄວາມຈໍາ VM ໃນ NUMA node ທ້ອງຖິ່ນ (ຖ້າຫນ້ອຍກວ່າ 80%, ບັນຫາການປະຕິບັດອາດຈະເກີດຂື້ນ).

ຄວາມຈໍາໃນ hypervisor

ຖ້າ CPU counters ສໍາລັບ hypervisor ປົກກະຕິແລ້ວບໍ່ມີຄວາມສົນໃຈໂດຍສະເພາະ, ຫຼັງຈາກນັ້ນກັບຄວາມຊົງຈໍາ, ສະຖານະການແມ່ນກົງກັນຂ້າມ. ການໃຊ້ຄວາມຈຳສູງໃນ VM ບໍ່ໄດ້ຊີ້ບອກເຖິງບັນຫາປະສິດທິພາບສະເໝີໄປ, ແຕ່ການໃຊ້ຄວາມຈຳສູງໃນ hypervisor ກະຕຸ້ນເຕັກນິກການຈັດການຄວາມຈຳ ແລະເຮັດໃຫ້ເກີດບັນຫາກັບປະສິດທິພາບຂອງ VM. ທ່ານຈໍາເປັນຕ້ອງຕິດຕາມສັນຍານເຕືອນການນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາຂອງເຈົ້າພາບແລະປ້ອງກັນບໍ່ໃຫ້ VMs ເຂົ້າໄປໃນ Swap.

ເຊົາແລກປ່ຽນ

ຖ້າ VM ຖືກຈັບຢູ່ໃນ Swap, ປະສິດທິພາບຂອງມັນຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ຮ່ອງຮອຍຂອງ Ballooning ແລະການບີບອັດຫາຍໄປຢ່າງໄວວາຫຼັງຈາກ RAM ຟຣີປາກົດຢູ່ໃນເຈົ້າພາບ, ແຕ່ເຄື່ອງ virtual ແມ່ນບໍ່ຮີບຮ້ອນທີ່ຈະກັບຄືນມາຈາກ Swap ກັບ RAM ຂອງເຄື່ອງແມ່ຂ່າຍ.
ກ່ອນ ESXi 6.0, ວິທີດຽວທີ່ເຊື່ອຖືໄດ້ແລະໄວທີ່ຈະເອົາ VM ອອກຈາກ Swap ແມ່ນການປິດເປີດໃຫມ່ (ທີ່ຊັດເຈນກວ່ານັ້ນ, ປິດ / ເປີດຕູ້ຄອນເທນເນີ). ເລີ່ມຕົ້ນດ້ວຍ ESXi 6.0, ເຖິງແມ່ນວ່າບໍ່ແມ່ນທາງການທັງຫມົດ, ວິທີທີ່ເຮັດວຽກແລະເຊື່ອຖືໄດ້ທີ່ຈະເອົາ VM ອອກຈາກ Swap ໄດ້ປາກົດຂຶ້ນ. ໃນກອງປະຊຸມຫນຶ່ງ, ຂ້ອຍສາມາດສົນທະນາກັບຫນຶ່ງໃນວິສະວະກອນ VMware ທີ່ຮັບຜິດຊອບ CPU Scheduler. ລາວຢືນຢັນວ່າວິທີການແມ່ນຂ້ອນຂ້າງເຮັດວຽກແລະປອດໄພ. ໃນປະສົບການຂອງພວກເຮົາ, ບໍ່ມີບັນຫາກັບມັນຄືກັນ.

ຄໍາສັ່ງທີ່ແທ້ຈິງສໍາລັບການຖອນ VM ອອກຈາກ Swap ອະທິບາຍ Duncan Epping. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບໍ່​ໄດ້​ເຮັດ​ເລ​ື້ມ​ຄືນ​ລາຍ​ລະ​ອຽດ​, ຂ້າ​ພະ​ເຈົ້າ​ພຽງ​ແຕ່​ຈະ​ຍົກ​ຕົວ​ຢ່າງ​ຂອງ​ການ​ນໍາ​ໃຊ້​ມັນ​. ດັ່ງທີ່ເຈົ້າເຫັນໃນພາບໜ້າຈໍ, ບາງເທື່ອຫຼັງຈາກປະຕິບັດຄຳສັ່ງທີ່ກຳນົດໄວ້, Swap on the VM ຈະຫາຍໄປ.

ຄໍາແນະນໍາສໍາລັບການຄຸ້ມຄອງ RAM ໃນ ESXi

ສຸດທ້າຍ, ນີ້ແມ່ນຄໍາແນະນໍາຈໍານວນຫນ້ອຍທີ່ຈະຊ່ວຍໃຫ້ທ່ານຫຼີກເວັ້ນບັນຫາກັບການປະຕິບັດ VM ເນື່ອງຈາກ RAM:

• ຫຼີກເວັ້ນການ subscription ຂອງ RAM ຫຼາຍເກີນໄປໃນກຸ່ມຜະລິດຕະພັນ. ມັນສົມຄວນທີ່ຈະມີ ~ 20-30% ຂອງຫນ່ວຍຄວາມຈໍາຟຣີຢູ່ໃນກຸ່ມເພື່ອໃຫ້ DRS (ແລະຜູ້ເບິ່ງແຍງລະບົບ) ມີບ່ອນຫວ່າງເພື່ອ maneuver ແລະ VMs ບໍ່ໄປຫາ Swap ໃນລະຫວ່າງການເຄື່ອນຍ້າຍ. ນອກຈາກນັ້ນ, ຢ່າລືມກ່ຽວກັບຂອບສໍາລັບຄວາມທົນທານຕໍ່ຄວາມຜິດ. ມັນບໍ່ຫນ້າພໍໃຈໃນເວລາທີ່, ເມື່ອເຄື່ອງແມ່ຂ່າຍຫນຶ່ງລົ້ມເຫລວແລະ VM ຖືກ rebooted ໂດຍໃຊ້ HA, ບາງເຄື່ອງກໍ່ໄປຫາ Swap.
• ໃນໂຄງສ້າງພື້ນຖານທີ່ລວມກັນສູງ, ພະຍາຍາມບໍ່ສ້າງ VM ທີ່ມີຫນ່ວຍຄວາມຈໍາໃຫຍ່ກວ່າເຄິ່ງຫນຶ່ງຂອງຫນ່ວຍຄວາມຈໍາຂອງເຈົ້າພາບ. ນີ້ອີກເທື່ອຫນຶ່ງຈະຊ່ວຍໃຫ້ DRS ແຈກຢາຍເຄື່ອງ virtual ໃນທົ່ວເຄື່ອງແມ່ຂ່າຍຂອງກຸ່ມໂດຍບໍ່ມີບັນຫາໃດໆ. ກົດລະບຽບນີ້, ແນ່ນອນ, ບໍ່ແມ່ນທົ່ວໄປ :).
• ລະວັງການປຸກການນຳໃຊ້ໜ່ວຍຄວາມຈຳຂອງເຈົ້າພາບ.
• ຢ່າລືມຕິດຕັ້ງ VMware Tools ໃນ VM ແລະຢ່າປິດ Ballooning.
• ພິຈາລະນາການເປີດໃຊ້ Inter-VM TPS ແລະປິດການໃຊ້ງານຫນ້າຂະຫນາດໃຫຍ່ໃນ VDI ແລະສະພາບແວດລ້ອມການທົດສອບ.
• ຖ້າ VM ປະສົບບັນຫາການປະຕິບັດ, ໃຫ້ກວດເບິ່ງວ່າມັນກໍາລັງໃຊ້ຫນ່ວຍຄວາມຈໍາຈາກ NUMA node ຫ່າງໄກສອກຫຼີກຫຼືບໍ່.
• ເອົາ VMs ອອກຈາກ 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