మెమరీ లీక్లను ట్రాక్ చేయడం ద్వారా సర్వర్ వనరుల వినియోగాన్ని మెరుగుపరచడం
మేము అన్వేషించిన మొదటి పరికల్పన ఏమిటంటే, గేమ్ల మెమరీ వినియోగం యొక్క నమూనా మారుతోందనేది. మేము డెవలపర్లను ప్లాట్ఫారమ్ యొక్క పరిమితులను అధిగమించమని, అద్భుతమైన మరియు విప్లవాత్మక గేమ్లను రూపొందించడానికి వారి వద్ద ఉన్న వనరులను ఉపయోగించుకోమని ప్రోత్సహిస్తాము. దీనిని తనిఖీ చేయడం సులభం, మేము అన్ని గేమ్ల మెమరీ వినియోగాన్ని సమీకరించి, అది పెరిగిందో లేదో చూడవచ్చు. కానీ ఫలితం లేదు, మా సామర్థ్యం స్థిరంగా తగ్గుతున్నప్పటికీ, ప్రతి గేమ్ యొక్క సగటు మెమరీ మరియు పెర్సంటైల్ సమీకరణలు దాదాపుగా స్థిరంగా ఉన్నాయి.
మేము ప్రతి నెలా టెరాబైట్ల పనితీరు మరియు వనరుల వినియోగ డేటాను నిల్వ చేస్తాము, దీనిని సమీకరించి, ఫిల్టర్ చేసి, ఇలాంటి సమస్యల మూల కారణాన్ని కనుగొనడంలో సహాయపడవచ్చు. మేము ఈ సమస్యను ఒక నిర్దిష్ట భౌగోళిక ప్రాంతానికి, హార్డ్వేర్ రకానికి, సాఫ్ట్వేర్ వెర్షన్కు పరిమితం చేయడానికి ప్రయత్నించాము, కానీ దురదృష్టవశాత్తు ఈ సమస్య ప్రతిచోటా ఉంది. అప్పుడు మేము కొన్ని గేమ్ సర్వర్లను యాదృచ్ఛికంగా తనిఖీ చేసి, సూక్ష్మంగా దర్యాప్తు చేయాలని నిర్ణయించుకున్నాము. ప్రారంభంలో, Linux సిస్టమ్లలో "ఫ్రీ" మెమరీ అనే భావన నన్ను తప్పుదారి పట్టించింది. ఇది ఎంత సాధారణమైన సమస్యో చెప్పాలంటే, మెమరీ వర్గాలను వివరించడానికి ఒకరు డొమైన్ రిజిస్టర్ చేసి, వెబ్సైట్ను ఏర్పాటు చేశారు: https://www.linuxatemyram.com.
TL;DR: మీ మెమరీలో ఎక్కువ భాగం ఉపయోగించబడటం మంచిది, ఖాళీగా ఉన్న మెమరీ అంటే వృధా అయిన మెమరీ. అందుబాటులో ఉన్న మెమరీ 0కి దగ్గరగా ఉన్నప్పుడు మాత్రమే మనం ఆందోళన చెందాలి.
మేము మెమరీని సరిగ్గా ట్రాక్ చేస్తున్నామని నిర్ధారించుకున్న తర్వాత, ఆ మెమరీ ఎక్కడ ఉపయోగించబడుతుందో తెలుసుకోవడానికి ఒక శ్రేణి ప్రయోగాలను ప్రారంభించాము. లక్షిత పరిష్కారాన్ని అందించడానికి, నిర్దిష్ట మెమరీ ఉప-వర్గాలను ట్రాక్ చేయడమే మా విధానం.
అందుబాటులో ఉన్న మెమరీని సుమారుగా MemFree + Active(file) + Inactive(file) + SReclaimable ల మొత్తంగా లెక్కిస్తారు.
MemFree ఉపయోగించబడని మెమరీని ట్రాక్ చేస్తుంది.
యాక్టివ్(ఫైల్) మరియు ఇనాక్టివ్(ఫైల్) పేజ్ క్యాష్ మెమరీని ట్రాక్ చేస్తాయి. డిస్క్ I/O పరిమాణాన్ని తగ్గించడానికి, పేజ్ క్యాష్ యాక్సెస్ చేయబడిన డేటాను మెమరీలో నిల్వ చేస్తుంది.
SReclaimable తిరిగి పొందగల స్లాబ్ మెమరీని ట్రాక్ చేస్తుంది. కెర్నల్ ద్వారా సాధారణంగా ఉపయోగించబడే ఇనిషియలైజ్డ్ ఆబ్జెక్ట్ల కాష్లను ఉంచడానికి స్లాబ్ మెమరీ ఉపయోగించబడుతుంది.
మొదటి ప్రయోగం క్యాష్ ట్యూనింగ్ను సర్దుబాటు చేయడం, ప్రత్యేకంగా: vm.vfs_cache_pressure మరియు vm.dirty_background_ratio.
vfs_cache_pressure పెంచడం వలన, మనం రిక్లెయిమబుల్ క్యాష్ నుండి ఆబ్జెక్టులను తిరిగి పొందే అవకాశం ఎక్కువగా ఉంటుంది. దీనివల్ల పనితీరుపై ప్రభావం పడుతుంది (క్యాష్ మిస్సులు మరియు ఖాళీ చేయగల ఆబ్జెక్టులను కనుగొనడానికి పట్టే సమయం రెండింటిలోనూ).
డర్టీ_బ్యాక్గ్రౌండ్_రేషియో అనేది (పేజ్ క్యాష్ మెమరీలో మురికిగా ఉన్న భాగం యొక్క శాతం), దీనిని మేము డిస్క్కు బ్లాక్-చేయని పద్ధతిలో వ్రాయడం ప్రారంభించినప్పుడు ఉపయోగిస్తాము.
మేము ఈ క్రింది మార్పులు చేసి, మెమరీ, స్లాబ్ఇన్ఫో, మరియు cgroups లలో వాటి ప్రభావాలను గమనించాము.
vm.vfs_cache_pressure= 100 ==> 10000<br>vm.dirty_background_ratio= 10 ==> 5ఫలితాన్ని ట్రాక్ చేయడానికి ఒక నాన్-ఇన్వేసివ్ మార్గం ఏమిటంటే, మెమరీ స్థితి యొక్క స్నాప్షాట్ను తీసుకునే ఒక క్రాన్ జాబ్ను క్రమానుగతంగా అమలు చేయడం. ఇలాంటిది:
#!/bin/bash<br>now=`date +%Y-%m-%d.%H:%M`
# create test dir<br>mkdir -p ~/memtest # log meminfo<br>sudo cat /proc/meminfo
~/memtest/meminfo_$now# log slabinfo<br>sudo cat /proc/slabinfo
~/memtest/slabinfo_$now # log cgroups<br>sudo cat /proc/cgroups
~/memtest/cgroups_$now క్యాష్ ప్రెజర్ మార్పులను అమలు చేసి, కొన్ని గంటల పాటు గమనించిన తర్వాత మేము విశ్లేషణను ప్రారంభించాము. మేము సుమారు 8GB ఫ్రీ మెమరీని పొందామని నిర్ధారించుకున్నాము, కానీ ఆ మెమరీ నేరుగా పేజ్ మరియు డిస్క్ క్యాష్లు, అంటే యాక్టివ్(ఫైల్) మరియు ఇనాక్టివ్(ఫైల్) కేటగిరీల నుండి వచ్చింది. ఇది నిరాశాజనకమైన ఫలితం, అందుబాటులో ఉన్న మెమరీలో గణనీయమైన నికర పెరుగుదల లేదు, అంతేకాకుండా మేము ఈ మెమరీని ఇకపై ఫలవంతంగా ఉపయోగించడం లేదు. మేము వేరే చోట నుండి మెమరీని తిరిగి పొందవలసి వచ్చింది.
డైరెక్ట్గా అందుబాటులో ఉన్న మెమరీని పెంచడంలో విఫలమైన తర్వాత, పోటీ పడుతున్న కేటగిరీలను తగ్గించడానికి ప్రయత్నించాము. SUnreclaim మెమరీ కేటగిరీ పెద్దగా ఉందని, కొన్ని సందర్భాల్లో కొన్ని నెలల వ్యవధిలో 60GB వరకు పెరిగిందని మేము గమనించాము. SUnreclaim కేటగిరీ, ఆపరేటింగ్ సిస్టమ్ ద్వారా ఆబ్జెక్ట్ పూల్స్ కోసం ఉపయోగించబడిన మరియు మెమరీ ప్రెజర్ కింద తిరిగి పొందలేని మెమరీని ట్రాక్ చేస్తుంది. సమస్య యొక్క మొదటి సంకేతం నిరంతరం పెరుగుతున్న cgroups సంఖ్య. మా డాకరైజ్డ్ ప్రాసెస్లను రన్ చేయడం వల్ల గరిష్టంగా కొన్ని వందల cgroups ఉంటాయని మేము ఆశించాము, కానీ మేము లక్షల సంఖ్యలో cgroups ను చూస్తున్నాము. అదృష్టవశాత్తూ మాకు, ఫేస్బుక్ నుండి రోమన్ గుష్చిన్ అనే మరో ఇంజనీర్, కెర్నల్ స్థాయిలో ఇదే సమస్యను ఇటీవల కనుగొని పరిష్కరించినట్లు కనిపిస్తోంది https://patchwork.kernel.org/cover/10943797/. అతను ఇలా పేర్కొన్నాడు:
దీనిలోని అంతర్లీన సమస్య చాలా సులభం: cgroupకు ఛార్జ్ చేయబడిన ఏ పేజ్లోనైనా దాని రిఫరెన్స్ ఉంటుంది, కాబట్టి ఛార్జ్ చేయబడిన అన్ని పేజీలు పోయే వరకు ఆ cgroupను తిరిగి స్వాధీనం చేసుకోలేము. ఒకవేళ స్లాబ్ ఆబ్జెక్ట్ను ఇతర cgroupలు చురుకుగా ఉపయోగిస్తుంటే, దానిని తిరిగి స్వాధీనం చేసుకోరు, మరియు అది అసలు cgroupను తిరిగి స్వాధీనం చేసుకోకుండా నిరోధిస్తుంది.
ఇది సరిగ్గా మా సమస్యే అని అనిపించింది, కాబట్టి ఈ పరిష్కారాన్ని ధృవీకరించడానికి మేము ఆత్రుతగా కెర్నల్ 5.3 కోసం వేచి ఉన్నాము.
మేము క్యాష్ ప్రెజర్ ప్రయోగం నుండి మెమరీ ట్రాకింగ్ స్క్రిప్ట్ను తిరిగి ఉపయోగించాము, కానీ కెర్నల్ ప్రయోగం కోసం మేము నియంత్రణ మరియు ప్రయోగాత్మక సమూహాలను ఏర్పాటు చేయాలనుకున్నాము. మేము 2 ర్యాక్ల సర్వర్ల నుండి ప్రొడక్షన్ ట్రాఫిక్ను తీసివేశాము, ఆపై ఒక ర్యాక్లో కెర్నెల్ను 5.3కి అప్గ్రేడ్ చేసి, మరొక ర్యాక్లో కెర్నెల్ 5.0ను ఉంచాము. ఆ తర్వాత మేము రెండు ర్యాక్లను రీబూట్ చేసి, వాటిని మళ్లీ ప్రొడక్షన్ ట్రాఫిక్ కోసం తెరిచాము. సుమారు ఒక వారం తర్వాత, cgroups మరియు రికవరీ చేయలేని స్లాబ్ మెమరీ కాలక్రమేణా ఎలా మారాయో మేము ట్రాక్ చేశాము. ఫలితాలు ఇక్కడ ఉన్నాయి:
కర్నల్ 5.0.0లో cgroups యొక్క నిరంతర పెరుగుదల ఉంది మరియు ఒక వారంలో 4GB యొక్క తిరిగి పొందలేని స్లాబ్ మెమరీని సంపాదించి, మొత్తం 6GBకి చేరుకుంటుంది. మరోవైపు, కర్నల్ 5.3.7లో cgroupsలో గణనీయమైన రోజువారీ తగ్గుదలలు ఉన్నాయి, మరియు తిరిగి పొందలేని స్లాబ్ మెమరీ పెరుగుదల చాలా నెమ్మదిగా ఉంటుంది. ఒక వారం తర్వాత, రికవరీ చేయలేని స్లాబ్ మెమరీ ~2 GB ఉంటుంది. కొత్త కెర్నెల్తో, అనేక నెలల అప్టైమ్ తర్వాత కూడా, రికవరీ చేయలేని స్లాబ్ మెమరీ సుమారు 4 GB వద్ద స్థిరంగా ఉంటుంది.
మేము పరిష్కరించాలనుకున్న అసలు సమస్య ఏమిటంటే, కాలక్రమేణా మా గేమ్ సర్వర్లు తమ సామర్థ్యాన్ని కోల్పోతున్నాయి. దీనికి కారణం అందుబాటులో ఉన్న మెమరీ తగ్గడం, అది నిరంతరం పెరుగుతున్న రికవరీ చేయలేని స్లాబ్ మెమరీ వల్ల జరుగుతోంది. కాబట్టి, కెర్నల్ ఫిక్స్ కారణంగా మేము దానిని కొంతవరకు నియంత్రణలోకి తీసుకువచ్చిన తర్వాత, సర్వర్ సామర్థ్యంపై దాని ప్రభావం ఏమిటి?
ఎడమ వైపున, మీరు మా సమస్యను చూడవచ్చు, ప్రతి సర్వర్కు ఆటల సంఖ్య స్థిరంగా తగ్గడం, ఇది మా మౌలిక సదుపాయాలపై చాలా ఒత్తిడిని పెంచింది. మేము మార్చి 2020 ప్రాంతంలో మా గ్లోబల్ ఫ్లీట్ అంతటా కెర్నల్ వెర్షన్ 5.3ని అమలు చేశాము, మరియు ఇప్పటి వరకు అధిక సర్వర్ సామర్థ్యాన్ని నిర్వహించగలిగాము. కెర్నల్ ఫిక్స్ కోసం రోమన్ గుష్చిన్కు మరియు ఈ సమస్యను పరిశోధించడంలో, ఫిక్స్ను అమలు చేయడంలో సహాయం చేసినందుకు ఆండ్రీ ట్రాన్కు మా హృదయపూర్వక ధన్యవాదాలు.
రాబ్లాక్స్ కార్పొరేషన్ గానీ, ఈ బ్లాగ్ గానీ ఏ కంపెనీని లేదా సేవను ఆమోదించవు లేదా మద్దతు ఇవ్వవు. అలాగే, ఈ బ్లాగ్లో ఉన్న సమాచారం యొక్క ఖచ్చితత్వం, విశ్వసనీయత లేదా సంపూర్ణతకు సంబంధించి ఎలాంటి హామీలు లేదా వాగ్దానాలు చేయబడవు.
ఈ బ్లాగ్ పోస్ట్ వాస్తవానికి రాబ్లాక్స్ టెక్ బ్లాగ్లో ప్రచురించబడింది.
