Нийтлэлийн орчуулгыг курс эхлэхийн өмнөх өдөр бэлтгэсэн .
Цөмийг тохируулах талаар Gluster-ийн зөвлөмж, шаардлагатай эсэх талаар үе үе асуултууд гарч ирдэг.
Энэ хэрэгцээ нь ховор тохиолддог. Гол нь ихэнх ажлын ачаалалд маш сайн ажилладаг. Хэдийгээр сул тал бий. Түүхээс харахад Линуксийн цөмд боломж олдвол маш их санах ой, түүний дотор кэшийг гүйцэтгэлийг сайжруулах үндсэн хэрэгсэл болгон ашигладаг.
Ихэнх тохиолдолд энэ нь маш сайн ажилладаг боловч их ачаалалтай үед асуудал үүсгэж болно.
Бид өндөр ачаалалтай үед удааширч эхэлсэн CAD, EDA гэх мэт маш их санах ой хэрэглэдэг системүүдтэй ажиллах арвин туршлагатай. Заримдаа бид Gluster-д асуудалтай тулгардаг. Ашигласан санах ой болон дискний хүлээх хугацааг нэгээс дээш хоног сайтар хянаж үзсэний дараа бид дискний хэт ачаалал, асар их хэмжээний iowait, цөмийн алдаанууд (цөмийн алдаа), хөлдөлт гэх мэтийг олж авлаа.
Энэ нийтлэл нь янз бүрийн нөхцөлд хийгдсэн параметрүүдийг тааруулах олон туршилтуудын үр дүн юм. Эдгээр параметрүүдийн ачаар зөвхөн хариу үйлдэл ерөнхийдөө сайжирч зогсохгүй кластерын үйл ажиллагаа мэдэгдэхүйц тогтворжсон.
Санах ойг тохируулахын тулд хамгийн түрүүнд хайх ёстой зүйл бол виртуал санах ойн дэд систем (VM) бөгөөд энэ нь таныг төөрөлдүүлэх олон тооны сонголттой байдаг.
vm.swappiness
Үзүүлэлт vm.swappiness цөм нь RAM-тай харьцуулахад свопыг хэр их ашигладаг болохыг тодорхойлдог. Үүнийг мөн эх кодонд "зурагласан санах ойг хулгайлах хандлага" гэж тодорхойлсон байдаг. Өндөр солилцооны утга нь цөм нь зурагласан хуудсыг солиход илүү өртөмтгий болно гэсэн үг юм. Бага солилцооны утга нь эсрэгээр гэсэн үг: цөм нь санах ойноос бага зэрэг хуудсуудыг солих болно. Өөрөөр хэлбэл, үнэ цэнэ нь өндөр байх болно vm.swappiness, систем илүү их своп ашиглах болно.
Асар их хэмжээний өгөгдлийг RAM-д ачаалж, буулгадаг тул солилцоог өргөнөөр ашиглах нь зохимжгүй юм. Олон хүмүүс солилцооны үнэ цэнэ өндөр байх ёстой гэж маргадаг ч миний туршлагаас харахад үүнийг "0" болгож тохируулснаар илүү сайн гүйцэтгэлтэй байдаг.
Та эндээс илүү ихийг уншиж болно -
Гэхдээ дахин хэлэхэд эдгээр тохиргоог болгоомжтой ашиглах хэрэгтэй бөгөөд зөвхөн тодорхой програмыг туршиж үзсэний дараа л хийх хэрэгтэй. Ачаалал ихтэй урсгал програмуудын хувьд энэ параметрийг "0" болгож тохируулах хэрэгтэй. "0" болгож өөрчлөхөд системийн хариу үйлдэл сайжирна.
vm.vfs_cache_даралт
Энэ тохиргоо нь лавлах объект болон иноод (dentry болон inode) кэш хийхэд цөмд зарцуулсан санах ойг хянадаг.
Өгөгдмөл утга нь 100 бол цөм нь dentry болон inode кэшийг pagecache болон swapcache руу шударгаар чөлөөлөхийг оролдох болно. Vfs_cache_даралтыг бууруулснаар цөм нь dentry болон inode кэшийг хадгалахад хүргэдэг. Утга нь "0" байх үед цөм нь санах ойн даралтын улмаас dentry болон inode кэшийг хэзээ ч цэвэрлэхгүй бөгөөд энэ нь санах ойн алдаа гарахад амархан хүргэдэг. Vfs_cache_даралтыг 100-аас дээш нэмэгдүүлэх нь цөм нь dentry болон inode pageouts-д давуу эрх олгоход хүргэдэг.
GlusterFS-г ашиглах үед их хэмжээний өгөгдөл болон олон жижиг файлтай олон хэрэглэгчид inode/dentry кэшийн улмаас сервер дээр ихээхэн хэмжээний RAM-г хялбархан ашиглаж болох бөгөөд энэ нь цөм нь систем дээрх өгөгдлийн бүтцийг зохицуулах шаардлагатай болдог тул гүйцэтгэл мууддаг. 40 ГБ санах ойтой. Энэ параметрийг 100-аас дээш болгож тохируулах нь олон хэрэглэгчдэд илүү шударга кэш хийх, цөмийн хариу урвалыг сайжруулахад тусалсан.
vm.бохир_арын_харьцаа ба vm.бохир_харьцаа
Эхний параметр (vm.dirty_background_ratio) нь бохир хуудас бүхий санах ойн хувийг тодорхойлдог бөгөөд үүнд хүрэхэд бохир хуудсыг диск рүү арын дэвсгэр дээр угааж эхлэх шаардлагатай. Энэ хувь хүрэх хүртэл хуудсуудыг диск рүү буулгадаггүй. Мөн дахин тохируулж эхлэхэд энэ нь ажиллаж байгаа процессуудыг тасалдуулахгүйгээр арын дэвсгэр дээр ажилладаг.
Хоёрдахь параметр (vm.dirty_ratio) албадан флэш эхлэхээс өмнө бохир хуудсанд эзлэх санах ойн хувийг тодорхойлдог. Энэ босго хэмжээнд хүрмэгц бүх процессууд синхрон (блоклогдсон) болж, тэдний хүссэн оролт гаралтын ажиллагаа дуусч, өгөгдөл дискэн дээр байх хүртэл үргэлжлүүлэн ажиллахыг зөвшөөрөхгүй. Оролт/гаралтын ачаалал ихтэй үед энэ нь асуудал үүсгэдэг, учир нь өгөгдөл кэш хийхгүй бөгөөд оролт/гаралтыг хийх бүх процессууд оролт/гаралтыг хүлээж блоклогддог. Үүний үр дүнд олон тооны өлгөгдсөн процесс, өндөр ачаалал, системийн тогтворгүй байдал, гүйцэтгэл муутай байдаг.
Эдгээр параметрүүдийн утгыг багасгах нь өгөгдлийг диск рүү илүү олон удаа угааж, RAM-д хадгалахгүй болоход хүргэдэг. Энэ нь санах ой ихтэй системүүдэд туслах бөгөөд 45-90 ГБ хуудасны кэшийг диск рүү угаах нь хэвийн үзэгдэл бөгөөд энэ нь урд талын програмуудад асар их хоцрогдол үүсгэж, ерөнхий хариу үйлдэл болон харилцан үйлчлэлийг бууруулдаг.
"1" > /proc/sys/vm/pagecache
Хуудасны кэш нь файлууд болон гүйцэтгэх боломжтой програмуудын өгөгдлийг хадгалдаг кэш бөгөөд өөрөөр хэлбэл эдгээр нь файл эсвэл блок төхөөрөмжийн бодит агуулга бүхий хуудсууд юм. Энэ кэш нь дискний уншилтын тоог багасгахад ашиглагддаг. "1" утга нь кэш нь RAM-ийн 1% -ийг ашигладаг бөгөөд RAM-аас илүү дискнээс унших болно гэсэн үг юм. Энэ тохиргоог өөрчлөх шаардлагагүй, гэхдээ хэрэв та хуудасны кэшийг удирдах талаар гаж донтой байгаа бол үүнийг ашиглаж болно.
"сонгосон хугацаа" > /sys/block/sdc/queue/хуваарилагч
Оролт гаралтын хуваарь нь унших, бичих дарааллыг зохицуулдаг Линуксийн цөмийн бүрэлдэхүүн хэсэг юм. Онолын хувьд ухаалаг RAID хянагчдаа "noop" ашиглах нь дээр, учир нь Линукс нь дискний физик геометрийн талаар юу ч мэдэхгүй тул дискний геометрийг сайн мэддэг хянагчдаа хүсэлтийг дараах байдлаар боловсруулахыг зөвшөөрөх нь илүү үр дүнтэй байдаг. аль болох хурдан. Гэхдээ "эцсийн хугацаа" нь гүйцэтгэлийг сайжруулдаг бололтой. Хуваарилагчдын талаарх дэлгэрэнгүй мэдээллийг Линуксийн цөмийн эх кодын баримтаас олж болно. linux/Documentation/block/*osched.txt. Холимог үйлдлийн (маш олон бичих) үед унших чадвар нэмэгдэж байгааг би ажигласан.
"256" > /sys/block/sdc/queue/nr_requests
Хуваарьлагч руу илгээгдэхээс өмнө буфер дэх оролт/гаралтын хүсэлтийн тоо. Зарим хянагчийн дотоод дарааллын хэмжээ (queue_depth) нь оролт/гаралтын хуваарь гаргагчийн nr_requests-ээс их байдаг тул оролт/гаралтын хуваарьлагч нь хүсэлтийг зөв эрэмбэлэх, нэгтгэх боломж багатай байдаг. Эцсийн хугацаа болон CFQ төлөвлөгчдийн хувьд nr_requests нь хянагчийн дотоод дарааллаас 2 дахин их байх нь дээр. Асуултуудыг нэгтгэх, дахин эрэмбэлэх нь хуваарилагчийг ачаалал ихтэй үед илүү хариу үйлдэл үзүүлэхэд тусалдаг.
echo "16" > /proc/sys/vm/page-cluster
Хуудасны кластер параметр нь солилцоонд нэг удаа бичигдэх хуудасны тоог хянадаг. Дээрх жишээн дээр RAID зурвасын 16 KB хэмжээтэй тааруулахын тулд утгыг "64" гэж тохируулсан. Энэ нь swappiness = 0 үед утгагүй, гэхдээ хэрэв та swappiness-ийг 10 эсвэл 20 гэж тохируулсан бол RAID зурвасын хэмжээ 64 KB байхад энэ утгыг ашиглах нь танд тусална.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc эсвэл dev_mapper)
Олон RAID хянагчдад зориулсан анхдагч блок төхөөрөмжийн тохиргоо нь ихэвчлэн аймшигтай гүйцэтгэлд хүргэдэг. Дээрх сонголтыг нэмснээр 4096*512 байт секторуудад урьдчилан унших тохиргоог хийнэ. Наад зах нь урсгалын үйлдлүүдийн хувьд цөмийн оролт / гаралтыг бэлтгэхэд ашигладаг хугацааны туршид чип дээрх дискний кэшийг урьдчилан унших замаар дүүргэх замаар хурдыг нэмэгдүүлдэг. Кэш нь дараагийн унших явцад шаардагдах өгөгдлийг хадгалах боломжтой. Хэт их урагш унших нь том файлуудын санамсаргүй I/O-г устгаж, хэрэв энэ нь дискний ашигтай цагийг зарцуулдаг эсвэл кэшээс гадуур өгөгдлийг ачаалдаг.
Файлын системийн түвшинд хэд хэдэн зөвлөмжийг доор өгөв. Гэхдээ тэдгээрийг хараахан туршиж үзээгүй байна. Таны файлын систем зурвасын хэмжээ болон массив дахь дискний тоог мэддэг эсэхийг шалгаарай. Жишээлбэл, энэ нь зургаан дискний 5К хэмжээтэй судалтай raid64 массив юм (үнэндээ тав, учир нь нэг дискийг паритад ашигладаг). Эдгээр зөвлөмжүүд нь онолын таамаглал дээр үндэслэсэн бөгөөд 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))Том хэмжээтэй файлуудын хувьд дээрх зураасны хэмжээг нэмэгдүүлэх талаар бодож болно.
Анхаар! Дээр дурдсан бүх зүйл зарим төрлийн хэрэглээний хувьд туйлын субъектив юм. Энэ нийтлэл нь хэрэглэгчийн холбогдох програмуудыг эхлээд туршихгүйгээр сайжруулалтыг баталгаажуулахгүй. Үүнийг зөвхөн системийн хариу урвалыг сайжруулах шаардлагатай эсвэл одоогийн асуудлыг шийдэж байгаа тохиолдолд л ашиглах ёстой.
Дополнительные материалууд:
Цааш унших
Эх сурвалж: www.habr.com