Макаланын котормосу курстун башталышынын алдында даярдалган .
Мезгил-мезгили менен, бул жерде жана бул жерде Glusterдин ядрону жөндөө боюнча сунуштары жана мунун кереги барбы деген суроолор пайда болот.
Мындай муктаждык чанда гана пайда болот. Көпчүлүк жүктөмдө ядро абдан жакшы иштейт. Жаман жагы бар да. Тарыхый жактан алганда, Linux ядросу мүмкүнчүлүк берилсе, эстутумдун көп үлүшүн сарптоого даяр болгон, анын ичинде аткарууну жакшыртуунун негизги жолу катары кэштөө үчүн.
Көпчүлүк учурларда, бул жакшы иштейт, бирок оор жүктө ал көйгөйлөргө алып келиши мүмкүн.
Бизде CAD, EDA жана ушул сыяктуулар сыяктуу эстутумду талап кылган системалар боюнча көп тажрыйбабыз бар, алар оор жүктөмдө жайлай баштаган. Кээде биз Глустерде көйгөйлөргө туш болобуз. Көп күн бою эстутумдун колдонулушун жана дисктин кечигүү убактысын кылдаттык менен байкагандан кийин, биз алардын ашыкча жүктөлүшүн, чоң iowait, ядро каталарын (ядро ой), катып калууларды ж.б. алдык.
Бул макала ар кандай кырдаалдарда жасалган көптөгөн тюнинг эксперименттеринин натыйжасы болуп саналат. Бул параметрлердин аркасында жалпы жооп берүү гана жакшырбастан, кластер да кыйла турукташкан.
Эстутумду тюнингге келгенде, биринчи кезекте сизди чаташтыра турган көптөгөн варианттарга ээ виртуалдык эс тутуму (VM, виртуалдык эс тутуму) каралышы керек.
vm.swappiness
параметр vm.swappiness RAMга салыштырмалуу ядро канчалык своп (алмаштыруу, пейджинг) колдоноорун аныктайт. Ал ошондой эле баштапкы коддо "карталанган эстутумду уурдоо тенденциясы" катары аныкталган. Жогорку алмашуу ядро карталанган барактарды алмаштырууга көбүрөөк ыктаарын билдирет. Төмөн алмаштыруу мааниси тескерисинче билдирет: ядро эстутумдан азыраак барактайт. Башка сөз менен айтканда, баасы жогору болот vm.swappiness, система свопту көбүрөөк колдонот.
Свопингди көп колдонуу жагымсыз, анткени RAMга чоң маалымат блоктору жүктөлөт жана түшүрүлөт. Көптөгөн адамдар swapiness мааниси чоң болушу керек деп ырасташат, бирок менин тажрыйбам боюнча, аны "0" деп коюу жакшыраак иштөөгө алып келет.
Кененирээк бул жерден окуй аласыз -
Бирок, дагы бир жолу, бул жөндөөлөр этияттык менен жана белгилүү бир колдонмону сынап көргөндөн кийин гана колдонулушу керек. Жогорку жүктөлгөн агымдык колдонмолор үчүн бул параметр "0" болушу керек. "0" деп өзгөртүлгөндө, системанын жооп берүү жөндөмдүүлүгү жакшырат.
vm.vfs_cache_pressure
Бул жөндөө каталог жана инод объекттерин кэштөө үчүн ядро тарабынан сарпталган эстутумду көзөмөлдөйт (dentry жана inode).
Демейки мааниси 100 болгон ядро дентри жана инод кэштерин "адилеттүү" негизде pagecache жана swapcache үчүн бошотууга аракет кылат. Vfs_cache_pressure төмөндөшү ядронун dentry жана inode кэштерин сактоого алып келет. Мааниси "0" болгондо, ядро эс тутумдун басымынан улам дентри жана инод кэшин эч качан тазалабайт жана бул оңой эле эс тутумдан чыгып кеткен катага алып келиши мүмкүн. Vfs_cache_pressure 100дөн жогору көтөрүлсө, ядро тиш жана инодду тазалоону артыкчылыктуу кылат.
GlusterFSди колдонууда, чоң көлөмдөгү маалыматтары жана көптөгөн майда файлдары бар көптөгөн колдонуучулар inode/dentry кэштөөдөн улам серверде оперативдүү эстутумдун олуттуу көлөмүн оңой пайдалана алышат, бул өзөктүн системадагы маалымат структураларын иштеп чыгуусу керек болгондуктан, иштөөнүн начарлашына алып келиши мүмкүн. 40 ГБ эстутум менен. Бул маанини 100дөн жогору коюу көптөгөн колдонуучуларга адилеттүү кэштоого жана ядронун жооп берүү жөндөмдүүлүгүн жакшыртууга жардам берди.
vm.dirty_background_ratio жана vm.dirty_ratio
Биринчи параметр (vm.dirty_background_ratio) кир барактар менен эстутумдун пайызын аныктайт, ага жеткенден кийин фондогу кир барактарын дискке жууп баштоо керек. Бул пайызга жеткенге чейин эч бир барак дискке түшүрүлбөйт. Жана баштапкы абалга келтирүү башталганда, ал иштеп жаткан процесстерди үзгүлтүккө учуратпастан фондо иштейт.
Экинчи параметр (vm.dirty_ratio) аргасыз жаркылдоо башталганга чейин кир барактар ээлей турган эстутум пайызын аныктайт. Бул чекке жеткенден кийин, бардык процесстер синхрондуу (бөгөттөлгөн) болуп калат жана алар сураган киргизүү/чыгаруу иш жүзүндө аткарылмайынча жана маалыматтар дискте болмоюнча улантууга уруксат берилбейт. Оор киргизүү/чыгаруу менен бул көйгөйдү жаратат, анткени берилиштерди кэштөө жок жана киргизүү/чыгаруучу бардык процесстер киргизүү/чыгарууну күтүүдө бөгөттөлгөн. Бул көп сандагы илинип турган процесстерге, жогорку жүктөөгө, системанын туруксуздугуна жана начар иштешине алып келет.
Бул орнотууларды азайтуу маалыматтардын дискке бат-баттан тазаланышына жана RAMда сакталбай калышына алып келет. Бул 45-90 ГБ бет кэштерин дискке жууп салууга жарамдуу эс тутуму оор системаларга жардам берет, натыйжада алдыңкы тиркемелер үчүн чоң кечигүү пайда болуп, жалпы жооптуулукту жана интерактивдүүлүктү азайтат.
"1" > /proc/sys/vm/pagecache
Барак кэши – бул файлдардын жана аткарылуучу программалардын маалыматтарын сактаган кэш, башкача айтканда, бул файлдардын же блоктук түзүлүштөрдүн чыныгы мазмуну бар барактар. Бул кэш дисктин окуу санын азайтуу үчүн колдонулат. "1" мааниси кэш үчүн оперативдүү эстутумдун 1% колдонуларын жана RAMдан караганда дисктен көбүрөөк окуулар болорун билдирет. Бул жөндөөнү өзгөртүүнүн кажети жок, бирок сиз баракчанын кэшин башкарууга паранойя болсоңуз, аны колдоно аласыз.
"мөөнөтү" > /sys/block/sdc/queue/scheduler
I/O пландаштыргыч окуу жана жазуу кезектерин башкарган Linux ядросунун компоненти. Теориялык жактан алганда, акылдуу RAID контроллери үчүн "noop" дегенди колдонуу жакшы, анткени Linux дисктин физикалык геометриясы жөнүндө эч нерсе билбейт, андыктан дисктин геометриясын жакшы билген контроллерге суроо-талапты тезирээк иштетүүгө мүмкүнчүлүк берүү натыйжалуураак. мүмкүн. Бирок "мөөнөт" аткарууну жакшыртат окшойт. Linux ядросунун баштапкы кодунун документтеринде пландаштыруучулар жөнүндө көбүрөөк окуй аласыз: 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
Барак-кластер параметри бир убакта алмашууга жазылган барактардын санын көзөмөлдөйт. Жогорудагы мисалда 16 KB RAID тилкесинин өлчөмүнө ылайык маани "64" деп коюлган. Swappiness = 0 менен мааниси жок, бирок эгер сиз алмаштырууну 10 же 20 деп коюңуз, анда бул маанини колдонуу RAID тилкесинин өлчөмү 64K болгондо жардам берет.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc же dev_mapper)
Көптөгөн RAID контроллерлору үчүн демейки блок түзмөк орнотуулары көбүнчө коркунучтуу аткарууга алып келет. Жогорудагы опцияны кошуу 4096 * 512 байт секторлор үчүн окууну алдын ала орнотот. Жок дегенде, агымдык операциялар үчүн, I/O даярдоо үчүн ядро колдонгон мезгил ичинде чиптеги дисктин кэшин алдыда окуу менен толтуруу менен ылдамдык жогорулайт. Кэш кийинки окууда сурала турган маалыматтарды камтышы мүмкүн. Өтө көп алдын ала жүктөө чоң файлдар үчүн кокустук киргизүү/чыгарууну жок кылышы мүмкүн, эгерде ал дисктин потенциалдуу пайдалуу убактысын колдонсо же кэштен тышкары маалыматтарды жүктөсө.
Төмөндө файл тутумунун деңгээлинде дагы бир нече сунуштар бар. Бирок алар азырынча текшериле элек. Сиздин файл тутумуңуз тилкенин өлчөмүн жана массивдеги дисктердин санын билерин текшериңиз. Мисалы, бул алты дисктен турган 5K тилкелүү 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))Чоң файлдар үчүн жогоруда саналган тилкелердин өлчөмүн көбөйтүүнү карап көрүңүз.
WARNING! Жогоруда айтылгандардын баары колдонмолордун кээ бир түрлөрү үчүн өтө субъективдүү. Бул макала колдонуучуга тиешелүү тиркемелерди алдын ала сынабай туруп, эч кандай өркүндөтүүгө кепилдик бербейт. Бул системанын жалпы жооп берүү жөндөмдүүлүгүн жакшыртуу үчүн зарыл болсо, же учурдагы көйгөйлөрдү чечсе гана колдонулушу керек.
Кошумча материалдар:
Кененирээк окуу
Source: www.habr.com