ການຕັ້ງຄ່າ Linux kernel ສໍາລັບ GlusterFS

ການ​ແປ​ພາ​ສາ​ຂອງ​ບົດ​ຄວາມ​ໄດ້​ຖືກ​ກະ​ກຽມ​ໃນ​ສະ​ມາດ​ສະ​ມາດ​ຂອງ​ການ​ເລີ່ມ​ຕົ້ນ​ຂອງ​ວິ​ຊາ​ການ "ຜູ້ເບິ່ງແຍງລະບົບ Linux. ມື​ອາ​ຊີບ".

ບາງຄັ້ງ, ທີ່ນີ້ແລະມີຄໍາຖາມກ່ຽວກັບຄໍາແນະນໍາຂອງ Gluster ກ່ຽວກັບການປັບແຕ່ງ kernel ແລະບໍ່ວ່າມັນເປັນສິ່ງຈໍາເປັນ.

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

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ນີ້ເຮັດວຽກໄດ້ດີ, ແຕ່ພາຍໃຕ້ການໂຫຼດຫນັກ, ມັນສາມາດເຮັດໃຫ້ເກີດບັນຫາ.

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

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

ໃນເວລາທີ່ມັນມາກັບການຕັ້ງຄ່າຫນ່ວຍຄວາມຈໍາ, ສະຖານທີ່ທໍາອິດທີ່ຈະເບິ່ງແມ່ນລະບົບຍ່ອຍຫນ່ວຍຄວາມຈໍາ virtual (VM), ທີ່ມີຈໍານວນຫລາຍທາງເລືອກທີ່ສາມາດສັບສົນທ່ານ.

vm. swappiness

Parameter vm.swappiness ກໍານົດຈໍານວນ kernel ໃຊ້ swap ເມື່ອທຽບກັບ RAM. ມັນຍັງຖືກກໍານົດໄວ້ໃນລະຫັດແຫຼ່ງເປັນ "ແນວໂນ້ມທີ່ຈະລັກຄວາມຊົງຈໍາທີ່ມີແຜນທີ່." ມູນຄ່າ swappiness ສູງຫມາຍຄວາມວ່າ kernel ຈະມີຄວາມສ່ຽງຫຼາຍທີ່ຈະ swapping ຫນ້າທີ່ແຜນທີ່. ຄ່າ swappiness ຕໍ່າຫມາຍຄວາມວ່າກົງກັນຂ້າມ: kernel ຈະ swap ຫນ້າອອກຈາກຫນ່ວຍຄວາມຈໍາຫນ້ອຍ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມູນຄ່າທີ່ສູງຂຶ້ນ vm.swappiness, ຫຼາຍລະບົບຈະໃຊ້ swap.

ການນໍາໃຊ້ຢ່າງກວ້າງຂວາງຂອງ swapping ແມ່ນບໍ່ຕ້ອງການທີ່ຈະ, ເນື່ອງຈາກວ່າຕັນຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນໄດ້ຖືກ loaded ແລະ unloaded ເຂົ້າໄປໃນ RAM. ຫຼາຍຄົນໂຕ້ຖຽງວ່າມູນຄ່າ swapiness ຄວນຈະສູງ, ແຕ່ໃນປະສົບການຂອງຂ້ອຍ, ການຕັ້ງມັນເປັນ "0" ຜົນໄດ້ຮັບໃນການປະຕິບັດທີ່ດີກວ່າ.

ທ່ານ​ສາ​ມາດ​ອ່ານ​ເພີ່ມ​ເຕີມ​ທີ່​ນີ້ - lwn.net/Articles/100978

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

vm.vfs_cache_pressure

ການຕັ້ງຄ່ານີ້ຄວບຄຸມຄວາມຊົງຈໍາທີ່ບໍລິໂພກໂດຍ kernel ສໍາລັບ cache directory objects ແລະ inodes (dentry and inode).

ດ້ວຍຄ່າເລີ່ມຕົ້ນຂອງ 100, kernel ຈະພະຍາຍາມປົດປ່ອຍ dentry ແລະ inode cache ໃນລັກສະນະຍຸດຕິທໍາກັບ pagecache ແລະ swapcache. ການຫຼຸດລົງຂອງ vfs_cache_pressure ເຮັດໃຫ້ kernel ຮັກສາ dentry ແລະ inode cache. ເມື່ອຄ່າແມ່ນ "0", kernel ຈະບໍ່ flush dentry ແລະ inode cache ເນື່ອງຈາກຄວາມກົດດັນຂອງຫນ່ວຍຄວາມຈໍາ, ແລະນີ້ສາມາດນໍາໄປສູ່ຄວາມຜິດພາດນອກຫນ່ວຍຄວາມຈໍາໄດ້ຢ່າງງ່າຍດາຍ. ການເພີ່ມ vfs_cache_pressure ຂ້າງເທິງ 100 ເຮັດໃຫ້ kernel ໃຫ້ຄວາມສໍາຄັນກັບ dentry ແລະ inode pageouts.

ເມື່ອໃຊ້ GlusterFS, ຜູ້ໃຊ້ຈໍານວນຫຼາຍທີ່ມີຂໍ້ມູນຂະຫນາດໃຫຍ່ແລະໄຟລ໌ຂະຫນາດນ້ອຍຫຼາຍສາມາດໃຊ້ RAM ຈໍານວນຫຼວງຫຼາຍໃນເຄື່ອງແມ່ຂ່າຍໄດ້ງ່າຍເນື່ອງຈາກ inode / dentry caching, ເຊິ່ງສາມາດນໍາໄປສູ່ການປະຕິບັດທີ່ບໍ່ດີຍ້ອນວ່າ kernel ຕ້ອງຈັດການກັບໂຄງສ້າງຂໍ້ມູນໃນລະບົບ. ດ້ວຍຄວາມຈຳ 40 GB. ການຕັ້ງຄ່າພາລາມິເຕີນີ້ສູງກວ່າ 100 ໄດ້ຊ່ວຍໃຫ້ຜູ້ໃຊ້ຫຼາຍຄົນບັນລຸຖານຄວາມຈຳທີ່ຍຸດຕິທຳ ແລະປັບປຸງການຕອບສະໜອງຂອງແກ່ນ.

vm.dirty_background_ratio ແລະ vm.dirty_ratio

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

ຕົວກໍານົດການທີສອງ (vm.dirty_ratio) ກໍານົດອັດຕາສ່ວນຂອງຫນ່ວຍຄວາມຈໍາທີ່ສາມາດຖືກຄອບຄອງໂດຍຫນ້າທີ່ເປື້ອນກ່ອນທີ່ຈະ flash ບັງຄັບເລີ່ມຕົ້ນ. ເມື່ອຮອດເກນນີ້ແລ້ວ, ຂະບວນການທັງໝົດຈະກາຍເປັນ synchronous (block) ແລະບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ດໍາເນີນການຕໍ່ໄປຈົນກ່ວາການດໍາເນີນການ I/O ເຂົາເຈົ້າຮ້ອງຂໍໃຫ້ສໍາເລັດແລະຂໍ້ມູນແມ່ນຢູ່ໃນແຜ່ນ. ດ້ວຍການໂຫຼດ I/O ສູງ, ນີ້ເຮັດໃຫ້ເກີດບັນຫາເນື່ອງຈາກບໍ່ມີການເກັບຂໍ້ມູນ ແລະຂະບວນການທັງໝົດທີ່ເຮັດ I/O ຖືກບລັອກລໍຖ້າ I/O. ນີ້ສົ່ງຜົນໃຫ້ຂະບວນການ hung ຈໍານວນຫລາຍ, ການໂຫຼດສູງ, ຄວາມບໍ່ສະຖຽນລະພາບຂອງລະບົບແລະການປະຕິບັດທີ່ບໍ່ດີ.

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

"1"> /proc/sys/vm/pagecache

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

"ເສັ້ນຕາຍ" > /sys/block/sdc/queue/scheduler

ຕົວກໍານົດເວລາ I/O ແມ່ນອົງປະກອບຂອງ Linux kernel ທີ່ຈັດການຄິວອ່ານແລະຂຽນ. ໃນທາງທິດສະດີ, ມັນດີກວ່າທີ່ຈະໃຊ້ "noop" ສໍາລັບຕົວຄວບຄຸມ RAID ທີ່ສະຫຼາດ, ເພາະວ່າ Linux ບໍ່ຮູ້ຫຍັງກ່ຽວກັບເລຂາຄະນິດທາງກາຍະພາບຂອງແຜ່ນ, ສະນັ້ນມັນມີປະສິດທິພາບຫຼາຍທີ່ຈະໃຫ້ຕົວຄວບຄຸມ, ເຊິ່ງຮູ້ເລຂາຄະນິດຂອງແຜ່ນດີ, ດໍາເນີນການຮ້ອງຂໍເປັນ. ໄວເທົ່າທີ່ຈະໄວໄດ້. ແຕ່ເບິ່ງຄືວ່າ "ເສັ້ນຕາຍ" ປັບປຸງການປະຕິບັດ. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບຕົວກໍານົດເວລາສາມາດພົບໄດ້ໃນເອກະສານສໍາລັບລະຫັດແຫຼ່ງ Linux kernel: linux/Documentation/block/*osched.txt. ແລະຂ້ອຍຍັງໄດ້ສັງເກດເຫັນການເພີ່ມຂຶ້ນຂອງການອ່ານໃນລະຫວ່າງການປະຕິບັດງານແບບປະສົມ (ການຂຽນຈໍານວນຫລາຍ).

"256" > /sys/block/sdc/queue/nr_requests

ຈໍານວນຄໍາຮ້ອງຂໍ I/O ໃນ buffer ກ່ອນທີ່ມັນຈະຖືກສົ່ງໄປຫາຜູ້ກໍານົດເວລາ. ຂະໜາດແຖວພາຍໃນຂອງຕົວຄວບຄຸມບາງອັນ (queue_depth) ແມ່ນໃຫຍ່ກວ່າຄຳຂໍ Nr_requests ຂອງຜູ້ຈັດຕາຕະລາງ I/O, ດັ່ງນັ້ນຕົວກຳນົດເວລາ I/O ມີໂອກາດໜ້ອຍທີ່ຈະຈັດລຳດັບຄວາມສຳຄັນ ແລະ ການລວມຄຳຮ້ອງຂໍຢ່າງຖືກຕ້ອງ. ສໍາລັບກໍານົດເວລາກໍານົດເວລາແລະ CFQ, ມັນດີກວ່າເມື່ອ nr_requests ມີຂະຫນາດໃຫຍ່ກວ່າຄິວພາຍໃນຂອງຕົວຄວບຄຸມ 2 ເທົ່າ. ການລວມເຂົ້າກັນ ແລະຈັດລໍາດັບແບບສອບຖາມຄືນໃໝ່ຊ່ວຍໃຫ້ຜູ້ກຳນົດເວລາຕອບສະໜອງໄດ້ຫຼາຍຂຶ້ນພາຍໃຕ້ການໂຫຼດໜັກ.

echo "16" > /proc/sys/vm/page-cluster

ພາລາມິເຕີ page-cluster ຄວບຄຸມຈໍານວນຫນ້າທີ່ຂຽນໃສ່ swap ໃນເວລາດຽວ. ໃນຕົວຢ່າງຂ້າງເທິງ, ມູນຄ່າຖືກຕັ້ງເປັນ "16" ເພື່ອໃຫ້ກົງກັບຂະຫນາດເສັ້ນດ່າງ RAID ຂອງ 64 KB. ນີ້ບໍ່ມີຄວາມຫມາຍເມື່ອ swappiness = 0, ແຕ່ຖ້າທ່ານຕັ້ງ swappiness ເປັນ 10 ຫຼື 20, ຫຼັງຈາກນັ້ນ, ການນໍາໃຊ້ຄ່ານີ້ຈະຊ່ວຍໃຫ້ທ່ານມີຂະຫນາດເສັ້ນດ່າງ RAID ແມ່ນ 64 KB.

blockdev --setra 4096 /dev/<ຊື່ dev> (-sdb, hdc ຫຼື dev_mapper)

ການຕັ້ງຄ່າອຸປະກອນຕັນໃນຕອນຕົ້ນສໍາລັບຕົວຄວບຄຸມ RAID ຈໍານວນຫຼາຍມັກຈະສົ່ງຜົນໃຫ້ປະສິດທິພາບທີ່ຂີ້ຮ້າຍ. ການເພີ່ມຕົວເລືອກຂ້າງເທິງຈະກຳນົດຄ່າການອ່ານລ່ວງໜ້າສຳລັບຂະແຫນງ 4096*512 byte. ຢ່າງຫນ້ອຍສໍາລັບການປະຕິບັດງານການຖ່າຍທອດ, ຄວາມໄວແມ່ນເພີ່ມຂຶ້ນໂດຍການຕື່ມຂໍ້ມູນໃສ່ cache ຂອງແຜ່ນໃນຊິບໂດຍຜ່ານການອ່ານລ່ວງຫນ້າໃນໄລຍະເວລາທີ່ kernel ໃຊ້ເພື່ອກະກຽມ I/O. ແຄດສາມາດເກັບຂໍ້ມູນທີ່ຈະຖືກຮ້ອງຂໍໃນລະຫວ່າງການອ່ານຕໍ່ໄປ. ການອ່ານລ່ວງໜ້າຫຼາຍເກີນໄປສາມາດຂ້າ I/O ແບບສຸ່ມສຳລັບໄຟລ໌ຂະໜາດໃຫຍ່ໄດ້ ຖ້າມັນໃຊ້ເວລາດິສກ໌ທີ່ມີປະໂຫຍດ ຫຼື ໂຫຼດຂໍ້ມູນຢູ່ນອກແຄດ.

ຂ້າງລຸ່ມນີ້ແມ່ນບາງຄໍາແນະນໍາເພີ່ມເຕີມໃນລະດັບລະບົບໄຟລ໌. ແຕ່ພວກເຂົາຍັງບໍ່ໄດ້ທົດສອບເທື່ອ. ໃຫ້ແນ່ໃຈວ່າລະບົບໄຟລ໌ຂອງທ່ານຮູ້ຂະຫນາດເສັ້ນດ່າງແລະຈໍານວນແຜ່ນໃນອາເຣ. ສໍາລັບການຍົກຕົວຢ່າງ, ວ່ານີ້ແມ່ນ raid5 array ທີ່ມີຂະຫນາດເສັ້ນດ່າງຂອງ 64K ຂອງຫົກແຜ່ນ (ຕົວຈິງແລ້ວຫ້າ, ເນື່ອງຈາກວ່າຫນຶ່ງດິດຖືກນໍາໃຊ້ສໍາລັບ parity). ຄໍາແນະນໍາເຫຼົ່ານີ້ແມ່ນອີງໃສ່ການສົມມຸດຕິຖານທາງທິດສະດີແລະເກັບກໍາຈາກ blogs / ບົດຄວາມຕ່າງໆໂດຍຜູ້ຊ່ຽວຊານ RAID.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

ສໍາລັບໄຟລ໌ຂະຫນາດໃຫຍ່, ທ່ານອາດຈະພິຈາລະນາການເພີ່ມຂະຫນາດເສັ້ນດ່າງຂ້າງເທິງ.

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

ອຸປະກອນເພີ່ມເຕີມ:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

ອ່ານ​ຕື່ມ

• ການນໍາໃຊ້ nftables ໃນ Red Hat Enterprise Linux 8

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