వ్యాసం యొక్క అనువాదం కోర్సు ప్రారంభం సందర్భంగా తయారు చేయబడింది .
క్రమానుగతంగా, ఇక్కడ మరియు అక్కడ, కెర్నల్ ట్యూనింగ్‌కు సంబంధించి గ్లస్టర్ సిఫార్సుల గురించి మరియు దీని అవసరం ఉందా అనే ప్రశ్నలు తలెత్తుతాయి.
అలాంటి అవసరం చాలా అరుదుగా పుడుతుంది. చాలా పనిభారంలో, కెర్నల్ చాలా బాగా పని చేస్తుంది. ఒక ప్రతికూలత ఉన్నప్పటికీ. చారిత్రాత్మకంగా, Linux కెర్నల్ అవకాశం ఇచ్చినట్లయితే, పనితీరును మెరుగుపరచడానికి ప్రధాన మార్గంగా కాషింగ్‌తో సహా చాలా మెమరీని వినియోగించుకోవడానికి సిద్ధంగా ఉంది.
చాలా సందర్భాలలో, ఇది బాగా పనిచేస్తుంది, కానీ అధిక లోడ్లో ఇది సమస్యలకు దారి తీస్తుంది.
CAD, EDA మరియు వంటి మెమొరీ ఇంటెన్సివ్ సిస్టమ్‌లతో మాకు చాలా అనుభవం ఉంది, ఇది భారీ లోడ్లో నెమ్మదించడం ప్రారంభించింది. మరియు కొన్నిసార్లు మేము గ్లస్టర్‌లో సమస్యలను ఎదుర్కొంటాము. చాలా రోజుల పాటు మెమరీ వినియోగం మరియు డిస్క్ లేటెన్సీని జాగ్రత్తగా గమనించిన తర్వాత, మేము వాటి ఓవర్‌లోడ్, భారీ iowait, కెర్నల్ లోపాలు (కెర్నల్ అయ్యో), ఫ్రీజ్‌లు మొదలైనవి పొందాము.
ఈ వ్యాసం వివిధ పరిస్థితులలో చేసిన అనేక ట్యూనింగ్ ప్రయోగాల ఫలితం. ఈ పారామితులకు ధన్యవాదాలు, మొత్తం ప్రతిస్పందన మెరుగుపడటమే కాకుండా, క్లస్టర్ కూడా గణనీయంగా స్థిరీకరించబడింది.
మెమరీ ట్యూనింగ్ విషయానికి వస్తే, మొదట చూడవలసిన విషయం వర్చువల్ మెమరీ సబ్‌సిస్టమ్ (VM, వర్చువల్ మెమరీ), ఇది మిమ్మల్ని గందరగోళానికి గురిచేసే పెద్ద సంఖ్యలో ఎంపికలను కలిగి ఉంటుంది.
vm.swappiness
పరామితి vm.swappiness RAMతో పోలిస్తే కెర్నల్ ఎంత స్వాప్ (స్వాప్, పేజింగ్) ఉపయోగిస్తుందో నిర్ణయిస్తుంది. ఇది సోర్స్ కోడ్‌లో "మ్యాప్ చేసిన మెమరీని దొంగిలించే ధోరణి"గా కూడా నిర్వచించబడింది. అధిక స్వాప్పీనెస్ అంటే కెర్నల్ మ్యాప్ చేయబడిన పేజీలను స్వాప్ చేయడానికి ఎక్కువ మొగ్గు చూపుతుంది. తక్కువ స్వాప్పీనెస్ విలువ అంటే వ్యతిరేకం: కెర్నల్ మెమరీ నుండి తక్కువ పేజీని కలిగి ఉంటుంది. మరో మాటలో చెప్పాలంటే, అధిక విలువ vm.swappiness, సిస్టమ్ స్వాప్‌ని ఎంత ఎక్కువగా ఉపయోగిస్తుంది.
పెద్ద మొత్తంలో ఇచ్చిపుచ్చుకోవడం అవాంఛనీయమైనది, ఎందుకంటే భారీ డేటా బ్లాక్‌లు ర్యామ్‌లోకి లోడ్ చేయబడతాయి మరియు అన్‌లోడ్ చేయబడతాయి. స్వాపైనెస్ విలువ పెద్దదిగా ఉండాలని చాలా మంది వాదించారు, కానీ నా అనుభవంలో, దానిని "0"కి సెట్ చేయడం మెరుగైన పనితీరుకు దారి తీస్తుంది.
మీరు ఇక్కడ మరింత చదవవచ్చు -
కానీ, మళ్ళీ, ఈ సెట్టింగ్‌లను జాగ్రత్తగా వర్తింపజేయాలి మరియు నిర్దిష్ట అప్లికేషన్‌ను పరీక్షించిన తర్వాత మాత్రమే. ఎక్కువగా లోడ్ చేయబడిన స్ట్రీమింగ్ అప్లికేషన్‌ల కోసం, ఈ పరామితిని "0"కి సెట్ చేయాలి. "0"కి మార్చినప్పుడు, సిస్టమ్ ప్రతిస్పందన మెరుగుపడుతుంది.
vm.vfs_cache_pressure
ఈ సెట్టింగ్ డైరెక్టరీ మరియు ఐనోడ్ ఆబ్జెక్ట్‌లు (డెంట్రీ మరియు ఐనోడ్) కాషింగ్ కోసం కెర్నల్ ద్వారా వినియోగించబడే మెమరీని నియంత్రిస్తుంది.
100 డిఫాల్ట్ విలువతో, కెర్నల్ డెంట్రీ మరియు ఐనోడ్ కాష్‌లను పేజ్‌కాష్ మరియు స్వాప్‌కాష్‌కి "ఫెయిర్" ప్రాతిపదికన ఖాళీ చేయడానికి ప్రయత్నిస్తుంది. vfs_cache_pressureని తగ్గించడం వలన కెర్నల్ డెంట్రీ మరియు ఐనోడ్ కాష్‌లను ఉంచుతుంది. విలువ "0" అయినప్పుడు, మెమరీ ఒత్తిడి కారణంగా కెర్నల్ డెంట్రీ మరియు ఐనోడ్ కాష్‌ను ఎప్పటికీ ఫ్లష్ చేయదు మరియు ఇది సులభంగా మెమరీలో లేని ఎర్రర్‌కు దారి తీస్తుంది. vfs_cache_pressure 100 కంటే ఎక్కువ పెరగడం వలన కెర్నల్ డెంట్రీ మరియు ఐనోడ్ ఫ్లషింగ్‌కు ప్రాధాన్యతనిస్తుంది.
GlusterFSని ఉపయోగిస్తున్నప్పుడు, పెద్ద మొత్తంలో డేటా మరియు అనేక చిన్న ఫైల్‌లు ఉన్న చాలా మంది వినియోగదారులు ఐనోడ్/డెంట్రీ కాషింగ్ కారణంగా సర్వర్‌లో గణనీయమైన మొత్తంలో RAMని సులభంగా ఉపయోగించగలరు, ఇది కెర్నల్ సిస్టమ్‌లో డేటా స్ట్రక్చర్‌లను ప్రాసెస్ చేయాల్సి ఉంటుంది కాబట్టి పనితీరు క్షీణతకు దారితీస్తుంది. 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-90 GB పేజీ కాష్‌లను డిస్క్‌కి ఫ్లష్ చేయడం సాధారణమైన మెమరీ-హెవీ సిస్టమ్‌లకు సహాయపడుతుంది, ఫలితంగా ఫ్రంట్-ఎండ్ అప్లికేషన్‌లకు భారీ జాప్యం ఏర్పడుతుంది, మొత్తం ప్రతిస్పందన మరియు ఇంటరాక్టివిటీని తగ్గిస్తుంది.
"1" > /proc/sys/vm/pagecache
పేజీ కాష్ అనేది ఫైల్‌లు మరియు ఎక్జిక్యూటబుల్ ప్రోగ్రామ్‌ల డేటాను నిల్వ చేసే కాష్, అంటే ఇవి ఫైల్‌లు లేదా బ్లాక్ పరికరాల యొక్క వాస్తవ కంటెంట్‌లతో కూడిన పేజీలు. ఈ కాష్ డిస్క్ రీడ్‌ల సంఖ్యను తగ్గించడానికి ఉపయోగించబడుతుంది. "1" విలువ అంటే 1% RAM కాష్ కోసం ఉపయోగించబడుతుంది మరియు RAM కంటే డిస్క్ నుండి ఎక్కువ రీడ్‌లు ఉంటాయి. ఈ సెట్టింగ్‌ని మార్చాల్సిన అవసరం లేదు, కానీ మీరు పేజీ కాష్‌ని నియంత్రించడంలో మతిస్థిమితం లేనివారైతే, మీరు దీన్ని ఉపయోగించవచ్చు.
"గడువు" > /sys/block/sdc/queue/షెడ్యూలర్
I/O షెడ్యూలర్ అనేది Linux కెర్నల్ భాగం, ఇది రీడ్ మరియు రైట్ క్యూలను నిర్వహిస్తుంది. సిద్ధాంతపరంగా, స్మార్ట్ RAID కంట్రోలర్ కోసం "noop"ని ఉపయోగించడం ఉత్తమం, ఎందుకంటే Linuxకి డిస్క్ యొక్క భౌతిక జ్యామితి గురించి ఏమీ తెలియదు, కాబట్టి డిస్క్ జ్యామితిని బాగా తెలిసిన కంట్రోలర్‌ను అభ్యర్థనను త్వరగా ప్రాసెస్ చేయడానికి అనుమతించడం మరింత సమర్థవంతమైనది. సాధ్యం. కానీ "డెడ్‌లైన్" పనితీరును మెరుగుపరుస్తుంది. మీరు Linux కెర్నల్ సోర్స్ కోడ్ డాక్యుమెంటేషన్‌లో షెడ్యూలర్‌ల గురించి మరింత చదవవచ్చు: linux/Documentation/block/*osched.txt. మరియు నేను మిశ్రమ కార్యకలాపాల సమయంలో రీడ్ త్రూపుట్‌లో పెరుగుదలను చూశాను (చాలా మంది వ్రాతలు).
"256" > /sys/block/sdc/queue/nr_requests
షెడ్యూలర్‌కు పంపడానికి ముందు బఫర్‌లోని I/O అభ్యర్థనల సంఖ్య. కొన్ని కంట్రోలర్‌ల అంతర్గత క్యూ పరిమాణం (క్యూ_డెప్త్) I/O షెడ్యూలర్ యొక్క nr_requests కంటే పెద్దది, కాబట్టి I/O షెడ్యూలర్‌కు అభ్యర్థనలకు సరైన ప్రాధాన్యతనిచ్చే మరియు విలీనం చేసే అవకాశం తక్కువ. గడువు మరియు CFQ షెడ్యూలర్‌ల కోసం, nr_requests కంట్రోలర్ యొక్క అంతర్గత క్యూ కంటే 2 రెట్లు ఎక్కువగా ఉంటే మంచిది. అభ్యర్థనలను విలీనం చేయడం మరియు క్రమాన్ని మార్చడం వలన షెడ్యూలర్ అధిక లోడ్లో మరింత ప్రతిస్పందించడానికి సహాయపడుతుంది.
echo "16" > /proc/sys/vm/page-cluster
పేజీ-క్లస్టర్ పరామితి ఒక సమయంలో స్వాప్‌కు వ్రాయబడిన పేజీల సంఖ్యను నియంత్రిస్తుంది. పై ఉదాహరణలో, విలువ 16 KB RAID స్ట్రిప్ పరిమాణం ప్రకారం "64"కి సెట్ చేయబడింది. స్వాప్పీనెస్ = 0తో అర్థం కాదు, కానీ మీరు స్వాప్పీనెస్‌ను 10 లేదా 20కి సెట్ చేస్తే, RAID స్ట్రిప్ పరిమాణం 64K ఉన్నప్పుడు ఈ విలువను ఉపయోగించడం మీకు సహాయం చేస్తుంది.
blockdev --setra 4096 /dev/<దేవ్పేరు> (-sdb, hdc లేదా dev_mapper)
అనేక RAID కంట్రోలర్‌ల కోసం డిఫాల్ట్ బ్లాక్ పరికర సెట్టింగ్‌లు తరచుగా భయంకరమైన పనితీరును కలిగిస్తాయి. పై ఎంపికను జోడించడం వలన 4096 * 512-బైట్ సెక్టార్‌ల కోసం రీడ్-ఎహెడ్ సెటప్ అవుతుంది. కనీసం, స్ట్రీమింగ్ కార్యకలాపాల కోసం, I/Oని సిద్ధం చేయడానికి కెర్నల్ ఉపయోగించే వ్యవధిలో ఆన్-చిప్ డిస్క్ కాష్‌ని రీడ్-ఎహెడ్‌తో నింపడం ద్వారా వేగం పెరుగుతుంది. కాష్ తదుపరి రీడ్‌లో అభ్యర్థించబడే డేటాను కలిగి ఉంటుంది. చాలా ఎక్కువ ప్రీఫెచ్ పెద్ద ఫైల్‌ల కోసం యాదృచ్ఛిక I/Oని నాశనం చేయగలదు, అది ఉపయోగకరమైన డిస్క్ సమయాన్ని ఉపయోగించినట్లయితే లేదా కాష్ వెలుపల డేటాను లోడ్ చేస్తుంది.
ఫైల్ సిస్టమ్ స్థాయిలో మరికొన్ని సిఫార్సులు క్రింద ఉన్నాయి. కానీ వాటిని ఇంకా పరీక్షించలేదు. మీ ఫైల్‌సిస్టమ్‌కు చారల పరిమాణం మరియు శ్రేణిలోని డిస్క్‌ల సంఖ్య తెలుసునని నిర్ధారించుకోండి. ఉదాహరణకు, ఇది ఆరు డిస్క్‌ల 5K స్ట్రిప్ రైడ్64 శ్రేణి (వాస్తవానికి ఐదు, ఎందుకంటే ఒక డిస్క్ సమానత్వం కోసం ఉపయోగించబడుతుంది). ఈ సిఫార్సులు సైద్ధాంతిక అంచనాలపై ఆధారపడి ఉంటాయి మరియు 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