ការដំឡើងខឺណែលលីនុចសម្រាប់ GlusterFS

ការបកប្រែអត្ថបទត្រូវបានរៀបចំនៅមុនថ្ងៃចាប់ផ្តើមនៃវគ្គសិក្សា "អ្នកគ្រប់គ្រងលីនុច។ វិជ្ជាជីវៈ".

ពីពេលមួយទៅពេលមួយ នៅទីនេះ និងទីនោះមានសំណួរអំពីអនុសាសន៍របស់ Gluster ទាក់ទងនឹងការប្ដូរតាមបំណងខឺណែល និងថាតើវាចាំបាច់ឬអត់។

តម្រូវការនេះកម្រកើតឡើងណាស់។ ស្នូលដំណើរការបានយ៉ាងល្អនៅក្រោមបន្ទុកការងារភាគច្រើន។ ទោះបីជាមានគុណវិបត្តិក៏ដោយ។ ជាប្រវត្តិសាស្ត្រ ខឺណែលលីនុចងាយស្រួលប្រើប្រាស់អង្គចងចាំច្រើន ប្រសិនបើផ្តល់ឱកាស រួមទាំងការរក្សាទុកឃ្លាំងសម្ងាត់ជាមធ្យោបាយចម្បងនៃការកែលម្អដំណើរការ។

ក្នុងករណីភាគច្រើនវាដំណើរការល្អ ប៉ុន្តែនៅក្រោមបន្ទុកធ្ងន់វាអាចបណ្តាលឱ្យមានបញ្ហា។

យើងមានបទពិសោធន៍យ៉ាងទូលំទូលាយក្នុងការធ្វើការជាមួយប្រព័ន្ធដែលប្រើប្រាស់អង្គចងចាំច្រើនដូចជា CAD, EDA និងប្រព័ន្ធផ្សេងទៀត ដែលបានចាប់ផ្តើមយឺតនៅក្រោមបន្ទុកខ្ពស់។ ហើយពេលខ្លះយើងជួបប្រទះបញ្ហានៅក្នុង Gluster ។ បន្ទាប់ពីត្រួតពិនិត្យដោយប្រុងប្រយ័ត្ននូវអង្គចងចាំដែលបានប្រើ និងពេលវេលារង់ចាំឌីសច្រើនជាងមួយថ្ងៃ យើងទទួលបានការផ្ទុកលើសចំណុះនៃឌីស អ៊ីយ៉ូតដ៏ធំ កំហុសខឺណែល (ខឺណែលអូប) ការបង្កក។ល។

អត្ថបទនេះគឺជាលទ្ធផលនៃការពិសោធន៍លៃតម្រូវប៉ារ៉ាម៉ែត្រជាច្រើនដែលបានអនុវត្តក្នុងស្ថានភាពផ្សេងៗ។ សូមអរគុណចំពោះប៉ារ៉ាម៉ែត្រទាំងនេះ មិនត្រឹមតែការឆ្លើយតបជាទូទៅមានភាពប្រសើរឡើងប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងប្រតិបត្តិការនៃចង្កោមមានស្ថេរភាពយ៉ាងខ្លាំងផងដែរ។

នៅពេលនិយាយអំពីការកំណត់រចនាសម្ព័ន្ធអង្គចងចាំ កន្លែងដំបូងដែលត្រូវមើលគឺប្រព័ន្ធរងនៃសតិនិម្មិត (VM) ដែលមានជម្រើសមួយចំនួនធំដែលអាចឱ្យអ្នកច្រឡំ។

vm. swappiness

ប៉ារ៉ាម៉ែត្រ vm.swappiness កំណត់ថាតើខឺណែលប្រើ swap ប៉ុន្មានបើធៀបនឹង RAM ។ វាក៏ត្រូវបានកំណត់នៅក្នុងកូដប្រភពថាជា "ទំនោរក្នុងការលួចអង្គចងចាំដែលបានគូសផែនទី"។ តម្លៃ swappiness ខ្ពស់មានន័យថា ខឺណែលនឹងងាយនឹងប្តូរទំព័រដែលបានគូសវាស។ តម្លៃ swappiness ទាបមានន័យថាផ្ទុយគ្នា៖ ខឺណែលនឹងប្តូរទំព័រចេញពីអង្គចងចាំតិចជាងមុន។ និយាយម្យ៉ាងទៀតតម្លៃកាន់តែខ្ពស់។ vm.swappinessប្រព័ន្ធនឹងប្រើ swap កាន់តែច្រើន។

ការប្រើប្រាស់ទូលំទូលាយនៃការប្តូរគឺមិនចង់បានទេ ចាប់តាំងពីប្លុកទិន្នន័យដ៏ធំត្រូវបានផ្ទុក និងមិនបានផ្ទុកទៅក្នុង RAM ។ មនុស្សជាច្រើនប្រកែកថាតម្លៃ swapiness គួរតែខ្ពស់ ប៉ុន្តែតាមបទពិសោធន៍របស់ខ្ញុំ ការកំណត់វាទៅជា "0" នាំឱ្យដំណើរការកាន់តែប្រសើរ។

អ្នកអាចអានបន្ថែមនៅទីនេះ - lwn.net/Articles/100978

ប៉ុន្តែម្តងទៀត ការកំណត់ទាំងនេះគួរតែត្រូវបានប្រើដោយប្រុងប្រយ័ត្ន ហើយបន្ទាប់ពីបានសាកល្បងកម្មវិធីជាក់លាក់ប៉ុណ្ណោះ។ សម្រាប់កម្មវិធីស្ទ្រីមដែលមានផ្ទុកខ្ពស់ ប៉ារ៉ាម៉ែត្រនេះគួរតែត្រូវបានកំណត់ទៅ "0" ។ នៅពេលប្តូរទៅជា "0" ការឆ្លើយតបរបស់ប្រព័ន្ធមានភាពប្រសើរឡើង។

vm.vfs_cache_pressure

ការកំណត់នេះគ្រប់គ្រងអង្គចងចាំដែលប្រើប្រាស់ដោយខឺណែលសម្រាប់ឃ្លាំងសម្ងាត់វត្ថុ និងអ៊ីណូត (ធ្មេញ និងអ៊ីណូត)។

ជាមួយនឹងតម្លៃលំនាំដើមនៃ 100 ខឺណែលនឹងព្យាយាមដោះលែងឃ្លាំងសម្ងាត់ dentry និង inode ក្នុងលក្ខណៈសមរម្យមួយទៅកាន់ pagecache និង swapcache ។ ការថយចុះ vfs_cache_pressure បណ្តាលឱ្យខឺណែលរក្សាធ្មេញ និងឃ្លាំងសម្ងាត់អ៊ីដ្រូសែន។ នៅពេលដែលតម្លៃគឺ "0" ខឺណែលនឹងមិនធ្វើឱ្យខូច dentry និង inode cache ដោយសារតែសម្ពាធនៃអង្គចងចាំនោះទេ ហើយវាអាចនាំឱ្យមានបញ្ហាក្រៅសតិយ៉ាងងាយស្រួល។ ការកើនឡើង vfs_cache_pressure លើសពី 100 បណ្តាលឱ្យខឺណែលផ្តល់អាទិភាពដល់ dentry និង inode pageouts ។

នៅពេលប្រើ GlusterFS អ្នកប្រើប្រាស់ជាច្រើនដែលមានទិន្នន័យច្រើន និងឯកសារតូចៗជាច្រើនអាចប្រើប្រាស់ RAM ដ៏ច្រើនសន្ធឹកសន្ធាប់នៅលើម៉ាស៊ីនមេបានយ៉ាងងាយស្រួល ដោយសារឃ្លាំងសម្ងាត់ inode/dentry ដែលអាចនាំឱ្យមានដំណើរការមិនល្អ ដោយសារខឺណែលត្រូវគ្រប់គ្រងរចនាសម្ព័ន្ធទិន្នន័យនៅលើប្រព័ន្ធ។ ជាមួយនឹងអង្គចងចាំ 40 GB ។ ការកំណត់ប៉ារ៉ាម៉ែត្រនេះឱ្យធំជាង 100 បានជួយអ្នកប្រើប្រាស់ជាច្រើនឱ្យសម្រេចបាននូវឃ្លាំងសម្ងាត់ត្រឹមត្រូវជាងមុន និងធ្វើឱ្យការឆ្លើយតបរបស់ខឺណែលប្រសើរឡើង។

vm.dirty_background_ratio និង vm.dirty_ratio

ប៉ារ៉ាម៉ែត្រដំបូង (vm.dirty_background_ratio) កំណត់ភាគរយនៃអង្គចងចាំជាមួយទំព័រកខ្វក់ នៅពេលឈានដល់ដែលវាចាំបាច់ដើម្បីចាប់ផ្តើមការបង្ហូរផ្ទៃខាងក្រោយនៃទំព័រកខ្វក់ទៅថាស។ រហូតដល់ភាគរយនេះត្រូវបានឈានដល់ ទំព័រមិនត្រូវបានបញ្ចូលទៅក្នុងថាសទេ។ ហើយនៅពេលដែលការកំណត់ឡើងវិញចាប់ផ្តើម វាដំណើរការក្នុងផ្ទៃខាងក្រោយដោយមិនរំខានដល់ដំណើរការដែលកំពុងដំណើរការ។

ប៉ារ៉ាម៉ែត្រទីពីរ (vm.dirty_ratio) កំណត់ភាគរយនៃអង្គចងចាំដែលអាចត្រូវបានកាន់កាប់ដោយទំព័រកខ្វក់ មុនពេលពន្លឺបង្ខំចាប់ផ្តើម។ នៅពេលដែលឈានដល់កម្រិតនេះ ដំណើរការទាំងអស់ក្លាយជាសមកាលកម្ម (បានទប់ស្កាត់) ហើយមិនត្រូវបានអនុញ្ញាតឱ្យបន្តដំណើរការរហូតដល់ប្រតិបត្តិការ I/O ដែលពួកគេស្នើសុំត្រូវបានបញ្ចប់ពិតប្រាកដ ហើយទិន្នន័យគឺនៅលើថាស។ ជាមួយនឹងការផ្ទុក I/O ខ្ពស់ នេះបណ្តាលឱ្យមានបញ្ហាដោយសារតែមិនមានឃ្លាំងសម្ងាត់ទិន្នន័យ ហើយដំណើរការទាំងអស់ដែលធ្វើ I/O ត្រូវបានរារាំងដោយរង់ចាំ I/O ។ នេះបណ្តាលឱ្យមានដំណើរការព្យួរមួយចំនួនធំ ការផ្ទុកខ្ពស់ អស្ថិរភាពនៃប្រព័ន្ធ និងដំណើរការមិនល្អ។

ការថយចុះតម្លៃនៃប៉ារ៉ាម៉ែត្រទាំងនេះបណ្តាលឱ្យទិន្នន័យត្រូវបានហូរទៅថាសញឹកញាប់ជាងមុននិងមិនត្រូវបានរក្សាទុកក្នុង RAM ។ នេះអាចជួយប្រព័ន្ធដែលមានអង្គចងចាំធ្ងន់ ដែលវាជារឿងធម្មតាក្នុងការលុបឃ្លាំងសម្ងាត់ទំព័រ 45-90GB ទៅក្នុងថាស ដែលបណ្តាលឱ្យមានភាពយឺតយ៉ាវដ៏ធំសម្រាប់កម្មវិធីផ្នែកខាងមុខ កាត់បន្ថយការឆ្លើយតប និងអន្តរកម្មរួម។

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

ឃ្លាំងសម្ងាត់ទំព័រគឺជាឃ្លាំងសម្ងាត់ដែលរក្សាទុកទិន្នន័យពីឯកសារ និងកម្មវិធីដែលអាចប្រតិបត្តិបាន ពោលគឺទាំងនេះគឺជាទំព័រដែលមានមាតិកាពិតនៃឯកសារ ឬឧបករណ៍ទប់ស្កាត់។ ឃ្លាំងសម្ងាត់នេះត្រូវបានប្រើដើម្បីកាត់បន្ថយចំនួននៃការអានថាស។ តម្លៃនៃ "1" មានន័យថាឃ្លាំងសម្ងាត់ប្រើ 1% នៃ RAM ហើយវានឹងមានការអានច្រើនជាងពី RAM ។ វាមិនចាំបាច់ក្នុងការផ្លាស់ប្តូរការកំណត់នេះទេ ប៉ុន្តែប្រសិនបើអ្នកព្រួយបារម្ភអំពីការគ្រប់គ្រងឃ្លាំងសម្ងាត់ទំព័រ អ្នកអាចប្រើវាបាន។

"កាលកំណត់" > /sys/block/sdc/queue/scheduler

កម្មវិធីកំណត់ពេល I/O គឺជាធាតុផ្សំនៃខឺណែលលីនុច ដែលគ្រប់គ្រងជួរអាន និងសរសេរ។ តាមទ្រឹស្ដី វាជាការប្រសើរក្នុងការប្រើប្រាស់ "noop" សម្រាប់ឧបករណ៍បញ្ជា RAID ដ៏ឆ្លាតវៃ ពីព្រោះលីនុចមិនដឹងអ្វីអំពីធរណីមាត្ររូបវន្តរបស់ឌីស ដូច្នេះវាមានប្រសិទ្ធភាពជាងក្នុងការអនុញ្ញាតឱ្យឧបករណ៍បញ្ជាដែលស្គាល់ធរណីមាត្រឌីសបានល្អ ដំណើរការសំណើជា លឿនតាមដែលអាចធ្វើទៅបាន។ ប៉ុន្តែវាហាក់ដូចជាថា "ពេលវេលាកំណត់" ធ្វើអោយប្រសើរឡើងនូវការអនុវត្ត។ ព័ត៌មានបន្ថែមអំពីកម្មវិធីកំណត់ពេលអាចរកបាននៅក្នុងឯកសារសម្រាប់កូដប្រភពខឺណែលលីនុច៖ linux/Documentation/block/*osched.txt. ហើយ​ខ្ញុំ​ក៏​សង្កេត​ឃើញ​មាន​ការ​កើន​ឡើង​នៃ​ការ​អាន​អំឡុង​ពេល​ប្រតិបត្តិការ​ចម្រុះ (សរសេរ​ច្រើន)។

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

ចំនួនសំណើ I/O នៅក្នុងសតិបណ្ដោះអាសន្ន មុនពេលពួកវាត្រូវបានបញ្ជូនទៅអ្នកកំណត់ពេល។ ទំហំជួរខាងក្នុងរបស់ឧបករណ៍បញ្ជាមួយចំនួន (queue_depth) គឺធំជាង nr_requests របស់អ្នកកំណត់ពេល I/O ដូច្នេះកម្មវិធីកំណត់ពេល I/O មានឱកាសតិចតួចក្នុងការកំណត់អាទិភាព និងសំណើបញ្ចូលគ្នាឱ្យបានត្រឹមត្រូវ។ សម្រាប់អ្នកកំណត់ពេលកំណត់ និង CFQ វាប្រសើរជាងនៅពេលដែល nr_requests ធំជាងជួរខាងក្នុងរបស់ឧបករណ៍បញ្ជា 2 ដង។ ការរួមបញ្ចូលគ្នា និងតម្រៀបសំណួរឡើងវិញជួយឱ្យអ្នកកំណត់ពេលឆ្លើយតបកាន់តែច្រើននៅក្រោមបន្ទុកធ្ងន់។

បន្ទរ "16" > /proc/sys/vm/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 បៃ។ យ៉ាងហោចណាស់សម្រាប់ប្រតិបត្តិការស្ទ្រីម ល្បឿនត្រូវបានបង្កើនដោយការបំពេញឃ្លាំងសម្ងាត់ថាសនៅលើបន្ទះឈីបតាមរយៈការអានជាមុនក្នុងអំឡុងពេលដែលខឺណែលប្រើដើម្បីរៀបចំ I/O ។ ឃ្លាំងសម្ងាត់អាចផ្ទុកទិន្នន័យដែលនឹងត្រូវបានស្នើសុំក្នុងអំឡុងពេលអានបន្ទាប់។ ការអានជាមុនច្រើនពេកអាចសម្លាប់ I/O ចៃដន្យសម្រាប់ឯកសារធំប្រសិនបើវាប្រើពេលវេលាថាសមានប្រយោជន៍ ឬផ្ទុកទិន្នន័យនៅខាងក្រៅឃ្លាំងសម្ងាត់។

ខាងក្រោម​នេះ​ជា​អនុសាសន៍​មួយ​ចំនួន​ទៀត​នៅ​កម្រិត​ប្រព័ន្ធ​ឯកសារ។ ប៉ុន្តែពួកគេមិនទាន់បានធ្វើតេស្តនៅឡើយ។ ត្រូវប្រាកដថាប្រព័ន្ធឯកសាររបស់អ្នកដឹងពីទំហំឆ្នូត និងចំនួនថាសនៅក្នុងអារេ។ ជាឧទាហរណ៍ ថានេះគឺជាអារេ raid5 ដែលមានទំហំឆ្នូតនៃ 64K នៃថាសចំនួនប្រាំមួយ (តាមពិតទៅ XNUMX ព្រោះថាសមួយត្រូវបានប្រើសម្រាប់ភាពស្មើគ្នា)។ អនុសាសន៍ទាំងនេះគឺផ្អែកលើការសន្មត់តាមទ្រឹស្តី និងប្រមូលពីប្លុក/អត្ថបទផ្សេងៗដោយអ្នកជំនាញ 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))

សម្រាប់ឯកសារធំជាងនេះ អ្នកអាចពិចារណាបង្កើនទំហំឆ្នូតខាងលើ។

យកចិត្តទុកដាក់! អ្វីគ្រប់យ៉ាងដែលបានពិពណ៌នាខាងលើគឺជាប្រធានបទយ៉ាងខ្លាំងសម្រាប់ប្រភេទនៃកម្មវិធីមួយចំនួន។ អត្ថបទនេះមិនធានាការកែលម្អណាមួយដោយមិនចាំបាច់សាកល្បងកម្មវិធីរៀងៗខ្លួនដោយអ្នកប្រើប្រាស់ជាមុននោះទេ។ វាគួរតែត្រូវបានប្រើលុះត្រាតែមានតម្រូវការដើម្បីកែលម្អការឆ្លើយតបរបស់ប្រព័ន្ធទាំងមូល ឬប្រសិនបើវាដោះស្រាយបញ្ហាបច្ចុប្បន្ន។

សំភារៈបន្ថែម៖

• 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