ລັກ: ຜູ້ທີ່ລັກເວລາ CPU ຈາກເຄື່ອງ virtual

ສະບາຍດີ! ຂ້າພະເຈົ້າຢາກບອກທ່ານໃນຄໍາສັບທີ່ງ່າຍດາຍກ່ຽວກັບກົນໄກການລັກພາຍໃນເຄື່ອງ virtual ແລະກ່ຽວກັບບາງສິ່ງປອມທີ່ບໍ່ຊັດເຈນທີ່ພວກເຮົາໄດ້ຄົ້ນຫາໃນລະຫວ່າງການຄົ້ນຄ້ວາຂອງມັນ, ເຊິ່ງຂ້ອຍຕ້ອງເຂົ້າໄປໃນການເປັນຜູ້ອໍານວຍການດ້ານວິຊາການຂອງເວທີຟັງ. Mail.ru Cloud Solutions. ເວທີທີ່ເຮັດວຽກຢູ່ໃນ KVM.

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

1. ການລັກແມ່ນຫຍັງ

ດັ່ງນັ້ນ, ການລັກແມ່ນຕົວຊີ້ວັດທີ່ຊີ້ໃຫ້ເຫັນເຖິງການຂາດເວລາຂອງໂປເຊດເຊີສໍາລັບຂະບວນການພາຍໃນເຄື່ອງ virtual. ດັ່ງທີ່ໄດ້ອະທິບາຍ ໃນ KVM kernel patchStealth ແມ່ນເວລາທີ່ hypervisor ກໍາລັງປະຕິບັດຂະບວນການອື່ນໆໃນ host OS ເຖິງແມ່ນວ່າມັນໄດ້ຈັດລໍາດັບຂະບວນການ virtual machine ສໍາລັບການປະຕິບັດ. ນັ້ນແມ່ນ, ການລັກຖືກຄິດໄລ່ເປັນຄວາມແຕກຕ່າງລະຫວ່າງເວລາທີ່ຂະບວນການພ້ອມທີ່ຈະປະຕິບັດແລະເວລາທີ່ຂະບວນການຖືກຈັດສັນເວລາຂອງໂປເຊດເຊີ.

kernel ເຄື່ອງ virtual ໄດ້ຮັບ metric ລັກຈາກ hypervisor. ໃນເວລາດຽວກັນ, hypervisor ບໍ່ໄດ້ລະບຸຢ່າງແນ່ນອນວ່າຂະບວນການອື່ນໆທີ່ມັນກໍາລັງເຮັດວຽກ, ມັນພຽງແຕ່ເວົ້າວ່າ "ໃນຂະນະທີ່ຂ້ອຍຫຍຸ້ງຢູ່, ຂ້ອຍບໍ່ສາມາດໃຫ້ເວລາເຈົ້າໄດ້." ໃນ KVM, ການສະຫນັບສະຫນູນການຄິດໄລ່ການລັກໄດ້ຖືກເພີ່ມເຂົ້າໃນ ເພີ້ມ. ມີສອງຈຸດສໍາຄັນຢູ່ທີ່ນີ້:

• ເຄື່ອງ virtual ຮຽນຮູ້ກ່ຽວກັບການລັກຈາກ hypervisor. ນັ້ນແມ່ນ, ຈາກທັດສະນະຂອງການສູນເສຍ, ສໍາລັບຂະບວນການໃນເຄື່ອງ virtual ຕົວຂອງມັນເອງນີ້ແມ່ນການວັດແທກທາງອ້ອມທີ່ສາມາດຖືກບິດເບືອນຕ່າງໆ.
• hypervisor ບໍ່ໄດ້ແບ່ງປັນຂໍ້ມູນກັບເຄື່ອງ virtual ກ່ຽວກັບສິ່ງທີ່ມັນກໍາລັງເຮັດ - ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າມັນບໍ່ໄດ້ໃຊ້ເວລາກັບມັນ. ເນື່ອງຈາກວ່ານີ້, ເຄື່ອງ virtual ຕົວຂອງມັນເອງບໍ່ສາມາດກວດພົບການບິດເບືອນໃນຕົວຊີ້ວັດການລັກ, ເຊິ່ງສາມາດໄດ້ຮັບການປະເມີນໂດຍລັກສະນະຂອງຂະບວນການແຂ່ງຂັນ.

2. ສິ່ງທີ່ສົ່ງຜົນກະທົບຕໍ່ການລັກ

2.1. ລັກ​ການ​ຄິດ​ໄລ່​

ໂດຍພື້ນຖານແລ້ວ, ການລັກແມ່ນຄິດໄລ່ປະມານເທົ່າກັບເວລາໃຊ້ CPU ປົກກະຕິ. ບໍ່ມີຂໍ້ມູນຫຼາຍກ່ຽວກັບວິທີການນໍາມາໃຊ້ຄືນໄດ້ຖືກພິຈາລະນາ. ອາດຈະເປັນຍ້ອນວ່າປະຊາຊົນສ່ວນໃຫຍ່ພິຈາລະນາຄໍາຖາມນີ້ຈະແຈ້ງ. ແຕ່​ກໍ​ຍັງ​ມີ pitfalls ຢູ່​ທີ່​ນີ້​. ເພື່ອຄຸ້ນເຄີຍກັບຂະບວນການນີ້, ທ່ານສາມາດອ່ານໄດ້ ບົດຄວາມໂດຍ Brendan Gregg: ທ່ານຈະໄດ້ຮຽນຮູ້ກ່ຽວກັບ nuances ຫຼາຍໃນເວລາທີ່ການຄິດໄລ່ການນໍາໃຊ້ແລະສະຖານະການໃນເວລາທີ່ການຄິດໄລ່ນີ້ຈະຜິດພາດສໍາລັບເຫດຜົນດັ່ງຕໍ່ໄປນີ້:

• ໂປເຊດເຊີຮ້ອນເກີນໄປ, ເຮັດໃຫ້ຮອບວຽນຂ້າມໄປ.
• ເປີດ/ປິດ turbo boost, ເຊິ່ງປ່ຽນຄວາມໄວໂມງຂອງໂປເຊດເຊີ.
• ການປ່ຽນແປງຂອງຄວາມຍາວຂອງເວລາທີ່ເກີດຂຶ້ນເມື່ອໃຊ້ເທັກໂນໂລຍີປະຫຍັດພະລັງງານຂອງໂປເຊດເຊີເຊັ່ນ SpeedStep.
• ບັນຫາໃນການຄິດໄລ່ຄ່າສະເລ່ຍ: ການຄາດຄະເນການນໍາໃຊ້ຫນຶ່ງນາທີຢູ່ທີ່ 80% ສາມາດເຊື່ອງການລະເບີດໃນໄລຍະສັ້ນຂອງ 100%.
• ການລັອກສະປິນເຮັດໃຫ້ໂປເຊດເຊີຖືກຍຶດຄືນ, ແຕ່ຂະບວນການຜູ້ໃຊ້ບໍ່ເຫັນຄວາມຄືບຫນ້າໃດໆໃນການປະຕິບັດຂອງມັນ. ດັ່ງນັ້ນ, ການໃຊ້ໂປເຊດເຊີທີ່ຄິດໄລ່ໂດຍຂະບວນການຈະເປັນຫນຶ່ງຮ້ອຍສ່ວນຮ້ອຍ, ເຖິງແມ່ນວ່າຂະບວນການຈະບໍ່ໃຊ້ເວລາຂອງໂປເຊດເຊີ.

ຂ້ອຍບໍ່ພົບບົດຄວາມທີ່ອະທິບາຍການຄິດໄລ່ທີ່ຄ້າຍຄືກັນສໍາລັບການລັກ (ຖ້າທ່ານຮູ້, ແບ່ງປັນມັນໃນຄໍາເຫັນ). ແຕ່, ການຕັດສິນໂດຍລະຫັດແຫຼ່ງ, ກົນໄກການຄິດໄລ່ແມ່ນຄືກັນກັບການລີໄຊເຄີນ. ພຽງແຕ່, counter ອື່ນແມ່ນເພີ່ມໃນ kernel, ໂດຍກົງສໍາລັບຂະບວນການ KVM (ຂະບວນການເຄື່ອງຈັກ virtual), ເຊິ່ງນັບໄລຍະເວລາຂອງຂະບວນການ KVM ລໍຖ້າເວລາ CPU. ເຄົາເຕີເອົາຂໍ້ມູນກ່ຽວກັບໂປເຊດເຊີຈາກຂໍ້ມູນສະເພາະຂອງມັນແລະກວດເບິ່ງວ່າຫມາຍຕິກທັງຫມົດຂອງມັນຖືກໃຊ້ໂດຍຂະບວນການ virtual machine ຫຼືບໍ່. ຖ້ານັ້ນແມ່ນທັງຫມົດ, ພວກເຮົາສົມມຸດວ່າໂປເຊດເຊີພຽງແຕ່ຖືກຄອບຄອງກັບຂະບວນການເຄື່ອງ virtual. ຖ້າບໍ່ດັ່ງນັ້ນ, ພວກເຮົາແຈ້ງໃຫ້ຊາບວ່າໂຮງງານຜະລິດກໍາລັງເຮັດສິ່ງອື່ນ, ລັກປາກົດ.

ຂະ​ບວນ​ການ​ນັບ​ລັກ​ແມ່ນ​ຂຶ້ນ​ກັບ​ບັນ​ຫາ​ດຽວ​ກັນ​ກັບ​ການ​ນັບ​ການ​ນໍາ​ໃຊ້​ໃຫມ່​ປົກ​ກະ​ຕິ​. ບໍ່​ໄດ້​ເວົ້າ​ວ່າ​ບັນ​ຫາ​ດັ່ງ​ກ່າວ​ປະ​ກົດ​ຂຶ້ນ​ເລື້ອຍໆ, ແຕ່​ເບິ່ງ​ຄື​ວ່າ​ທໍ້​ຖອຍ​ໃຈ.

2.2. ປະເພດຂອງ virtualization ໃນ KVM

ເວົ້າຢ່າງກວ້າງຂວາງ, ມີສາມປະເພດຂອງ virtualization, ທັງຫມົດທີ່ສະຫນັບສະຫນູນໂດຍ KVM. ກົນໄກຂອງການລັກລອບເກີດຂຶ້ນອາດຈະຂຶ້ນກັບປະເພດຂອງ virtualization.

ອອກອາກາດ. ໃນກໍລະນີນີ້, ການດໍາເນີນງານຂອງລະບົບປະຕິບັດການ virtual machine ກັບອຸປະກອນ hypervisor ທາງດ້ານຮ່າງກາຍເກີດຂຶ້ນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

1. ລະບົບປະຕິບັດການຂອງແຂກສົ່ງຄໍາສັ່ງໄປຫາອຸປະກອນແຂກຂອງມັນ.
2. ໄດເວີອຸປະກອນຂອງແຂກໄດ້ຮັບຄໍາສັ່ງ, ສ້າງການຮ້ອງຂໍສໍາລັບອຸປະກອນ BIOS ແລະສົ່ງມັນໄປຫາ hypervisor.
3. ຂະບວນການ hypervisor ແປຄໍາສັ່ງຄໍາສັ່ງສໍາລັບອຸປະກອນທາງດ້ານຮ່າງກາຍ, ເຮັດໃຫ້ມັນ, ໃນບັນດາສິ່ງອື່ນໆ, ຄວາມປອດໄພຫຼາຍ.
4. ໄດເວີອຸປະກອນທາງກາຍະພາບຍອມຮັບຄໍາສັ່ງທີ່ຖືກດັດແປງແລະສົ່ງມັນໄປຫາອຸປະກອນທາງດ້ານຮ່າງກາຍຂອງມັນເອງ.
5. ຜົນໄດ້ຮັບຂອງການປະຕິບັດຄໍາສັ່ງກັບຄືນໄປຕາມເສັ້ນທາງດຽວກັນ.

ປະໂຫຍດຂອງການແປພາສາແມ່ນວ່າມັນອະນຸຍາດໃຫ້ທ່ານສາມາດເຮັດຕາມອຸປະກອນຕ່າງໆແລະບໍ່ຈໍາເປັນຕ້ອງມີການກະກຽມພິເສດຂອງ kernel ລະບົບປະຕິບັດການ. ແຕ່ທ່ານຕ້ອງຈ່າຍສໍາລັບການນີ້, ກ່ອນອື່ນ ໝົດ, ໃນຄວາມໄວ.

ຮາດແວ virtualization. ໃນກໍລະນີນີ້, ອຸປະກອນຢູ່ໃນລະດັບຮາດແວເຂົ້າໃຈຄໍາສັ່ງຈາກລະບົບປະຕິບັດການ. ນີ້ແມ່ນວິທີທີ່ໄວທີ່ສຸດແລະດີທີ່ສຸດ. ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍອຸປະກອນທາງດ້ານຮ່າງກາຍທັງຫມົດ, hypervisors ແລະລະບົບປະຕິບັດການຂອງແຂກ. ໃນປັດຈຸບັນ, ອຸປະກອນຕົ້ນຕໍທີ່ສະຫນັບສະຫນູນຮາດແວ virtualization ແມ່ນໂປເຊດເຊີ.

Paravirtualization. ທາງເລືອກທົ່ວໄປທີ່ສຸດສໍາລັບການ virtualization ອຸປະກອນໃນ KVM ແລະໂດຍທົ່ວໄປແລ້ວຮູບແບບ virtualization ທົ່ວໄປທີ່ສຸດສໍາລັບລະບົບປະຕິບັດການແຂກ. peculiarity ຂອງມັນແມ່ນການເຮັດວຽກກັບບາງລະບົບຍ່ອຍ hypervisor (ຕົວຢ່າງເຊັ່ນ, ກັບເຄືອຂ່າຍຫຼື disk stack) ຫຼືການຈັດສັນຫນ້າຫນ່ວຍຄວາມຈໍາເກີດຂຶ້ນໂດຍໃຊ້ hypervisor API, ໂດຍບໍ່ມີການແປຄໍາສັ່ງລະດັບຕ່ໍາ. ຂໍ້ເສຍຂອງວິທີການ virtualization ນີ້ແມ່ນວ່າ kernel ລະບົບປະຕິບັດການຂອງແຂກຕ້ອງໄດ້ຮັບການແກ້ໄຂເພື່ອໃຫ້ມັນສາມາດສື່ສານກັບ hypervisor ໂດຍໃຊ້ API ນີ້. ແຕ່ປົກກະຕິແລ້ວນີ້ແມ່ນການແກ້ໄຂໂດຍການຕິດຕັ້ງໄດເວີພິເສດໃນລະບົບປະຕິບັດການຂອງແຂກ. ໃນ KVM API ນີ້ເອີ້ນວ່າ virtio API.

ດ້ວຍ paravirtualization, ເມື່ອທຽບກັບການອອກອາກາດ, ເສັ້ນທາງໄປສູ່ອຸປະກອນທາງດ້ານຮ່າງກາຍແມ່ນຫຼຸດລົງຢ່າງຫຼວງຫຼາຍໂດຍການສົ່ງຄໍາສັ່ງໂດຍກົງຈາກເຄື່ອງ virtual ກັບຂະບວນການ hypervisor ໃນເຈົ້າພາບ. ນີ້ອະນຸຍາດໃຫ້ທ່ານເພື່ອເລັ່ງການປະຕິບັດຄໍາແນະນໍາທັງຫມົດພາຍໃນເຄື່ອງ virtual. ໃນ KVM, ນີ້ແມ່ນເຮັດໄດ້ໂດຍ virtio API, ເຊິ່ງພຽງແຕ່ເຮັດວຽກສໍາລັບອຸປະກອນສະເພາະໃດຫນຶ່ງ, ເຊັ່ນ: ເຄືອຂ່າຍຫຼືອະແດບເຕີແຜ່ນ. ນີ້ແມ່ນເຫດຜົນທີ່ໄດເວີ virtio ຖືກຕິດຕັ້ງຢູ່ໃນເຄື່ອງ virtual.

ຂໍ້ເສຍຂອງການເລັ່ງນີ້ແມ່ນວ່າບໍ່ແມ່ນຂະບວນການທັງຫມົດທີ່ດໍາເນີນການພາຍໃນເຄື່ອງ virtual ຍັງຄົງຢູ່ໃນມັນ. ອັນນີ້ສ້າງຜົນກະທົບພິເສດບາງຢ່າງທີ່ສາມາດສົ່ງຜົນໃຫ້ເກີດການລັກລອບ. ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເລີ່ມຕົ້ນການສຶກສາລາຍລະອຽດກ່ຽວກັບບັນຫານີ້ກັບ API ສໍາລັບ virtual I/O: virtio.

2.3. ການຈັດຕາຕະລາງ "ຍຸດຕິທໍາ".

ໃນຄວາມເປັນຈິງ, ເຄື່ອງ virtual ເທິງ hypervisor ແມ່ນຂະບວນການທໍາມະດາທີ່ປະຕິບັດຕາມກົດຫມາຍຂອງການກໍານົດເວລາ (ການແຈກຢາຍຊັບພະຍາກອນລະຫວ່າງຂະບວນການ) ໃນ Linux kernel, ດັ່ງນັ້ນໃຫ້ພວກເຮົາພິຈາລະນາຢ່າງໃກ້ຊິດ.

Linux ໃຊ້ອັນທີ່ເອີ້ນວ່າ CFS, Completely Fair Scheduler, ເຊິ່ງໄດ້ກາຍເປັນຕົວກໍານົດເວລາເລີ່ມຕົ້ນຕັ້ງແຕ່ kernel 2.6.23. ເພື່ອເຂົ້າໃຈວິທີການນີ້, ທ່ານສາມາດອ່ານ Linux Kernel Architecture ຫຼືລະຫັດແຫຼ່ງ. ໂດຍເນື້ອແທ້ແລ້ວຂອງ CFS ແມ່ນການແຈກຢາຍເວລາຂອງໂປເຊດເຊີລະຫວ່າງຂະບວນການໂດຍອີງຕາມໄລຍະເວລາຂອງການປະຕິບັດຂອງພວກເຂົາ. ເວລາ CPU ຫຼາຍຂະບວນການຕ້ອງການ, ເວລາ CPU ໜ້ອຍລົງ. ນີ້ຮັບປະກັນວ່າຂະບວນການທັງຫມົດຖືກປະຕິບັດ "ຍຸດຕິທໍາ" - ດັ່ງນັ້ນຂະບວນການຫນຶ່ງບໍ່ໄດ້ຄອບຄອງໂປເຊດເຊີທັງຫມົດຢ່າງຕໍ່ເນື່ອງ, ແລະຂະບວນການອື່ນໆກໍ່ສາມາດປະຕິບັດໄດ້.

ບາງຄັ້ງ paradigm ນີ້ນໍາໄປສູ່ການປອມທີ່ຫນ້າສົນໃຈ. ຜູ້ໃຊ້ Linux ທີ່ໃຊ້ເວລາດົນນານອາດຈະຈື່ຈໍາການແຊ່ແຂງຂອງຕົວແກ້ໄຂຂໍ້ຄວາມປົກກະຕິຢູ່ໃນ desktop ໃນຂະນະທີ່ແລ່ນຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ຊັບພະຍາກອນເຊັ່ນ compiler. ນີ້ເກີດຂຶ້ນຍ້ອນວ່າວຽກງານທີ່ບໍ່ແມ່ນຊັບພະຍາກອນຫຼາຍໃນແອັບພລິເຄຊັນ desktop ແຂ່ງຂັນກັບວຽກງານທີ່ໃຊ້ຊັບພະຍາກອນ, ເຊັ່ນ: compiler. CFS ຄິດວ່ານີ້ບໍ່ຍຸຕິທໍາ, ສະນັ້ນມັນຢຸດຕົວແກ້ໄຂຂໍ້ຄວາມເປັນໄລຍະແລະໃຫ້ໂປເຊດເຊີຈັດການວຽກງານຂອງຜູ້ລວບລວມຂໍ້ມູນ. ນີ້ໄດ້ຖືກແກ້ໄຂໂດຍໃຊ້ກົນໄກ sche_autogroup, ແຕ່ລັກສະນະອື່ນໆຈໍານວນຫຼາຍຂອງການແຈກຢາຍເວລາຂອງໂປເຊດເຊີລະຫວ່າງຫນ້າວຽກຍັງຄົງຢູ່. ຕົວຈິງແລ້ວ, ນີ້ບໍ່ແມ່ນເລື່ອງກ່ຽວກັບວ່າທຸກສິ່ງທຸກຢ່າງທີ່ບໍ່ດີຢູ່ໃນ CFS, ແຕ່ຄວາມພະຍາຍາມທີ່ຈະດຶງດູດຄວາມສົນໃຈກັບຄວາມຈິງທີ່ວ່າການແຈກຢາຍເວລາຂອງໂປເຊດເຊີ "ຍຸດຕິທໍາ" ບໍ່ແມ່ນວຽກທີ່ຫຍຸ້ງຍາກທີ່ສຸດ.

ຈຸດສໍາຄັນອີກອັນນຶ່ງໃນຕົວກໍານົດເວລາແມ່ນການຈອງລ່ວງໜ້າ. ນີ້ແມ່ນສິ່ງຈໍາເປັນເພື່ອເລີ່ມຕົ້ນຂະບວນການ snickering ຈາກໂຮງງານຜະລິດແລະໃຫ້ຄົນອື່ນເຮັດວຽກ. ຂະບວນການ ejection ເອີ້ນວ່າ context switching, processor switching context. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ສະ​ພາບ​ການ​ທັງ​ຫມົດ​ຂອງ​ວຽກ​ງານ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ຮັກ​ສາ​ໄວ້​: ລັດ​ຂອງ stack ໄດ້​, ການ​ຈົດ​ທະ​ບຽນ​, ແລະ​ອື່ນໆ​, ຫຼັງ​ຈາກ​ນັ້ນ​ຂະ​ບວນ​ການ​ໄດ້​ຖືກ​ສົ່ງ​ໄປ​ລໍ​ຖ້າ​, ແລະ​ອີກ​ຫນຶ່ງ​ສະ​ຖານ​ທີ່​ຂອງ​ຕົນ​. ນີ້ແມ່ນການດໍາເນີນງານທີ່ມີລາຄາແພງສໍາລັບ OS ແລະບໍ່ຄ່ອຍຖືກນໍາໃຊ້, ແຕ່ບໍ່ມີຫຍັງຜິດປົກກະຕິກັບມັນ. ການປ່ຽນສະພາບການເລື້ອຍໆອາດຈະຊີ້ບອກເຖິງບັນຫາໃນ OS, ແຕ່ໂດຍປົກກະຕິແລ້ວມັນແມ່ນຢ່າງຕໍ່ເນື່ອງແລະບໍ່ຊີ້ບອກຫຍັງໂດຍສະເພາະ.

ເລື່ອງຍາວດັ່ງກ່າວແມ່ນຈໍາເປັນເພື່ອອະທິບາຍຄວາມຈິງອັນຫນຶ່ງ: ຊັບພະຍາກອນຂອງໂປເຊດເຊີຫຼາຍທີ່ຂະບວນການພະຍາຍາມບໍລິໂພກຢູ່ໃນຕົວກໍານົດເວລາ Linux ທີ່ຊື່ສັດ, ມັນຈະໄວຂຶ້ນເພື່ອໃຫ້ຂະບວນການອື່ນໆສາມາດເຮັດວຽກໄດ້. ບໍ່ວ່ານີ້ແມ່ນຖືກຕ້ອງຫຼືບໍ່ແມ່ນຄໍາຖາມທີ່ສັບສົນທີ່ສາມາດແກ້ໄຂໄດ້ພາຍໃຕ້ການໂຫຼດທີ່ແຕກຕ່າງກັນ. ໃນ Windows, ຈົນກ່ວາບໍ່ດົນມານີ້, ຕົວກໍານົດເວລາໄດ້ສຸມໃສ່ການປະມວນຜົນບູລິມະສິດຂອງຄໍາຮ້ອງສະຫມັກ desktop, ເຊິ່ງສາມາດເຮັດໃຫ້ຂະບວນການພື້ນຖານຄ້າງ. Sun Solaris ມີຫ້າຫ້ອງຮຽນທີ່ແຕກຕ່າງກັນຂອງຕາຕະລາງ. ເມື່ອພວກເຮົາເປີດຕົວ virtualization, ພວກເຮົາໄດ້ເພີ່ມອັນທີ 6, ຕາຕະລາງການແບ່ງປັນຍຸດຕິທໍາ, ເນື່ອງຈາກວ່າຫ້າທີ່ຜ່ານມາບໍ່ໄດ້ເຮັດວຽກຢ່າງພຽງພໍກັບ Solaris Zones virtualization. ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເລີ່ມຕົ້ນການສຶກສາລາຍລະອຽດກ່ຽວກັບບັນຫານີ້ກັບປື້ມເຊັ່ນ Solaris ພາຍໃນ: Solaris 10 ແລະ OpenSolaris Kernel Architecture ຫຼື ຄວາມເຂົ້າໃຈກ່ຽວກັບ Linux Kernel.

2.4. ວິທີການຕິດຕາມກວດກາການລັກ?

ການຕິດຕາມການລັກໃນເຄື່ອງ virtual, ເຊັ່ນດຽວກັນກັບຕົວຊີ້ວັດຕົວປະມວນຜົນອື່ນໆ, ແມ່ນງ່າຍດາຍ: ທ່ານສາມາດນໍາໃຊ້ເຄື່ອງມືວັດແທກຂອງໂປເຊດເຊີໃດໆ. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າເຄື່ອງ virtual ແມ່ນຢູ່ໃນ Linux. ສໍາລັບເຫດຜົນບາງຢ່າງ Windows ບໍ່ໄດ້ສະຫນອງຂໍ້ມູນນີ້ໃຫ້ກັບຜູ້ໃຊ້ຂອງມັນ. 🙁

ຜົນໄດ້ຮັບຂອງຄໍາສັ່ງເທິງ: ລາຍລະອຽດຂອງການໂຫຼດຂອງໂປເຊດເຊີ, ໃນຖັນຂວາສຸດ - ລັກ

ຄວາມຫຍຸ້ງຍາກເກີດຂື້ນໃນເວລາທີ່ພະຍາຍາມເອົາຂໍ້ມູນນີ້ຈາກ hypervisor. ທ່ານສາມາດພະຍາຍາມຄາດຄະເນການລັກໃນເຄື່ອງໂຮດ, ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້ພາລາມິເຕີ Load Average (LA) - ມູນຄ່າສະເລ່ຍຂອງຈໍານວນຂະບວນການລໍຖ້າຢູ່ໃນແຖວການປະຕິບັດ. ວິທີການຄິດໄລ່ພາລາມິເຕີນີ້ແມ່ນບໍ່ງ່າຍດາຍ, ແຕ່ໂດຍທົ່ວໄປ, ຖ້າ LA normalized ໂດຍຈໍານວນຂອງກະທູ້ຂອງໂປເຊດເຊີແມ່ນຫຼາຍກ່ວາ 1, ນີ້ຊີ້ໃຫ້ເຫັນວ່າເຄື່ອງແມ່ຂ່າຍຂອງ Linux ແມ່ນ overloaded ກັບບາງສິ່ງບາງຢ່າງ.

ຂະບວນການທັງຫມົດເຫຼົ່ານີ້ລໍຖ້າຫຍັງ? ຄໍາຕອບທີ່ຊັດເຈນແມ່ນໂປເຊດເຊີ. ແຕ່ຄໍາຕອບແມ່ນບໍ່ຖືກຕ້ອງທັງຫມົດ, ເພາະວ່າບາງຄັ້ງໂປເຊດເຊີແມ່ນບໍ່ເສຍຄ່າ, ແຕ່ LA ໄປຂະຫນາດ. ຈື່ໄວ້ NFS ຫຼຸດລົງແນວໃດ ແລະ LA ເຕີບໂຕແນວໃດ. ດຽວກັນສາມາດເກີດຂຶ້ນກັບແຜ່ນແລະອຸປະກອນ input / output ອື່ນໆ. ແຕ່ໃນຄວາມເປັນຈິງ, ຂະບວນການສາມາດລໍຖ້າການສິ້ນສຸດຂອງການລັອກໃດກໍ່ຕາມ, ທາງດ້ານຮ່າງກາຍ, ທີ່ກ່ຽວຂ້ອງກັບອຸປະກອນ I/O, ຫຼືຢ່າງມີເຫດຜົນ, ເຊັ່ນ mutex. ນີ້ຍັງລວມເຖິງການລັອກໃນລະດັບຂອງຮາດແວ (ການຕອບສະຫນອງດຽວກັນຈາກແຜ່ນ), ຫຼືເຫດຜົນ (ອັນທີ່ເອີ້ນວ່າ locking primitives, ເຊິ່ງປະກອບມີຊໍ່ຂອງຫນ່ວຍງານ, mutex adaptive ແລະ spin, semaphores, ຕົວແປເງື່ອນໄຂ, locks rw, locks ipc. ...).

ລັກສະນະອື່ນຂອງ LA ແມ່ນວ່າມັນຖືກພິຈາລະນາເປັນລະບົບປະຕິບັດງານໂດຍສະເລ່ຍ. ສໍາລັບຕົວຢ່າງ, 100 ຂະບວນການແຂ່ງຂັນສໍາລັບຫນຶ່ງໄຟລ໌, ແລະຫຼັງຈາກນັ້ນ LA=50. ມູນຄ່າຂະຫນາດໃຫຍ່ດັ່ງກ່າວເບິ່ງຄືວ່າຈະຊີ້ໃຫ້ເຫັນວ່າລະບົບປະຕິບັດການບໍ່ດີ. ແຕ່ສໍາລັບລະຫັດທີ່ຂຽນຜິດອື່ນໆ, ນີ້ອາດຈະເປັນສະຖານະປົກກະຕິ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າພຽງແຕ່ມັນບໍ່ດີ, ແລະຂະບວນການອື່ນໆໃນລະບົບປະຕິບັດການບໍ່ທົນທຸກ.

ເນື່ອງຈາກວ່ານີ້ໂດຍສະເລ່ຍ (ແລະບໍ່ຫນ້ອຍກວ່າຫນຶ່ງນາທີ), ການກໍານົດສິ່ງໃດແດ່ໂດຍຕົວຊີ້ວັດ LA ບໍ່ແມ່ນວຽກທີ່ໄດ້ຮັບລາງວັນທີ່ສຸດ, ມີຜົນໄດ້ຮັບທີ່ບໍ່ແນ່ນອນຫຼາຍໃນກໍລະນີສະເພາະ. ຖ້າທ່ານພະຍາຍາມຄິດໄລ່ມັນ, ທ່ານຈະພົບວ່າບົດຄວາມໃນ Wikipedia ແລະຊັບພະຍາກອນອື່ນໆທີ່ອະທິບາຍພຽງແຕ່ກໍລະນີທີ່ງ່າຍດາຍທີ່ສຸດ, ໂດຍບໍ່ມີການອະທິບາຍຢ່າງເລິກເຊິ່ງກ່ຽວກັບຂະບວນການ. ຂ້ອຍສົ່ງທຸກຄົນທີ່ສົນໃຈ, ອີກເທື່ອຫນຶ່ງ, ຢູ່ທີ່ນີ້ເພື່ອ Brendan Gregg  - ປະ​ຕິ​ບັດ​ຕາມ​ການ​ເຊື່ອມ​ຕໍ່​ຂ້າງ​ລຸ່ມ​ນີ້​. ໃຜຂີ້ຄ້ານເວົ້າພາສາອັງກິດ - ການແປບົດຄວາມຍອດນິຍົມຂອງລາວກ່ຽວກັບ LA.

3. ຜົນກະທົບພິເສດ

ບັດ​ນີ້​ໃຫ້​ເຮົາ​ມາ​ເບິ່ງ​ກໍລະນີ​ຕົ້ນ​ຕໍ​ຂອງ​ການ​ລັກລອບ​ທີ່​ພວກ​ເຮົາ​ພົບ​ເຫັນ. ຂ້າພະເຈົ້າຈະບອກທ່ານວ່າພວກເຂົາປະຕິບັດຕາມຈາກທັງຫມົດຂ້າງເທິງແລະວິທີການທີ່ພວກມັນພົວພັນກັບຕົວຊີ້ວັດໃນ hypervisor.

ການຣີໄຊເຄິນ. ງ່າຍທີ່ສຸດແລະທົ່ວໄປທີ່ສຸດ: hypervisor ໄດ້ຖືກນໍາໃຊ້ຄືນໃຫມ່. ແທ້ຈິງແລ້ວ, ມີຫຼາຍເຄື່ອງ virtual ແລ່ນ, ການບໍລິໂພກຂອງໂປເຊດເຊີສູງພາຍໃນພວກມັນ, ການແຂ່ງຂັນຫຼາຍ, ການນໍາໃຊ້ LA ແມ່ນຫຼາຍກ່ວາ 1 (ປົກກະຕິໂດຍກະທູ້ໂປເຊດເຊີ). ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນເຄື່ອງ virtual ທັງຫມົດຊ້າລົງ. ການລັກຖ່າຍທອດຈາກ hypervisor ແມ່ນຍັງເຕີບໃຫຍ່, ມັນຈໍາເປັນຕ້ອງແຈກຢາຍການໂຫຼດໃຫມ່ຫຼືປິດຜູ້ໃດຜູ້ຫນຶ່ງ. ໂດຍທົ່ວໄປ, ທຸກສິ່ງທຸກຢ່າງແມ່ນມີເຫດຜົນແລະເຂົ້າໃຈໄດ້.

Paravirtualization ທຽບກັບຕົວຢ່າງດຽວ. ມີເຄື່ອງ virtual ພຽງອັນດຽວຢູ່ໃນ hypervisor; ມັນກິນສ່ວນນ້ອຍໆຂອງມັນ, ແຕ່ຜະລິດ I/O load ຂະຫນາດໃຫຍ່, ຕົວຢ່າງໃນແຜ່ນ. ແລະຈາກບ່ອນໃດບ່ອນຫນຶ່ງການລັກຂະໂມຍຂະຫນາດນ້ອຍຈະປາກົດຢູ່ໃນນັ້ນ, ເຖິງ 10% (ດັ່ງທີ່ສະແດງໃຫ້ເຫັນໂດຍການທົດລອງຫຼາຍໆຄັ້ງ).

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

ອັນນີ້ເກີດຂຶ້ນໃນຂະນະທີ່ buffer ຖືກສົ່ງ, ມັນເຂົ້າໄປໃນຊ່ອງ kernel ຂອງ hypervisor, ແລະພວກເຮົາເລີ່ມລໍຖ້າມັນ. ເຖິງແມ່ນວ່າ, ຈາກທັດສະນະຂອງເຄື່ອງ virtual, ລາວຄວນຈະກັບຄືນມາທັນທີ. ດັ່ງນັ້ນ, ອີງຕາມສູດການຄິດໄລ່ການລັກ, ເວລານີ້ຖືວ່າຖືກລັກ. ສ່ວນຫຼາຍອາດຈະ, ໃນສະຖານະການນີ້ອາດຈະມີກົນໄກອື່ນໆ (ຕົວຢ່າງ, ການປະມວນຜົນບາງການໂທ sys), ແຕ່ພວກເຂົາບໍ່ຄວນແຕກຕ່າງກັນຫຼາຍ.

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

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

LA ຕ່ໍາ, ແຕ່ມີການລັກ. ຖ້າ LA ແມ່ນປະມານ 0,7 (ນັ້ນແມ່ນ, hypervisor ເບິ່ງຄືວ່າຖືກໂຫຼດຫນ້ອຍ), ແຕ່ການລັກແມ່ນສັງເກດເຫັນຢູ່ໃນເຄື່ອງ virtual ສ່ວນບຸກຄົນ:

• ທາງເລືອກທີ່ມີ paravirtualization ໄດ້ອະທິບາຍໄວ້ຂ້າງເທິງ. ເຄື່ອງ virtual ສາມາດໄດ້ຮັບ metrics ຊີ້ບອກລັກ, ເຖິງແມ່ນວ່າ hypervisor ແມ່ນດີ. ອີງຕາມຜົນຂອງການທົດລອງຂອງພວກເຮົາ, ທາງເລືອກການລັກນີ້ບໍ່ເກີນ 10% ແລະບໍ່ຄວນມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການປະຕິບັດຂອງແອັບພລິເຄຊັນພາຍໃນເຄື່ອງ virtual.
• ພາລາມິເຕີ LA ຖືກຄິດໄລ່ບໍ່ຖືກຕ້ອງ. ຫຼາຍທີ່ຊັດເຈນ, ໃນແຕ່ລະຊ່ວງເວລາສະເພາະມັນຖືກຄິດໄລ່ຢ່າງຖືກຕ້ອງ, ແຕ່ເມື່ອສະເລ່ຍຫຼາຍກວ່າຫນຶ່ງນາທີມັນຈະກາຍເປັນການຄາດຄະເນຫນ້ອຍ. ຕົວຢ່າງ, ຖ້າເຄື່ອງ virtual ຫນຶ່ງຕໍ່ສາມຂອງ hypervisor ບໍລິໂພກໂປເຊດເຊີທັງຫມົດຂອງມັນສໍາລັບເຄິ່ງຫນຶ່ງນາທີ, ຫຼັງຈາກນັ້ນ LA ຕໍ່ນາທີໃນ hypervisor ຈະເປັນ 0,15; ສີ່ເຄື່ອງ virtual ດັ່ງກ່າວເຮັດວຽກພ້ອມໆກັນຈະໃຫ້ 0,6. ແລະຄວາມຈິງທີ່ວ່າສໍາລັບເຄິ່ງຫນຶ່ງນາທີໃນແຕ່ລະຂອງເຂົາເຈົ້າມີການລັກປ່າທໍາມະຊາດຢູ່ທີ່ 25% ອີງຕາມຕົວຊີ້ວັດ LA ຈະບໍ່ສາມາດດຶງອອກໄດ້.
• ອີກເທື່ອ ໜຶ່ງ, ເພາະວ່າຜູ້ຈັດຕາຕະລາງທີ່ຕັດສິນໃຈວ່າຜູ້ໃດຜູ້ ໜຶ່ງ ກິນຫຼາຍເກີນໄປແລະປ່ອຍໃຫ້ຜູ້ນັ້ນລໍຖ້າ. ໃນເວລານີ້, ຂ້ອຍຈະປ່ຽນສະພາບການ, ຈັດການການຂັດຂວາງແລະເບິ່ງແຍງລະບົບທີ່ສໍາຄັນອື່ນໆ. ດັ່ງນັ້ນ, ບາງເຄື່ອງ virtual ບໍ່ເຫັນບັນຫາໃດໆ, ໃນຂະນະທີ່ເຄື່ອງອື່ນໆປະສົບກັບການເສື່ອມສະພາບທີ່ຮ້າຍແຮງ.

4. ການບິດເບືອນອື່ນໆ

ມີຫຼາຍລ້ານເຫດຜົນສໍາລັບການບິດເບືອນຜົນຕອບແທນຍຸດຕິທໍາຂອງເວລາຂອງໂປເຊດເຊີໃນເຄື່ອງ virtual. ຕົວຢ່າງ, hyperthreading ແລະ NUMA ແນະນໍາຄວາມຫຍຸ້ງຍາກໃນການຄິດໄລ່. ພວກເຂົາສັບສົນຢ່າງສົມບູນກ່ຽວກັບທາງເລືອກຂອງແກ່ນສໍາລັບການປະຕິບັດຂະບວນການ, ເພາະວ່າຜູ້ກໍານົດເວລາໃຊ້ຄ່າສໍາປະສິດ - ນ້ໍາຫນັກ, ເຊິ່ງເຮັດໃຫ້ການຄິດໄລ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍເມື່ອປ່ຽນສະພາບການ.

ມີການບິດເບືອນເນື່ອງຈາກເຕັກໂນໂລຢີເຊັ່ນ turbo boost ຫຼື, ໃນທາງກັບກັນ, ຮູບແບບການປະຫຍັດພະລັງງານ, ເຊິ່ງ, ເມື່ອຄິດໄລ່ການນໍາໃຊ້, ສາມາດເພີ່ມຫຼືຫຼຸດລົງຄວາມຖີ່ຫຼືແມ້ກະທັ້ງເວລາໃນເຄື່ອງແມ່ຂ່າຍ. ການເປີດໃຊ້ turbo boost ຫຼຸດລົງປະສິດທິພາບຂອງສາຍປະມວນຜົນຫນຶ່ງເນື່ອງຈາກການເພີ່ມຂຶ້ນຂອງປະສິດທິພາບຂອງອື່ນ. ໃນເວລານີ້, ຂໍ້ມູນກ່ຽວກັບຄວາມຖີ່ຂອງໂປເຊດເຊີໃນປະຈຸບັນບໍ່ໄດ້ຖືກສົ່ງໄປຫາເຄື່ອງ virtual, ແລະມັນເຊື່ອວ່າຜູ້ໃດຜູ້ຫນຶ່ງກໍາລັງລັກເວລາຂອງມັນ (ຕົວຢ່າງ, ມັນໄດ້ຮ້ອງຂໍ 2 GHz, ແຕ່ໄດ້ຮັບເຄິ່ງຫນຶ່ງ).

ໂດຍທົ່ວໄປ, ມີຫຼາຍເຫດຜົນສໍາລັບການບິດເບືອນ. ທ່ານອາດຈະຊອກຫາສິ່ງອື່ນໃນລະບົບສະເພາະ. ມັນດີກວ່າທີ່ຈະເລີ່ມຕົ້ນດ້ວຍປື້ມທີ່ຂ້ອຍໃຫ້ລິ້ງຂ້າງເທິງ, ແລະການດຶງຂໍ້ມູນສະຖິຕິຈາກ hypervisor ໂດຍໃຊ້ utilities ເຊັ່ນ perf, sysdig, systemtap, ເຊິ່ງໃນນັ້ນ. ສິບ.

5. ບົດສະຫຼຸບ

1. ການລັກຂະໂມຍຈຳນວນໜຶ່ງອາດເກີດຂຶ້ນຍ້ອນການລັກຂະໂມຍ, ແລະມັນສາມາດຖືວ່າເປັນເລື່ອງປົກກະຕິ. ພວກເຂົາຂຽນໃນອິນເຕີເນັດວ່າມູນຄ່ານີ້ສາມາດເປັນ 5-10%. ແມ່ນຂຶ້ນກັບແອັບພລິເຄຊັນພາຍໃນເຄື່ອງ virtual ແລະໃນການໂຫຼດທີ່ມັນໃສ່ໃນອຸປະກອນທາງດ້ານຮ່າງກາຍຂອງມັນ. ໃນທີ່ນີ້ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເອົາໃຈໃສ່ກັບຄວາມຮູ້ສຶກຂອງຄໍາຮ້ອງສະຫມັກພາຍໃນເຄື່ອງ virtual.
2. ອັດຕາສ່ວນຂອງການໂຫຼດໃນ hypervisor ແລະການລັກພາຍໃນເຄື່ອງ virtual ແມ່ນບໍ່ສະເຫມີກັນຢ່າງຊັດເຈນ; ການຄາດຄະເນທັງສອງຂອງການລັກສາມາດຜິດພາດໃນສະຖານະການສະເພາະໃດຫນຶ່ງພາຍໃຕ້ການໂຫຼດທີ່ແຕກຕ່າງກັນ.
3. ຜູ້ຈັດຕາຕະລາງມີທັດສະນະທີ່ບໍ່ດີຕໍ່ຂະບວນການທີ່ຖາມຫຼາຍ. ພະອົງ​ພະຍາຍາມ​ໃຫ້​ຜູ້​ທີ່​ຂໍ​ຫຼາຍ​ໜ້ອຍ​ລົງ. ເຄື່ອງຈັກ virtual ຂະຫນາດໃຫຍ່ແມ່ນຊົ່ວ.
4. ການລັກເລັກນ້ອຍສາມາດເປັນມາດຕະຖານເຖິງແມ່ນວ່າໂດຍບໍ່ມີການ paravirtualization (ຄໍານຶງເຖິງການໂຫຼດພາຍໃນເຄື່ອງ virtual, ລັກສະນະຂອງການໂຫຼດຂອງເພື່ອນບ້ານ, ການແຜ່ກະຈາຍການໂຫຼດໃນທົ່ວກະທູ້ແລະປັດໃຈອື່ນໆ).
5. ຖ້າທ່ານຕ້ອງການຄິດໄລ່ການລັກໃນລະບົບສະເພາະ, ທ່ານຕ້ອງໄດ້ຄົ້ນຫາທາງເລືອກຕ່າງໆ, ເກັບກໍາຂໍ້ມູນ metrics, ວິເຄາະຢ່າງລະມັດລະວັງແລະຄິດກ່ຽວກັບວິທີການແຈກຢາຍການໂຫຼດເທົ່າທຽມກັນ. ການບ່ຽງເບນຈາກກໍລະນີໃດກໍ່ຕາມແມ່ນເປັນໄປໄດ້, ເຊິ່ງຕ້ອງໄດ້ຮັບການຢືນຢັນໃນການທົດລອງຫຼືເບິ່ງຢູ່ໃນຕົວດີບັກເຄີເນນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com