Мақаланың аудармасы курстың басталу қарсаңында дайындалды .
Уақыт өте келе Gluster компаниясының ядроны теңшеуге қатысты ұсыныстары және бұл қажет пе деген сұрақтар туындайды.
Бұл қажеттілік сирек туындайды. Негізгі жұмыс жүктемелерінің көпшілігінде өте жақсы жұмыс істейді. Кемшілігі болса да. Тарихи тұрғыдан алғанда, Linux ядросы мүмкіндік берілсе, оның ішінде өнімділікті жақсартудың негізгі құралы ретінде кэштеу үшін де көп жадты жұмсайды.
Көп жағдайда бұл жақсы жұмыс істейді, бірақ ауыр жүктеме кезінде ол қиындықтар тудыруы мүмкін.
Бізде CAD, EDA және т.б. сияқты жадты көп тұтынатын, жоғары жүктеме кезінде баяулай бастаған жүйелермен жұмыс істеуде үлкен тәжірибеміз бар. Кейде біз Gluster-де қиындықтарға тап болдық. Пайдаланылған жадты және дискіні бір күннен астам күту уақытын мұқият бақылаған соң, біз дискіні шамадан тыс жүктеу, үлкен iowait, ядро қателері (ядро ойы), қатып қалу және т.б. алдық.
Бұл мақала әртүрлі жағдайларда орындалған көптеген параметрлерді баптау эксперименттерінің нәтижесі болып табылады. Осы параметрлердің арқасында жалпы жауап беру қабілеті жақсарып қана қоймай, кластердің жұмысы да айтарлықтай тұрақтандырылды.
Жадты конфигурациялауға келетін болсақ, бірінші кезекте сізді шатастыруы мүмкін көптеген опциялар бар виртуалды жад ішкі жүйесі (VM) қарастырылады.
vm.swappiness
Параметр vm.swappiness RAM-мен салыстырғанда ядроның свопты қаншалықты пайдаланатынын анықтайды. Ол сондай-ақ бастапқы кодта «карталанған жадты ұрлау үрдісі» ретінде анықталған. Жоғары ауыстыру мәні ядроның салыстырылған беттерді ауыстыруға бейім болатынын білдіреді. Төмен ауыстыру мәні керісінше білдіреді: ядро беттерді жадтан азырақ ауыстырады. Басқаша айтқанда, мән соғұрлым жоғары болады vm.swappiness, жүйе свопты көбірек пайдаланады.
Свопингті кеңінен пайдалану қажет емес, өйткені деректердің үлкен блоктары жедел жадқа жүктеледі және түсіріледі. Көптеген адамдар свопинг мәні жоғары болуы керек деп санайды, бірақ менің тәжірибемде оны «0» мәніне қою жақсы өнімділікке әкеледі.
Толығырақ мына жерден оқи аласыз -
Бірақ тағы да, бұл параметрлерді сақтықпен және арнайы қолданбаны тексергеннен кейін ғана пайдалану керек. Жоғары жүктелген ағынды қолданбалар үшін бұл параметр «0» мәніне орнатылуы керек. «0» мәніне өзгертілген кезде жүйенің жауап беру қабілеті жақсарады.
vm.vfs_cache_pressure
Бұл параметр каталог нысандары мен инодтарды кэштеу үшін ядромен тұтынылатын жадты басқарады (dentry және inode).
Әдепкі мәні 100 болса, ядро беткэшіне және свопкэшке әділ түрде dentry және inode кэштерін босатуға әрекет жасайды. vfs_cache_pressure төмендеуі ядроның dentry және inode кэштерін сақтауға әкеледі. Мән «0» болғанда, ядро жад қысымына байланысты тісжегі мен инод кэшін ешқашан тазартпайды және бұл жадтың жеткіліксіз қатесіне оңай әкелуі мүмкін. vfs_cache_pressure мәнін 100-ден жоғары ұлғайту ядроның dentry және inode бет шығуларына басымдық беруін тудырады.
GlusterFS пайдаланған кезде деректердің үлкен көлемі және көптеген шағын файлдары бар көптеген пайдаланушылар inode/dentry кэштеуіне байланысты серверде оперативті жадтың айтарлықтай көлемін оңай пайдалана алады, бұл ядроның жүйедегі деректер құрылымдарын өңдеуі керек болғандықтан нашар өнімділікке әкелуі мүмкін. 40 ГБ жады бар. Бұл параметрді 100-ден жоғары етіп орнату көптеген пайдаланушыларға жақсырақ кэштеу мен ядроның жауап беру қабілетін жақсартуға көмектесті.
vm.dirty_background_ratio және vm.dirty_ratio
Бірінші параметр (vm.dirty_background_ratio) лас беттері бар жадтың пайызын анықтайды, оған жеткенде лас беттерді дискіге фондық тазалауды бастау қажет. Бұл пайызға жеткенше беттер дискіге тазартылмайды. Қалпына келтіру басталған кезде ол жұмыс істеп тұрған процестерді тоқтатпай фондық режимде жұмыс істейді.
Екінші параметр (vm.dirty_ratio) мəжбүрлі жарқыл басталғанға дейін кір беттер алатын жад пайызын анықтайды. Осы шекке жеткеннен кейін барлық процестер синхронды болады (бұғатталған) және олар сұраған енгізу/шығару әрекеті нақты аяқталмайынша және деректер дискіде болғанша жұмысты жалғастыруға рұқсат етілмейді. Енгізу/шығару жүктемесі жоғары болса, бұл мәселені тудырады, себебі деректерді кэштеу жоқ және енгізу/шығару әрекеттерін орындайтын барлық процестер енгізу/шығару күту кезінде блокталады. Бұл көптеген ілулі процестерге, жоғары жүктемеге, жүйенің тұрақсыздығына және нашар өнімділікке әкеледі.
Бұл параметрлердің мәндерін азайту деректердің дискіге жиі қайталануын және жедел жадта сақталмауын тудырады. Бұл 45-90 ГБ бет кэштерін дискіге тазарту қалыпты жағдай болып табылатын жады ауыр жүйелерге көмектесе алады, нәтижесінде алдыңғы қосымшалар үшін үлкен кідіріс пайда болады, жалпы жауап беру қабілеті мен интерактивтілік төмендейді.
"1" > /proc/sys/vm/pagecache
Бет кэші – файлдар мен орындалатын бағдарламалардан деректерді сақтайтын кэш, яғни бұл файлдардың немесе блок құрылғыларының нақты мазмұны бар беттер. Бұл кэш дискіні оқу санын азайту үшін қолданылады. «1» мәні кэш оперативті жадтың 1% пайдаланатынын және ЖЖҚ-ға қарағанда дискіден көбірек оқылатынын білдіреді. Бұл параметрді өзгерту қажет емес, бірақ бет кэшін басқаруға параноид болсаңыз, оны пайдалана аласыз.
"соңғы мерзім" > /sys/block/sdc/queue/cheduler
Енгізу/шығару жоспарлаушысы оқу және жазу кезектерін өңдейтін Linux ядросының құрамдас бөлігі болып табылады. Теориялық тұрғыдан ақылды RAID контроллері үшін «noop» қолданған дұрыс, себебі Linux дискінің физикалық геометриясы туралы ештеңе білмейді, сондықтан дискінің геометриясын жақсы білетін контроллерге сұрауды келесідей өңдеуге мүмкіндік беру тиімдірек. мүмкіндігінше тез. Бірақ «соңғы мерзім» өнімділікті жақсартатын сияқты. Жоспарлаушылар туралы қосымша ақпаратты Linux ядросының бастапқы кодының құжаттамасынан табуға болады: linux/Documentation/block/*osched.txt. Сондай-ақ аралас операциялар (көп жазулар) кезінде оқу өткізу қабілетінің жоғарылауын байқадым.
"256" > /sys/block/sdc/queue/nr_requests
Жоспарлаушыға жіберілгенге дейін буфердегі енгізу/шығару сұрауларының саны. Кейбір контроллерлердің ішкі кезек өлшемі (queue_depth) енгізу/шығару жоспарлағышының nr_сұрауларынан үлкенірек, сондықтан енгізу/шығару жоспарлаушысының сұрауларды дұрыс басымдылықпен біріктіру және біріктіру мүмкіндігі аз. Мерзімі мен CFQ жоспарлаушылары үшін nr_requests контроллердің ішкі кезегінен 2 есе үлкен болғанда жақсы. Сұрауларды біріктіру және ретін өзгерту жоспарлаушыға ауыр жүктеме кезінде жауап беруге көмектеседі.
echo "16" > /proc/sys/vm/page-cluster
Бет кластері параметрі бір уақытта свопқа жазылатын беттер санын басқарады. Жоғарыдағы мысалда RAID жолағы өлшемі 16 КБ сәйкес болу үшін мән «64» мәніне орнатылған. Ауыстыру = 0 болғанда бұл мағынасы жоқ, бірақ айырбастауды 10 немесе 20 мәніне орнатсаңыз, RAID жолағы өлшемі 64 Кбайт болғанда бұл мәнді пайдалану сізге көмектеседі.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc немесе dev_mapper)
Көптеген RAID контроллерлері үшін әдепкі блок құрылғысының параметрлері жиі қорқынышты өнімділікке әкеледі. Жоғарыдағы опцияны қосу 4096*512 байт секторлары үшін алдын ала оқуды конфигурациялайды. Кем дегенде ағынды операциялар үшін, ядро енгізу/шығару дайындау үшін пайдаланатын кезеңде алдын ала оқу арқылы чиптегі дискінің кэшін толтыру арқылы жылдамдық артады. Кэш келесі оқу кезінде сұралатын деректерді сақтай алады. Алдын ала оқудың тым көп болуы ықтимал пайдалы диск уақытын пайдаланса немесе деректерді кэштен тыс жүктесе, үлкен файлдар үшін кездейсоқ енгізу/шығаруды жоюы мүмкін.
Төменде файлдық жүйе деңгейінде тағы бірнеше ұсыныстар берілген. Бірақ олар әлі сынақтан өткен жоқ. Файлдық жүйе жолақ өлшемін және массивтегі дискілердің санын білетініне көз жеткізіңіз. Мысалы, бұл алты дискіден тұратын 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))Үлкенірек файлдар үшін жоғарыдағы жолақ өлшемдерін ұлғайту мүмкіндігін қарастыруға болады.
ЕСКЕРТУ! Жоғарыда сипатталған барлық қолданбалардың кейбір түрлері үшін өте субъективті. Бұл мақала алдымен пайдаланушының тиісті қолданбаларды сынамайынша жақсартуларға кепілдік бермейді. Ол жүйенің жалпы жауап беру қабілетін жақсарту қажет болған жағдайда немесе ағымдағы мәселелерді шешсе ғана қолданылуы керек.
Дополнительные материалдар:
Ары қарай оқу
Ақпарат көзі: www.habr.com