ການວິເຄາະຜົນກະທົບຂອງການປະຕິບັດຂອງແຫຼ່ງເວລາທີ່ເລືອກໃນລະບົບ

Brendan Gregg, ຫນຶ່ງໃນນັກພັດທະນາຂອງ DTrace, ຜູ້ທີ່ກໍາລັງພັດທະນາເຄື່ອງມືການວິເຄາະປະສິດທິພາບ BPF ໃນ Linux kernel, ໄດ້ສະຫຼຸບປະສົບການທີ່ໄດ້ຮັບຈາກການວິເຄາະບັນຫາການປະຕິບັດທີ່ Netflix ພົບໃນເວລາທີ່ການເຄື່ອນຍ້າຍ Cassandra DBMS ຈາກ CentOS ໄປ Ubuntu. Amazon EC2 cloud ອີງໃສ່ Xen. ຫຼັງຈາກການເຄື່ອນຍ້າຍ, ການໂຫຼດ CPU ເພີ່ມຂຶ້ນ 30% ແລະຄວາມລ່າຊ້າໃນລະຫວ່າງການດໍາເນີນການຂຽນເພີ່ມຂຶ້ນປະມານຈໍານວນດຽວກັນ. ຍ້ອນວ່າມັນຫັນອອກ, ການປະຕິບັດຂອງແອັບພລິເຄຊັນທີ່ຮຽກຮ້ອງຂໍ້ມູນເວລາຫຼາຍຂື້ນກັບແຫຼ່ງເວລາທີ່ແນ່ນອນທີ່ເລືອກໃນລະບົບ.

ໃນຕອນທໍາອິດ, ເຫດຜົນຂອງການຫຼຸດລົງຂອງການປະຕິບັດແມ່ນບໍ່ຊັດເຈນແລະການວິນິດໄສໄດ້ເລີ່ມຕົ້ນດ້ວຍການຕິດຕາມຜົນກະທົບທີ່ເປັນໄປໄດ້ຂອງການເຮັດວຽກຢ່າງຕໍ່ເນື່ອງຫຼືການເປີດຕົວເປັນໄລຍະໆຂອງຂະບວນການລະບົບທີ່ໃຊ້ຊັບພະຍາກອນໂດຍນໍາໃຊ້ຜົນປະໂຫຍດດ້ານເທິງແລະ execsnoop. ແຕ່ທຸກສິ່ງທຸກຢ່າງຊີ້ໃຫ້ເຫັນວ່າການບໍລິໂພກຊັບພະຍາກອນໄດ້ເພີ່ມຂຶ້ນໂດຍສະເພາະໃນ Cassandra DBMS, ຂຽນໃນ Java. ການປຽບທຽບການວັດແທກ profile ຂອງສອງຂະບວນການ Cassandra ທີ່ເຮັດວຽກຂະຫນານກັນໃນ CentOS ແລະ Ubuntu, ດໍາເນີນການສອບຖາມດຽວກັນ, ສະແດງໃຫ້ເຫັນວ່າປະມານ 32% ຂອງເວລາທັງຫມົດແມ່ນໃຊ້ໂທຫາ os::javaTimeMillis(), ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອໃຫ້ໄດ້ຂໍ້ມູນກ່ຽວກັບເວລາໃນປະຈຸບັນ. .

ຫຼັງຈາກນີ້, ການທົດລອງໄດ້ຖືກດໍາເນີນໂດຍທີ່ຄໍາຮ້ອງສະຫມັກ Java ງ່າຍດາຍຖືກຂຽນທີ່ເອີ້ນວ່າ System.currentTimeMillis() ວິທີການຫນຶ່ງຮ້ອຍລ້ານຄັ້ງໃນ loop. ການແລ່ນແອັບພລິເຄຊັນສະແດງໃຫ້ເຫັນວ່າມັນໃຊ້ເວລາ 13 ວິນາທີເພື່ອເຮັດສໍາເລັດໃນ CentOS, ແລະປະມານ 68 ວິນາທີໃນ Ubuntu, i.e. ຊ້າລົງ 5 ເທົ່າ. ໂຄງການທີ່ຄ້າຍຄືກັນໄດ້ຖືກຂຽນໄວ້ໃນ C ທີ່ເອີ້ນວ່າ gettimeofday () ປະຕິບັດຫນ້າຮ້ອຍລ້ານເທື່ອ, ແຕ່ເມື່ອປະຕິບັດ, ຜົນໄດ້ຮັບທີ່ຄ້າຍຄືກັນແມ່ນໄດ້ຮັບ.

ເນື່ອງຈາກວ່າມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າແຫຼ່ງຂອງບັນຫາແມ່ນຫນ້າທີ່ຂອງການກັບຄືນເວລາໃນປະຈຸບັນ, ຄວາມສົນໃຈໄດ້ຫັນໄປສູ່ການປ່ຽນແປງຕົວຊີ້ວັດໃນເວລາທີ່ເລືອກແຫຼ່ງທີ່ແຕກຕ່າງກັນຂອງເວລາທີ່ແນ່ນອນໃນລະບົບ. ການຕັດສິນໂດຍເນື້ອໃນຂອງ “/sys/devices/system/clocksource/clocksource0/current_clocksource”, ເຄື່ອງຈັບເວລາ “xen” ຖືກໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນເມື່ອແລ່ນ Linux ໃນລະບົບແຂກ. ຫຼັງຈາກປ່ຽນແຫຼ່ງເວລາເປັນ "tsc", ເວລາປະຕິບັດຂອງຄໍາຮ້ອງສະຫມັກການທົດສອບໃນ Ubuntu ຫຼຸດລົງຈາກ 68 ຫາ 3.3 ວິນາທີ, i.e. ມັນກາຍມາເປັນ 20 ເທົ່າໄວ. ນອກຈາກນັ້ນ, ການທົດສອບການປະຕິບັດຂອງແຫຼ່ງເວລາ kvm-clock ໄດ້ຖືກປະຕິບັດ, ເຊິ່ງສະແດງໃຫ້ເຫັນເຖິງການຊັກຊ້າເພີ່ມຂຶ້ນ 20% ເມື່ອທຽບກັບ TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s user 0m38.337s $ sys.0m. echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $time java TimeBench real 0m0s ຜູ້ໃຊ້ 3.370m0s sys 3.353m0s

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

ການປ່ຽນເຊີບເວີການຜະລິດຢູ່ Netflix ໄປຫາແຫຼ່ງ TSC ເຮັດໃຫ້ມີການຫຼຸດລົງ 43% ໃນການຂຽນ latency ແລະບັນລຸຜົນໄດ້ຮັບໂດຍໃຊ້ Ubuntu ທີ່ໄວກວ່າການຕັ້ງຄ່າທີ່ໃຊ້ CentOS 4 ເທົ່າດ້ວຍແຫຼ່ງເວລາ "xen". ຜົນໄດ້ຮັບຂອງການສຶກສາໄດ້ຖືກໂອນໄປຫາ Amazon, ເຊິ່ງແນະນໍາຢ່າງເປັນທາງການໂດຍໃຊ້ແຫຼ່ງເວລາ TSC ເລີ່ມຕົ້ນໃນສະພາບແວດລ້ອມ AWS EC2 ໂດຍອີງໃສ່ Xen hypervisor (kvm-clock ຍັງຄົງຖືກແນະນໍາໃນສະພາບແວດລ້ອມໂດຍອີງໃສ່ Nitro hypervisor).

ແຫຼ່ງຂໍ້ມູນ: opennet.ru