మెమొరీ మరియు స్వాప్: ఎప్పుడు అధిక టియర్ అవసరం

"2 GBలో 120 MB ఖాళీగా ఉంది" అనే మాట కొత్తవారిని భయపెడుతుంది, అయితే Linuxలో దీనికి అర్థం ఏమీ లేదు: ఖాళీ మెమొరీ వృథా కాబట్టి, సిస్టమ్ ఉద్దేశపూర్వకంగా ఫైల్ క్యాష్ కోసం ఖాళీ మెమొరీని ఉపయోగిస్తుంది. అసలైన చిత్రాన్ని వేరే కాలమ్ చూపిస్తుంది.

ఖాళీ మెమొరీని సరిగ్గా చదవడం

free -h
#               total  used   free  shared  buff/cache  available
# Mem:          1.9Gi  742Mi  102Mi    18Mi       1.1Gi      1.0Gi
# Swap:         1.0Gi  126Mi  898Mi

available వైపు చూడండి — క్యాష్ను తొలగించి ఒక అప్లికేషన్ ఎంత మెమొరీని పొందగలదో అది చూపిస్తుంది. ఈ విలువ సున్నా కంటే బాగా ఎక్కువగా ఉన్నంత కాలం, మెషీన్ బాగానే ఉంది. ఈ అర్థంలో free పనికిరాదు.

హెచ్చరిక సంకేతాలు:

• available అనేది totalలో 10% కంటే తక్కువగా ఉండటం;
• Swap used పెరుగుతూ, విడుదల కాకపోవడం;
• vmstat 2లో si/so సున్నా కానివిగా, స్థిరంగా ఉండటం — సిస్టమ్ నిరంతరం డిస్క్కు పేజింగ్ చేస్తోంది.

మెమొరీని సరిగ్గా ఏది తింటోంది:

ps aux --sort=-%mem | head -10
smem -tk -s uss 2>/dev/null | tail -10

Swap: అవసరమా, లేదా

ఏ టియర్లోనైనా కొద్దిపాటి swap ఉపయోగకరం: చాలా కాలంగా ఉపయోగించని పేజీలను తరలించడానికి అది సిస్టమ్కు స్థలం ఇస్తుంది, చిన్న స్పైక్ సమయంలో ఒక ప్రాసెస్ తక్షణమే చనిపోకుండా కాపాడుతుంది. అయితే అది మెమొరీకి ప్రత్యామ్నాయం కాదు — డిస్క్ వందల రెట్లు నెమ్మదిగా ఉంటుంది.

2 GB swap ఫైల్ను సృష్టించండి:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

సిస్టమ్ అతిగా swap చేయాలనే ఉత్సాహాన్ని అదుపు చేయండి:

sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf

swap ఫైల్ టియర్ డిస్క్లో స్థలాన్ని ఆక్రమిస్తుంది (VDS-1లో 40 GB), దానిలో రాయడం డిస్క్ వేగం బ్యాండ్విడ్త్ను వినియోగిస్తుంది అనే విషయాన్ని గుర్తుంచుకోండి, చూడండి డిస్క్ లోడ్.

లీకా, లేదా మెమొరీ సరిపోకపోవడమా

ప్యానెల్ /hosting/vds/m/<id>లోని మెమొరీ గ్రాఫ్ వారానికి ఒకసారి స్కేల్లో ఈ రెండింటిని వేరు చేయడంలో సహాయపడుతుంది:

• రంపపు పళ్లు — పైకప్పు వరకు పెరుగుతుంది, సేవ రీస్టార్ట్ అయినప్పుడు పడిపోతుంది, మళ్లీ పెరుగుతుంది. ఇది అప్లికేషన్లోని లీక్; ఎక్కువ టియర్ సమస్యను వాయిదా వేస్తుంది మాత్రమే.
• మొదటి నుంచే పైకప్పు వద్ద చదునైన పీఠభూమి — పని చేసే సెట్కు స్థలం సరిపోవడం లేదు.
• ఒక్కసారిగా పడిపోవడం — OOM killer ప్రాసెస్ను చంపింది; మెమొరీ అయిపోయింది అనే వ్యాసం చూడండి.

ప్లాన్ మార్చే ముందు, స్పష్టమైన విషయాలను చూసుకోండి: journal కోసం SystemMaxUseను పరిమితం చేయండి, డేటాబేస్కు సహేతుకమైన పరిమితులు పెట్టండి (MySQL డిఫాల్ట్గా చాలా ఎక్కువ అడుగుతుంది), ఉపయోగించని సేవలను తీసివేయండి (systemctl list-units --type=service --state=running), PHP-FPM మరియు Gunicorn కోసం వర్కర్ల సంఖ్యను తగ్గించండి.

ఎప్పుడు అప్గ్రేడ్ చేయాలి

శుభ్రం చేసిన తర్వాత కూడా available వారాల పాటు సున్నా దగ్గరే ఉంటే, swap నిరంతరం వాడుకలో ఉంటే, మరియు మొత్తం అప్లికేషన్ మీకు అవసరమైతే, ఎక్కువ టియర్ తీసుకోండి. మెమొరీ 2, 4, 8, 16, 24, 32 GB శ్రేణిలో పెరుగుతుంది. అప్గ్రేడ్లు పైకి మాత్రమే, మిగిలిన రోజులకు అదనపు చెల్లింపుతో; డౌన్గ్రేడ్లు అందుబాటులో లేవు: డిస్క్ తగ్గదు. వివరాల కోసం, ప్లాన్ అప్గ్రేడ్ అనే వ్యాసం చూడండి.

సాధారణ తప్పులు

• swapను పూర్తిగా నిలిపివేయడం. స్పైక్ సమయంలో, ఒక నిమిషం పాటు నిలబడటానికి బదులుగా సిస్టమ్ ప్రాసెస్ను చంపేస్తుంది.
• డిస్క్ సైజు అంత swap చేయడం. మెషీన్ చనిపోదు, కానీ గంటల తరబడి నెమ్మదిగా కదులుతుంది, ఇది త్వరిత క్రాష్ కంటే దారుణం.
• htopలో VIRT వైపు చూడటం. JVM, PostgreSQL, Node కోసం వర్చువల్ సైజు భారీగా ఉంటుంది, అది వినియోగాన్ని ప్రతిబింబించదు. RES వైపు చూడండి.

మెమొరీని అంతరాయం తర్వాత కాదు, దానికి ముందే తనిఖీ చేయాలి. థ్రెషోల్డ్ హెచ్చరికలను సెటప్ చేయండి — సైట్ డౌన్టైమ్ హెచ్చరికలు అనే వ్యాసంలో ఒక సులభమైన విధానం ఉంది.