ເປັນຫຍັງການຈັດສັນ C++ (m) ທຳອິດຈຶ່ງເປັນ 72 KB?

ຄວາມລຶກລັບທີ່ຢູ່ເບື້ອງຫຼັງການຈັດສັນ C++ ທໍາອິດຂອງເຈົ້າ

ທ່ານຂຽນໂປຣແກຣມ C++ ງ່າຍໆ. ໃໝ່ int ດຽວ. ສີ່ bytes. ທ່ານດັບໄຟ strace ຫຼືໂປໄຟເຊີຫນ່ວຍຄວາມຈໍາທີ່ທ່ານມັກ, ແລະມີ - ຂະບວນການຂອງທ່ານພຽງແຕ່ຮ້ອງຂໍປະມານ 72 KB ຈາກລະບົບປະຕິບັດການ. ບໍ່ແມ່ນ 4 bytes. ບໍ່ແມ່ນ 64 bytes. ເຕັມ 72 KB. ຖ້າທ່ານເຄີຍເບິ່ງຕົວເລກນັ້ນແລະສົງໄສວ່າເຄື່ອງມືຂອງເຈົ້າໄດ້ຕົວະເຈົ້າ, ເຈົ້າບໍ່ໄດ້ຢູ່ຄົນດຽວ. ພຶດຕິກໍາທີ່ແປກປະຫຼາດນີ້ແມ່ນຫນຶ່ງໃນຄໍາຖາມທີ່ພົບເລື້ອຍທີ່ສຸດໃນບັນດານັກພັດທະນາ C++ ທີ່ຂຸດເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາພາຍໃນຄັ້ງທໍາອິດ, ແລະຄໍາຕອບນໍາພວກເຮົາໄປສູ່ການເດີນທາງທີ່ຫນ້າປະທັບໃຈຜ່ານຊັ້ນທີ່ຕັ້ງຢູ່ລະຫວ່າງລະຫັດຂອງເຈົ້າແລະຮາດແວຕົວຈິງ.

ຈະເກີດຫຍັງຂຶ້ນເມື່ອທ່ານໂທຫາ ໃໝ່

ເພື່ອເຂົ້າໃຈຕົວເລກ 72 KB, ທ່ານຈໍາເປັນຕ້ອງຕິດຕາມຕ່ອງໂສ້ການຈັດສັນອັນເຕັມທີ່. ເມື່ອລະຫັດ C++ ຂອງທ່ານປະຕິບັດ int ໃຫມ່, compiler ແປເປັນການໂທໄປຫາ operator ໃຫມ່, ເຊິ່ງໃນລະບົບ Linux ສ່ວນໃຫຍ່ມອບຫມາຍໃຫ້ malloc ຈາກ glibc. ແຕ່ malloc ບໍ່ໄດ້ຖາມ kernel ໂດຍກົງສໍາລັບ 4 bytes ຂອງຫນ່ວຍຄວາມຈໍາ. kernel ເຮັດວຽກຢູ່ໃນຫນ້າຕ່າງໆ - ໂດຍປົກກະຕິ 4 KB ໃນ x86_64 - ແລະຄ່າໃຊ້ຈ່າຍຂອງການໂທລະບົບແມ່ນໃຫຍ່ຫຼວງທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາທີ່ງ່າຍດາຍ. ການໂທຫາ brk() ຫຼື mmap() ສໍາລັບການຈັດສັນແຕ່ລະບຸກຄົນຈະເຮັດໃຫ້ໂຄງການທີ່ບໍ່ແມ່ນເລື່ອງເລັກໆນ້ອຍໆຢຸດຢັ້ງ.

ແທນທີ່ຈະ, ຕົວຈັດສັນຄວາມຈຳຂອງ glibc — ການປະຕິບັດທີ່ເອີ້ນວ່າ ptmalloc2, ຕົວຂອງມັນເອງໄດ້ມາຈາກ dlmalloc ແບບຄລາສສິກຂອງ Doug Lea — ເຮັດໜ້າທີ່ເປັນຄົນກາງ. ມັນຮ້ອງຂໍໃຫ້ຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່ຈາກ kernel ຢູ່ທາງຫນ້າ, ຫຼັງຈາກນັ້ນແກະໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນຕ່ອນຂະຫນາດນ້ອຍຕາມທີ່ໂຄງການຂອງທ່ານຕ້ອງການໃຫ້ເຂົາເຈົ້າ. ນີ້ແມ່ນເຫດຜົນພື້ນຖານການຈັດສັນ 4-byte ທໍາອິດຂອງທ່ານເຮັດໃຫ້ເກີດການຮ້ອງຂໍທີ່ໃຫຍ່ກວ່າກັບລະບົບປະຕິບັດການ. ຜູ້ຈັດສັນແມ່ນບໍ່ເປັນສິ່ງເສດເຫຼືອ. ມັນ​ເປັນ​ຍຸດ​ທະ​ສາດ.

ການແຍກ 72 KB: ບ່ອນທີ່ Bytes ໄປ

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

ທຳອິດ, glibc's malloc ເລີ່ມຕົ້ນ ສະໜາມຫຼັກ — ໂຄງສ້າງບັນຊີຫຼັກທີ່ຕິດຕາມການຈັດສັນທັງໝົດໃນຫົວຂໍ້ຫຼັກ. ສະຫນາມກິລານີ້ປະກອບມີ metadata ສໍາລັບ heap, ຕົວຊີ້ລາຍຊື່ຟຣີ, ແລະໂຄງສ້າງຖັງສໍາລັບຂະຫນາດການຈັດສັນທີ່ແຕກຕ່າງກັນ. ຜູ້ຈັດສັນຂະຫຍາຍການຢຸດໂຄງການຜ່ານ sbrk(), ແລະສ່ວນຂະຫຍາຍເບື້ອງຕົ້ນແມ່ນຄວບຄຸມໂດຍພາລາມິເຕີພາຍໃນທີ່ເອີ້ນວ່າ M_TOP_PAD, ເຊິ່ງຄ່າເລີ່ມຕົ້ນເປັນ 128 KB ຂອງ padding. ແນວໃດກໍ່ຕາມ, ການຮ້ອງຂໍເບື້ອງຕົ້ນຕົວຈິງແມ່ນຖືກປັບເພື່ອຈັດຮຽງໜ້າ ແລະ ຕຳແໜ່ງການແບ່ງທີ່ມີຢູ່, ເຊິ່ງມັກຈະສົ່ງຜົນໃຫ້ຄຳຮ້ອງຂໍທຳອິດທີ່ນ້ອຍກວ່າ - ໂດຍທົ່ວໄປແລ້ວຈະລົງຈອດໃກ້ກັບຕົວເລກ 72 KB ຢູ່ໃນຂະບວນການທີ່ເລີ່ມຕົ້ນໃໝ່ໆ.

ອັນທີສອງ, ນັບຕັ້ງແຕ່ glibc 2.26, ຜູ້ຈັດສັນເລີ່ມຕົ້ນເປັນ thread-local cache (tcache) ໃນຄັ້ງທໍາອິດ. tcache ມີ 64 bins (ຫນຶ່ງຕໍ່ຂະຫນາດການຈັດສັນຂະຫນາດນ້ອຍ), ແຕ່ລະຄົນສາມາດຖືໄດ້ເຖິງ 7 chunks cache. tcache_perthread_struct ຕົວມັນເອງໃຊ້ພື້ນທີ່ປະມານ 1 KB, ແຕ່ການປະຕິບັດການເລີ່ມຕົ້ນຂອງມັນເຮັດໃຫ້ເກີດການຕັ້ງຄ່າສະຫນາມກິລາທີ່ກວ້າງຂຶ້ນ. ອັນທີສາມ, C++ runtime ໄດ້ປະຕິບັດການຈັດສັນກ່ອນທີ່ main() ຂອງເຈົ້າຈະແລ່ນໄປກ່ອນແລ້ວ — static constructors, iostream buffer initialization for std::cout and friends, and locale setup all contribute to that heap footprint.

ລະບົບ Arena ແລະເປັນຫຍັງການຈັດສັນລ່ວງໜ້າຈຶ່ງສະຫຼາດ

ການ​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ຈັດ​ສັນ​ສ່ວນ​ຄວາມ​ຊົງ​ຈໍາ​ເປັນ​ຈໍາ​ນວນ​ຫຼວງ​ຫຼາຍ​ແທນ​ທີ່​ຈະ​ເປັນ​ການ​ຮ້ອງ​ຂໍ​ໃຫ້​ບາງ​ສ່ວນ​ບໍ່​ແມ່ນ​ອຸ​ບັດ​ຕິ​ເຫດ​ຂອງ​ການ​ປະ​ຕິ​ບັດ​. ມັນເປັນການແລກປ່ຽນດ້ານວິສະວະກໍາໂດຍເຈດຕະນາທີ່ຮາກຖານຢູ່ໃນປະສົບການການດໍາເນີນໂຄງການລະບົບຫຼາຍທົດສະວັດ. ທຸກໆການໂທໄປຫາ brk() ຫຼື mmap() ກ່ຽວຂ້ອງກັບການປ່ຽນບໍລິບົດຈາກພື້ນທີ່ຜູ້ໃຊ້ໄປຫາພື້ນທີ່ kernel, ການແກ້ໄຂແຜນທີ່ຫນ່ວຍຄວາມຈໍາ virtual ຂອງຂະບວນການ, ແລະການປັບປຸງຕາຕະລາງຫນ້າທີ່ເປັນໄປໄດ້. ໃນຮາດແວທີ່ທັນສະໄຫມ, ການໂທລະບົບດຽວມີຄ່າໃຊ້ຈ່າຍປະມານ 100-200 nanoseconds — ເລັກນ້ອຍໃນການໂດດດ່ຽວ, ໄພພິບັດໃນລະດັບຂະຫນາດ.

ພິຈາລະນາໂຄງການທີ່ເຮັດໃຫ້ 10,000 ການຈັດສັນຂະຫນາດນ້ອຍໃນລະຫວ່າງການເລີ່ມຕົ້ນ. ໂດຍບໍ່ມີການຈັດສັນກ່ອນ, ນັ້ນຫມາຍຄວາມວ່າ 10,000 ການໂທລະບົບ, ຄ່າໃຊ້ຈ່າຍປະມານ 1-2 milliseconds ຂອງ overhead ບໍລິສຸດ. ດ້ວຍຜູ້ຈັດສັນທີ່ອີງໃສ່ສະຫນາມກິລາ, ການຈັດສັນທໍາອິດເຮັດໃຫ້ເກີດການໂທລະບົບດຽວ, ແລະການຈັດສັນ 9,999 ຕໍ່ມາແມ່ນໃຫ້ບໍລິການທັງຫມົດໃນພື້ນທີ່ຜູ້ໃຊ້ໂດຍຜ່ານການປະຕິບັດເລກຄະນິດຊີ້ແລະການເຊື່ອມໂຍງ - ແຕ່ລະໃຊ້ເວລາປະມານ 10-50 nanoseconds. ຄະນິດສາດແມ່ນບໍ່ຊັດເຈນ: ການຈັດສັນກ່ອນຈະຊະນະຕາມລຳດັບຂະໜາດ.

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

ຄວາມຊົງຈຳ Virtual vs. Physical Memory: ເປັນຫຍັງມັນບໍ່ສຳຄັນ

ຄວາມ​ເປັນ​ຫ່ວງ​ທົ່ວ​ໄປ​ຂອງ​ຜູ້​ພັດ​ທະ​ນາ​ທີ່​ປະ​ເຊີນ​ກັບ​ພຶດ​ຕິ​ກຳ​ນີ້​ເປັນ​ຄັ້ງ​ທຳ​ອິດ​ແມ່ນ​ການ​ເສຍ​ຊັບ​ພະ​ຍາ​ກອນ. ຖ້າຂ້ອຍຕ້ອງການພຽງແຕ່ 4 bytes, ເປັນຫຍັງໂປຼແກຼມຂອງຂ້ອຍຈຶ່ງໃຊ້ 72 KB? ຄວາມເຂົ້າໃຈທີ່ສໍາຄັນແມ່ນວ່າ ຄວາມຊົງຈໍາ virtual ບໍ່ແມ່ນຄວາມຊົງຈໍາທາງດ້ານຮ່າງກາຍ. ເມື່ອ glibc ຂະຫຍາຍການຢຸດໂຄງການໂດຍ 72 KB, kernel ປັບປຸງແຜນທີ່ຫນ່ວຍຄວາມຈໍາ virtual ຂອງຂະບວນການ, ແຕ່ມັນບໍ່ກັບຄືນຫນ້າເຫຼົ່ານັ້ນດ້ວຍ RAM ທາງດ້ານຮ່າງກາຍ. ຫນ້າຕົວຈິງແມ່ນຖືກຈັດສັນຕາມຄວາມຕ້ອງການໂດຍຜ່ານ ຄວາມຜິດຂອງຫນ້າ — ພຽງແຕ່ໃນເວລາທີ່ໂຄງການຂອງທ່ານຂຽນໄປຫາທີ່ຢູ່ສະເພາະທີ່ kernel ມອບຫມາຍຫນ້າທີ່ແທ້ຈິງຂອງຫນ່ວຍຄວາມຈໍາໃຫ້ກັບມັນ.

ນີ້ຫມາຍຄວາມວ່າເຖິງແມ່ນວ່າຂະຫນາດ virtual ຂອງຂະບວນການຂອງທ່ານເພີ່ມຂຶ້ນ 72 KB, ຂະຫນາດທີ່ກໍານົດໄວ້ທີ່ຢູ່ອາໄສ (RSS) ຂອງມັນ - ຈໍານວນ RAM ຕົວຈິງທີ່ບໍລິໂພກ - ເພີ່ມຂຶ້ນພຽງແຕ່ຫນ້າທີ່ທ່ານສໍາຜັດຕົວຈິງ. ສຳລັບ ໃໝ່ int ອັນດຽວ, ນັ້ນຄືໜ້າເວັບ 4 KB ໂດຍປົກກະຕິ, ບວກກັບໜ້າໃດກໍໄດ້ທີ່ metadata ຂອງສະໜາມກິລາຄອບຄອງ. ພື້ນທີ່ສະເໝືອນຈິງທີ່ຍັງເຫຼືອຢູ່ນັ້ນ, ພ້ອມໃຫ້ນຳໃຊ້, ບໍ່ເສຍຄ່າໃຊ້ຈ່າຍຫຍັງ ນອກຈາກພື້ນທີ່ທີ່ຢູ່ — ເຊິ່ງໃນນັ້ນເຈົ້າມີ 128 TB ໃນລະບົບ Linux 64-bit.

ຄວາມແຕກຕ່າງນີ້ແມ່ນມີຄວາມສຳຄັນຫຼາຍເມື່ອສ້າງໂປຣໄຟລ໌ ແລະຕິດຕາມການນຳໃຊ້ການຜະລິດ. ຖ້າທ່ານກໍາລັງສ້າງຊອບແວທີ່ຕ້ອງຕິດຕາມການບໍລິໂພກຊັບພະຍາກອນທີ່ແທ້ຈິງ — ບໍ່ວ່າຈະເປັນ backend SaaS, microservice, ຫຼືທໍ່ການວິເຄາະທີ່ເຮັດວຽກຢູ່ໃນເວທີເຊັ່ນ Mewayz ສໍາລັບການດໍາເນີນທຸລະກິດ, ທ່ານຄວນຕິດຕາມກວດກາ RSS ແທນທີ່ຈະກ່ວາຂະຫນາດ virtual. ເຄື່ອງມືເຊັ່ນ /proc/[pid]/smaps, valgrind --tool=massif, ແລະ pmap ສາມາດໃຫ້ຄວາມຊົງຈຳທາງກາຍຍະພາບທີ່ຖືກຕ້ອງແກ່ເຈົ້າ ແທນທີ່ຈະເຮັດໃຫ້ຕົວເລກຄວາມຊົງຈຳສະເໝືອນທີ່ເຂົ້າໃຈຜິດ.

ຜູ້ຈັດສັນທີ່ແຕກຕ່າງກັນຈັດການກັບການຈັດສັນທຳອິດແນວໃດ

ຕົວເລກ 72 KB ແມ່ນສະເພາະກັບ ptmalloc2 ຂອງ glibc. ຜູ້ຈັດສັນອື່ນເຮັດໃຫ້ການຊື້ຂາຍທີ່ແຕກຕ່າງກັນ, ແລະການຈັດສັນເບື້ອງຕົ້ນແມ່ນແຕກຕ່າງກັນຕາມຄວາມເຫມາະສົມ. ການເຂົ້າໃຈຄວາມແຕກຕ່າງເຫຼົ່ານີ້ແມ່ນມີຄ່າເມື່ອເລືອກຜູ້ຈັດສັນສຳລັບແອັບພລິເຄຊັນທີ່ລະອຽດອ່ອນ.

• jemalloc (ໃຊ້ໂດຍ Facebook, FreeBSD) — ໃຊ້ໂຄງສ້າງສະຫນາມກິລາທີ່ມີຄວາມລະອຽດຫຼາຍຂຶ້ນກັບບ່ອນເກັບຂໍ້ມູນຂອງ thread-local. ຄ່າ overhead ເບື້ອງຕົ້ນມີແນວໂນ້ມທີ່ຈະສູງກວ່າ (ເລື້ອຍໆ 200+ KB) ແຕ່ໃຫ້ປະສິດທິພາບຫຼາຍ threaded ທີ່ດີກວ່າເນື່ອງຈາກການຂັດກັນຂອງ lock ຫຼຸດລົງ.
• tcmalloc (Google's Thread-Caching Malloc) — ຈັດສັນແຄສຕໍ່ກະທູ້ປະມານ 2 MB ຕາມຄ່າເລີ່ມຕົ້ນ, ດ້ວຍການຈັດສັນລ່ວງໜ້າລ່ວງໜ້າ. ຄ່າໃຊ້ຈ່າຍເບື້ອງຕົ້ນແມ່ນສູງກວ່າ, ແຕ່ການຈັດສັນນ້ອຍໆຕາມມາແມ່ນໄວທີ່ສຸດ.
• musl libc's malloc — ໃຊ້ການອອກແບບທີ່ງ່າຍກວ່າໂດຍອີງໃສ່ mmap ສໍາລັບການຈັດສັນທັງໝົດ. ຄ່າໃຊ້ຈ່າຍເບື້ອງຕົ້ນແມ່ນໜ້ອຍທີ່ສຸດ (ມັກຈະພຽງແຕ່ 4 KB ຕໍ່ການຈັດສັນ), ແຕ່ຄ່າໃຊ້ຈ່າຍຕໍ່ການຈັດສັນແມ່ນສູງກວ່າເນື່ອງຈາກການໂທລະບົບເລື້ອຍໆ.
• mimalloc (Microsoft) — ໃຊ້ການຈັດສັນຕາມພາກສ່ວນທີ່ມີ 64 MB segments. ການຈັດສັນທຳອິດເຮັດໃຫ້ເກີດການຈອງສະເໝືອນ 64 MB (ດ້ວຍຄວາມຜູກມັດທາງກາຍຍະພາບໜ້ອຍທີ່ສຸດ), ພື້ນທີ່ທີ່ຢູ່ການຊື້ຂາຍສຳລັບພື້ນທີ່ພິເສດ ແລະ ການສົ່ງຜ່ານ.

ການເລືອກລະຫວ່າງຜູ້ຈັດສັນເຫຼົ່ານີ້ຂຶ້ນກັບວຽກຂອງເຈົ້າທັງໝົດ. ສໍາລັບຄໍາຮ້ອງສະຫມັກເຊີຟເວີທີ່ໃຊ້ເວລາດົນນານທີ່ມີການຈັດສັນຫຼາຍກະທູ້ທີ່ຫນັກຫນ່ວງ, jemalloc ຫຼື tcmalloc ປົກກະຕິຈະດີກວ່າຄ່າເລີ່ມຕົ້ນຂອງ glibc. ສໍາລັບລະບົບຝັງຕົວທີ່ມີຂໍ້ຈໍາກັດຂອງຫນ່ວຍຄວາມຈໍາ, ວິທີການທີ່ງ່າຍດາຍຂອງ musl ອາດຈະດີກວ່າເຖິງວ່າຈະມີການປ້ອນຂໍ້ມູນຕ່ໍາ. ສໍາລັບແອັບພລິເຄຊັນ desktop ແລະ server ທີ່ມີຈຸດປະສົງທົ່ວໄປສ່ວນໃຫຍ່, 72 KB ເບື້ອງຕົ້ນຂອງ ptmalloc2 ເປັນຕົວແທນໃຫ້ຄ່າເລີ່ມຕົ້ນທີ່ສົມເຫດສົມຜົນທີ່ເຮັດວຽກໄດ້ດີໂດຍບໍ່ມີການປັບ.

ການປັບແຕ່ງພຶດຕິກຳການຈັດສັນເບື້ອງຕົ້ນ

ຖ້າຄ່າເລີ່ມຕົ້ນຂອງ 72 KB ເລີ່ມຕົ້ນແມ່ນມີບັນຫາຢ່າງແທ້ຈິງສໍາລັບກໍລະນີການນໍາໃຊ້ຂອງທ່ານ - ບາງທີທ່ານກໍາລັງສ້າງຂະບວນການທີ່ມີຊີວິດຊີວາຫຼາຍພັນຂະບວນການ, ແຕ່ລະອັນເຮັດໃຫ້ການຈັດສັນພຽງແຕ່ຈໍານວນຫນ້ອຍຫນຶ່ງເທົ່ານັ້ນ - glibc ສະຫນອງຫຼາຍ tunables ຜ່ານ mallopt() ແລະຕົວແປສະພາບແວດລ້ອມຄອບຄົວ MALLOC_

ພາຣາມິເຕີ M_TOP_PAD ຄວບຄຸມຄວາມຈຳພິເສດທີ່ຜູ້ຈັດສັນຮ້ອງຂໍໃຫ້ເກີນກວ່າທີ່ຕ້ອງການໃນທັນທີ. ການຕັ້ງມັນເປັນ 0 ດ້ວຍ mallopt(M_TOP_PAD, 0) ບອກຜູ້ຈັດສັນໃຫ້ຮ້ອງຂໍພຽງແຕ່ສິ່ງທີ່ຕ້ອງການ, ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍເບື້ອງຕົ້ນຢ່າງຫຼວງຫຼາຍ. ພາຣາມິເຕີ M_MMAP_THRESHOLD ຄວບຄຸມຂະໜາດຂ້າງເທິງທີ່ການຈັດສັນໃຊ້ mmap ແທນສະໜາມກິລາ. M_TRIM_THRESHOLD ຄວບຄຸມເມື່ອໜ່ວຍຄວາມຈຳທີ່ຖືກປົດປ່ອຍຖືກສົ່ງກັບຄືນສູ່ OS. ແລະນັບຕັ້ງແຕ່ glibc 2.26, ຕົວປັບປ່ຽນ glibc.malloc.tcache_count ແລະ glibc.malloc.tcache_max ໃຫ້ທ່ານຄວບຄຸມພຶດຕິກຳແຄດຂອງກະທູ້.

ຢ່າງ​ໃດ​ກໍ​ຕາມ, ຂໍ້​ຄວນ​ລະ​ວັງ: ການ​ປັບ​ຕົວ​ກຳ​ນົດ​ການ​ເຫຼົ່າ​ນີ້​ໂດຍ​ບໍ່​ມີ​ການ​ຄາດ​ຄະ​ເນ​ຢ່າງ​ຮອບ​ຄອບ​ເກືອບ​ຈະ​ເຮັດ​ໃຫ້​ສິ່ງ​ທີ່​ຮ້າຍ​ແຮງ​ຂຶ້ນ. ຄ່າເລີ່ມຕົ້ນໄດ້ຖືກເລືອກໂດຍອີງໃສ່ການສ້າງໂປຣໄຟລ໌ໂລກທີ່ແທ້ຈິງຢ່າງກວ້າງຂວາງ, ແລະພວກມັນເປັນຕົວແທນຂອງຈຸດທີ່ຫວານສໍາລັບສ່ວນໃຫຍ່ຂອງວຽກ. ເວັ້ນເສຍແຕ່ວ່າທ່ານມີຫຼັກຖານທີ່ເຂັ້ມແຂງຈາກການຜະລິດ profileing ວ່າ malloc overhead ເປັນຄໍຂວດ - ແລະທ່ານໄດ້ວັດແທກຜົນກະທົບຂອງການປ່ຽນແປງຂອງທ່ານ - ປ່ອຍໃຫ້ຄ່າເລີ່ມຕົ້ນຢ່າງດຽວ. ການປັບແຕ່ງຜູ້ຈັດສັນກ່ອນໄວອັນຄວນແມ່ນຮູບແບບການໂກນຫນວດຢິກທີ່ຂີ້ຮ້າຍໂດຍສະເພາະທີ່ໄດ້ໃຊ້ເວລາວິສະວະກໍານັບບໍ່ຖ້ວນເພື່ອຜົນປະໂຫຍດທີ່ຂາດແຄນ.

ສິ່ງ​ນີ້​ສອນ​ພວກ​ເຮົາ​ກ່ຽວ​ກັບ​ການ​ຂຽນ​ໂປຣ​ແກຣມ​ລະບົບ

ຄວາມ​ລຶກ​ລັບ​ການ​ຈັດ​ສັນ​ຄັ້ງ​ທໍາ​ອິດ 72 KB ແມ່ນ​ຫຼັກ​ຂອງ​ມັນ​ເປັນ​ບົດ​ຮຽນ​ກ່ຽວ​ກັບ ຊັ້ນ​ຂໍ້​ມູນ​ທີ່​ບໍ່​ມີ​ຕົວ​ຕົນ. C++ ໃຫ້ທ່ານພາບລວງຕາວ່າ int ໃໝ່ ຈັດສັນ 4 bytes. ມາດຕະຖານພາສາເວົ້າແນວນັ້ນ. ຮູບແບບຈິດໃຈຂອງເຈົ້າເວົ້າແນວນັ້ນ. ແຕ່ລະຫວ່າງລະຫັດຂອງເຈົ້າກັບຮາດແວມີລະບົບທີ່ຊັບຊ້ອນຫຼາຍ — ຊ່ວງເວລາແລ່ນ C++, C library allocator, ລະບົບຍ່ອຍຂອງໜ່ວຍຄວາມຈຳສະເໝືອນຂອງ kernel, ແລະ MMU ແລະ TLB ຂອງຮາດແວ — ແຕ່ລະອັນຈະເພີ່ມພຶດຕິກຳ, ການເພີ່ມປະສິດທິພາບ ແລະສ່ວນເກີນຂອງຕົນເອງ.

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

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