क्या VPS के लिए swap जरूरी है? सही साइज कैसे चुनें

क्या आपके VPS को swap की आवश्यकता है?

अधिकांश cloud images में swap नहीं होता है, और एक छोटे VPS पर इसका उत्तर आमतौर पर 'हाँ' होता है, एक swap file जोड़ें। Swap 1 GB के सर्वर को 2 GB के सर्वर जैसा नहीं बनाता है। यह kernel को cold anonymous pages रखने के लिए जगह देता है, जिससे page cache उपयोगी बना रहता है और OOM killer (out of memory killer, वह kernel routine जो memory खाली करने के लिए किसी process को चुनकर उसे kill कर देता है) पहली प्राथमिकता के बजाय अंतिम विकल्प बन जाता है।

संक्षेप में: एक ऐसे सर्वर पर जो कुछ लंबी अवधि तक चलने वाली services चलाता है, एक छोटी swap file उस disk space के लायक है जो वह लेती है। ऐसे सर्वर पर जहाँ एक process नियमित रूप से पूरी machine की क्षमता से अधिक memory allocate करने का प्रयास करती है, swap आपको नहीं बचाएगा, और यह failure को धीमा और पहचानने में कठिन बना देगा। इस guide का शेष भाग इन दोनों स्थितियों में अंतर करने और उन दो लागतों के बारे में है जो केवल VPS पर दिखाई देती हैं।

नीचे दिए गए प्रत्येक command के लिए आपके अपने सर्वर पर root access की आवश्यकता है, इसलिए उन्हें किसी और के सर्वर के output को copy करने के बजाय अपने सर्वर पर चलाएं।

Swap वास्तव में क्या करता है, और क्या नहीं करता

Linux मेमोरी दो प्रकार की होती है। File backed pages उन चीजों की प्रतियां हैं जो पहले से ही डिस्क पर मौजूद हैं: आपके प्रोग्राम और हर वह फाइल जिसे आपने हाल ही में पढ़ा है। यह संग्रह page cache कहलाता है। Anonymous pages वह मेमोरी है जिसके पीछे कोई फाइल नहीं होती: heap और stack, साथ ही वह अधिकांश डेटा जिसे कोई डेटाबेस रनटाइम पर allocate करता है।

जब मेमोरी कम पड़ जाती है, तो kernel को pages को reclaim करना पड़ता है। एक clean file backed page को reclaim करना आसान है, क्योंकि डिस्क पर उसकी प्रतिलिपि मौजूद रहती है और उस page को बाद में फिर से पढ़ा जा सकता है। एक anonymous page के साथ ऐसा नहीं है, क्योंकि उसकी एकमात्र प्रतिलिपि RAM में ही होती है। Swap के बिना, kernel के पास anonymous memory के लिए दो ही विकल्प होते हैं: उसे बनाए रखना, या उस प्रक्रिया (process) को kill कर देना जो उसकी स्वामी है।

बिना swap वाला सर्वर भी paging करता है। वह बस गलत मेमोरी की paging करता है। दबाव में, kernel page cache को छोटा कर देता है, और उन file pages को हटा देता है जिनकी उसे तुरंत फिर से आवश्यकता होने वाली है, जिसमें चल रहे प्रोग्रामों का executable text भी शामिल है। वे pages major page faults के रूप में वापस आते हैं। आप vmstat के bi कॉलम में डिस्क रीड देखते हैं और /proc/vmstat में एक बढ़ता हुआ pgmajfault काउंटर देखते हैं, जबकि si और so पूरे समय शून्य पर रहते हैं। सिस्टम thrashing कर रहा है और swap काउंटर कुछ भी रिपोर्ट नहीं कर रहे हैं।

Swap जो नहीं करता, वह है क्षमता बढ़ाना। यदि working set, जिसका अर्थ है वे pages जिन्हें वास्तव में access किया जा रहा है, RAM से बड़े हैं, तो swap एक out of memory kill को एक बहुत धीमे सर्वर में बदल देता है। कभी-कभी आप यही चाहते हैं, क्योंकि एक धीमे सर्वर में login करके उसे ठीक किया जा सकता है, जबकि एक kill हो चुके डेटाबेस के साथ ऐसा नहीं हो सकता। कभी-कभी यह स्थिति और भी खराब होती है, क्योंकि एक धीमा सर्वर हर कनेक्शन को खुला रखते हुए health checks में विफल होता रहता है। इसे जोड़ने से पहले तय करें कि आप क्या चाहते हैं।

Cloud images में swap क्यों नहीं होता है?

यह एक सोच-समझकर लिया गया निर्णय है। एक ही image को प्रदाता द्वारा बेचे जाने वाले हर plan पर boot होना होता है, इसलिए एक निश्चित swap partition छोटे plans पर disk space बर्बाद करेगा और बड़े plans पर इसका कोई उपयोग नहीं होगा। Swap की गति guest के नीचे मौजूद storage पर निर्भर करती है, जिसके बारे में image को पहले से जानकारी नहीं हो सकती। इसके अलावा, image builders अनुमानित व्यवहार (predictable behaviour) के लिए optimize करते हैं, क्योंकि जो process तुरंत बंद हो जाती है, उसे पूरे fleet में diagnose करना उस machine की तुलना में आसान है जो चालू रहती है और हर request का जवाब कुछ सेकंड देरी से देती है।

ये कारण disposable machines के लिए हैं। एक VPS जिसे आप लंबे समय तक रखते हैं, वह अलग मामला है। आप उसे बदलने के बजाय ठीक करते हैं, इसलिए आमतौर पर कुछ सेकंड की paging, service के बंद होने (killed service) से बेहतर होती है। यह मानकर चलें कि swap का न होना किसी और के उपयोग के लिए बनाया गया default है।

VPS पर swap file या swap partition?

Swap file का उपयोग करें। Partition का अर्थ है एक ऐसे disk पर live root filesystem का आकार बदलना जो पहले से ही partitioned है, जिसमें बिना किसी लाभ के वास्तविक जोखिम होता है। एक file को सामान्य commands के साथ बनाया और हटाया जा सकता है, और आप partition table को छुए बिना बाद में इसका आकार बदल सकते हैं।

गति निर्णायक कारक नहीं है। swapon के समय kernel file के extent map को एक बार पढ़ता है और फिर सीधे block device पर I/O सबमिट करता है, इसलिए प्रत्येक page in और page out के दौरान filesystem रास्ते में नहीं आता है। एक ही disk पर, swap file और swap partition समान प्रदर्शन करते हैं।

दो सीमाओं को जानना आवश्यक है। Swap को NFS (network file system) जैसे network filesystem पर न रखें। और btrfs पर file में copy on write अक्षम (disabled) और compression बंद होना चाहिए, यही कारण है कि btrfs इसे बनाने के लिए अपना स्वयं का helper प्रदान करता है।

Ubuntu या Debian पर swap file कैसे जोड़ें

कुछ भी बदलने से पहले यह जाँच लें कि आपके पास क्या उपलब्ध है।

swapon --show
free -h
findmnt -no FSTYPE /

swapon --show से खाली आउटपुट का मतलब है कि कोई swap मौजूद नहीं है, जो कि एक नए cloud image की सामान्य स्थिति है। findmnt root filesystem का प्रकार बताता है, और इसी से तय होता है कि आप फाइल कैसे बनाएंगे। ext4 पर, जिसका उपयोग अधिकांश cloud images करते हैं, fallocate सुरक्षित है।

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

chmod को जानबूझकर mkswap से पहले रखा गया है। यदि आप इसे छोड़ देते हैं, तो mkswap आपको यह चेतावनी देगा: mkswap: /swapfile: insecure permissions 0644, fix with: chmod 0600 /swapfile। एक world-readable swap file सिस्टम के हर user को वह मेमोरी दे देती है जिसे अन्य processes ने swap out किया था। इसके बाद एक सही mkswap आकार की पुष्टि करता है, जिसमें Setting up swapspace version 1, size = 2 GiB (2147479552 bytes) जैसी एक लाइन दिखाई देती है।

xfs या btrfs पर अंतिम कमांड swapon: /swapfile: swapon failed: Invalid argument के साथ विफल हो सकती है। XFS पर ऐसा इसलिए होता है क्योंकि fallocate unwritten extents छोड़ देता है, इसलिए इसके बजाय bytes लिखें।

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

btrfs पर इसका कारण copy-on-write है, और वर्तमान btrfs-progs आपके लिए सही flags सेट कर देता है।

sudo btrfs filesystem mkswapfile --size 2g /swapfile

किसी भी स्थिति में, chmod 600, जहाँ लागू हो वहाँ mkswap, और swapon के साथ प्रक्रिया पूरी करें, फिर परिणाम की पुष्टि करें।

swapon --show
free -h

swapon --show को file प्रकार के साथ /swapfile और आपके द्वारा मांगे गए आकार को सूचीबद्ध करना चाहिए, और free -h को एक Swap पंक्ति दिखानी चाहिए जिसमें लगभग कुछ भी उपयोग न हुआ हो। एक नए सेटअप पर शून्य swap उपयोग सही है। kernel केवल तभी pages को वहां ले जाता है जब उसके पास कोई कारण हो।

इसे reboot के बाद भी सक्रिय रखें, फिर तुरंत entry का परीक्षण करें।

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
sudo swapoff /swapfile
sudo swapon -a
swapon --show

swapon -a, /etc/fstab को पढ़ता है, इसलिए एक गलत लाइन अभी, आपके सामने ही विफल हो जाएगी। जिस typo का आप परीक्षण नहीं करते, वह आपको unplanned reboot के दौरान मिलता है, जब सिस्टम उस swap के बिना वापस आता है जिसे आप मौजूद समझ रहे थे।

बाद में swap हटाने के लिए, sudo swapoff /swapfile चलाएं, fstab लाइन को हटाएं, फिर sudo rm /swapfile करें। swapoff को पहले हर paged-out page को वापस RAM में पढ़ना पड़ता है, इसलिए एक व्यस्त सिस्टम पर यह swapoff: /swapfile: swapoff failed: Cannot allocate memory के साथ विफल हो सकता है। कुछ मेमोरी खाली करें और पुनः प्रयास करें।

Swap file का आकार कितना होना चाहिए?

यह कार्य cold anonymous pages को होल्ड करता है, इसलिए महत्वपूर्ण यह है कि आपकी allocated memory का कितना हिस्सा वास्तव में idle है, न कि यह कि plan में कितनी RAM है। Idle memory, plan के आकार के साथ नहीं बढ़ती है, इसलिए जैसे-जैसे plans बड़े होते जाते हैं, multiplier कम होता जाता है। यह गाइड इसी नियम का पालन करती है।

[
  {
    "label": "1 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 2
  },
  {
    "label": "2 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 1
  },
  {
    "label": "4 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 0.5
  },
  {
    "label": "8 GB plan",
    "swap_gb": 4,
    "swap_x_ram": 0.5
  },
  {
    "label": "16 GB plan",
    "swap_gb": 4,
    "swap_x_ram": 0.25
  }
]

सबसे छोटे plan पर 2 GB का swap होता है, जो RAM का 2 गुना है, क्योंकि 1 GB वाले box में headroom इतना कम होता है कि एक भी spike OOM killer को सक्रिय कर सकता है। चार्ट के ऊपरी स्तर पर यह फाइल 4 GB पर रुक जाती है, या RAM का 0.25 गुना होती है, क्योंकि shared storage पर इतना अधिक डेटा paging करने में इतना समय लगता है कि सर्वर प्रभावी रूप से down हो जाता है। यदि आपके पास disk की जगह कम है, तो इन numbers को कम करें, क्योंकि यह फाइल वास्तविक disk space लेती है।

Swap को RAM के बराबर या उससे अधिक रखने का एक क्लासिक कारण hibernation है, जो पूरी memory image को swap में लिख देता है। एक VPS hibernate नहीं होता है, इसलिए वह नियम आप पर लागू नहीं होता है।

vm.swappiness वास्तव में क्या बदलता है?

vm.swappiness यह RAM का प्रतिशत नहीं है और न ही यह कोई थ्रेशोल्ड है। यह वह सापेक्ष लागत (relative cost) है जिसे kernel anonymous pages को reclaim करने के लिए file pages की तुलना में निर्धारित करता है। इसका डिफ़ॉल्ट मान 60 है। इसे कम करने पर kernel page cache को हटाने को प्राथमिकता देता है। इसे बढ़ाने पर kernel anonymous memory को swap में भेजने को प्राथमिकता देता है।

यह दोनों दिशाओं में एक ट्रेड-ऑफ है। vm.swappiness = 10 पर एक डेटाबेस अपने अधिक allocations को resident रखता है, और इसके बदले में उसे उन फाइलों को फिर से पढ़ना पड़ता है जिन्हें उसने अभी-अभी cache से हटाया है। जिस सर्वर का मुख्य काम फाइलें सर्व करना है, वहां यह गलत दिशा है, क्योंकि वहां page cache ही उपयोगी काम कर रहा होता है।

इसे 0 पर सेट करने से swap बंद नहीं होता है। यह kernel को निर्देश देता है कि वह anonymous reclaim से तब तक बचे जब तक कि memory लगभग खत्म न हो जाए, जिससे OOM killer की स्थिति टलने के बजाय जल्दी आ जाती है। यदि आप swap नहीं चाहते हैं, तो swap file को हटा दें।

sysctl vm.swappiness
printf 'vm.swappiness = 10\n' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
sysctl vm.swappiness

एक साधारण sysctl -w केवल अगले reboot तक ही प्रभावी रहता है और उसके बाद अपने आप लागू होना बंद हो जाता है, इसलिए इस फाइल को /etc/sysctl.d/ के अंतर्गत लिखें। 5.8 के बाद के Kernels 0 से 200 तक के मान स्वीकार करते हैं। 100 से ऊपर का मान केवल तभी तर्कसंगत है जब swap की गति RAM के लगभग बराबर हो, और इसका अर्थ zram है।

zram: swap जो डिस्क के बजाय CPU का उपयोग करता है

zram एक compressed block device है जो RAM में रहता है। इसे swap के रूप में उपयोग करें; इससे जो page डिस्क पर जाता, वह compress होकर मेमोरी में ही रह जाता है। इसमें न तो disk I/O होता है और न ही disk quota खर्च होता है। इसकी कीमत हर page in और page out पर लगने वाला CPU time है, साथ ही वह RAM जो compressed pages को रखती है, जिसे आपके applications अब उपयोग नहीं कर सकते।

Anonymous pages के लिए आमतौर पर 2:1 और 3:1 के बीच compression ratio के आंकड़े प्रकाशित किए जाते हैं, और आपका अपना आंकड़ा zramctl द्वारा इसके DATA और COMPR columns में प्रिंट किया जाता है। सामान्य आंकड़ों के आधार पर योजना बनाने के बजाय मापें, क्योंकि कुछ workloads में ऐसा डेटा होता है जो बहुत कम compress होता है।

sudo apt install zram-tools

/etc/default/zramswap में ALGO=zstd और PERCENT=25 को सेट करें, फिर service को restart करें और परिणाम देखें।

sudo systemctl restart zramswap
zramctl
swapon --show

PERCENT कुल RAM का एक हिस्सा है, इसलिए 4 GB के box पर 25 सेट करने से compressed pages के लिए 1 GB तक आरक्षित हो जाता है। कम से शुरुआत करें और केवल तभी बढ़ाएं जब zramctl यह दिखाए कि device भर रहा है। उसी file में PRIORITY setting यह तय करती है कि kernel पहले किस swap को भरेगा: उच्च मान वाला swap पहले भरता है, और साधारण swapon के साथ जोड़ा गया disk swap file negative priority प्राप्त करता है, इसलिए zram का उपयोग पहले होता है और file overflow को संभालती है। swapon --show इन दोनों को अपने PRIO column में प्रिंट करता है। जो distributions zram-tools के बजाय systemd-zram-generator का उपयोग करते हैं, उनमें यही settings /etc/systemd/zram-generator.conf में होती हैं।

zram उन boxes के लिए उपयुक्त है जिनमें CPU headroom अधिक हो और disk space कम हो। यदि CPU allowance वह संसाधन है जिसकी आपके पास पहले से ही कमी है, तो यह गलत विकल्प है, क्योंकि compression का काम application के साथ उसी संसाधन के लिए प्रतिस्पर्धा करता है।

VPS पर आने वाली दो swap संबंधी समस्याएं

पहली समस्या डिस्क से जुड़ी है। 2 GB की swap file बनाते ही आपके प्लान की 2 GB डिस्क जगह तुरंत भर जाती है, क्योंकि यह जगह पहले से ही आवंटित (allocate) करनी पड़ती है। df -h / तुरंत उतनी मात्रा में कम हो जाता है और फाइल डिलीट करने तक वापस नहीं मिलता। छोटे प्लान पर यह एक बड़ा हिस्सा होता है, और root filesystem के पूरी तरह भर जाने से swap द्वारा ठीक की गई समस्या से कहीं अधिक नुकसान हो सकता है। यह फाइल du के आउटपुट में भी दिखाई देती है, जिसे तब याद रखना जरूरी है जब आप डिस्क स्पेस की तलाश कर रहे हों और df और du के बीच डिस्क स्पेस को लेकर मतभेद हो।

दूसरी समस्या latency की है। आपका swap I/O उस स्टोरेज पर जाता है जिसे host अपने अन्य guests के साथ साझा करता है, और आप अपने guest के अंदर से उनके load को नहीं देख सकते। आपको केवल इसका प्रभाव दिखता है: जो page-in सामान्यतः तेज होता है, वह कभी-कभी बहुत अधिक समय लेता है, और उस पर प्रतीक्षा करने वाली process तब तक रुक जाती है जब तक page प्राप्त नहीं हो जाता। यह वही तर्क है जो shared host पर CPU steal time के लिए लागू होता है, बस यहाँ यह run queue के बजाय disk queue पर लागू होता है। इसे अपने सिस्टम पर मापें, क्योंकि प्रकाशित latency के आंकड़े हमेशा किसी और के पड़ोसियों (neighbours) के बारे में होते हैं।

यह कैसे पता करें कि स्वैपिंग (swapping) आपके सिस्टम को नुकसान पहुँचा रही है?

स्वैप का उपयोग होना कोई समस्या नहीं है। समस्या स्वैप ट्रैफिक (swap traffic) है। यदि किसी सर्वर की कुछ सौ मेगाबाइट मेमोरी स्वैप में है और कोई पेजिंग गतिविधि (paging activity) नहीं हो रही है, तो इसका मतलब है कि ऐसी मेमोरी को स्वैप में भेजा गया है जिसे घंटों से किसी ने इस्तेमाल नहीं किया है, और यही अपेक्षित परिणाम है।

कुल योग (totals) के बजाय दरों (rates) पर ध्यान दें।

vmstat 1 5

si और so स्वैप में अंदर और बाहर जाने वाले kibibytes प्रति सेकंड हैं। एक स्वस्थ सर्वर पर, swpd कॉलम में चाहे जो भी लिखा हो, ये मान शून्य या उसके करीब रहते हैं। यदि so लगातार बना हुआ है और साथ ही si बढ़ रहा है, तो इसका मतलब है कि पेजों को बार-बार लिखा और तुरंत वापस लाया जा रहा है, जिसे थ्रैशिंग (thrashing) कहते हैं।

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  3 1048572  38210   4096  61440  912 1180  2210  1290 1402 2890  9  7 12 72  0

यह नमूना एक समस्याग्रस्त सर्वर को दर्शाता है, और इसका सबसे स्पष्ट संकेत स्वैप कॉलम में नहीं है। यह wa का 72 पर होना है, जिसका अर्थ है कि CPU ने अपना अधिकांश समय I/O की प्रतीक्षा में बिताया, और b का 3 होना, जिसका अर्थ है कि तीन प्रोसेस ब्लॉक हैं।

PSI (pressure stall information) इस प्रश्न का अधिक सीधा उत्तर देता है।

cat /proc/pressure/memory

some avg10=8.42 avg60=5.11 avg300=2.03 total=1284729
full avg10=3.10 avg60=1.94 avg300=0.71 total=498210

some avg10=8.42 का अर्थ है कि पिछले 10 सेकंड के दौरान, कम से कम एक टास्क मेमोरी की प्रतीक्षा में 8.42 प्रतिशत समय तक रुका रहा। full उस समय को गिनता है जब हर नॉन-आइडल टास्क रुका हुआ था, इसलिए full का लगातार बना रहना चेतावनी के बजाय वास्तविक नुकसान है। यदि यह फाइल मौजूद नहीं है, तो आपके कर्नेल में PSI डिफ़ॉल्ट रूप से अक्षम है और इसके लिए कर्नेल कमांड लाइन पर psi=1 की आवश्यकता है।

यह देखने के लिए कि कौन सी प्रोसेस स्वैप में पेज रखती हैं:

sudo awk '/^Name:/{n=$2} /^VmSwap:/ && $2+0 > 0 {printf "%10d kB  %s\n", $2, n}' /proc/[0-9]*/status | sort -rn | head

और यह पता लगाने के लिए कि क्या OOM killer ने पहले ही हस्तक्षेप किया है:

sudo journalctl -k --grep "Out of memory"

एक हिट Out of memory: Killed process 2199 (mysqld) total-vm:1275860kB, anon-rss:129252kB, file-rss:0kB, shmem-rss:0kB, UID:114 pgtables:504kB oom_score_adj:0 जैसा दिखता है, और उसी सेकंड के लिए सर्विस लॉग Main process exited, code=killed, status=9/KILL कहता है। यदि आपने बिना स्वैप वाले सर्वर पर ये लाइनें देखी हैं, तो अगला सबसे सस्ता उपाय एक स्वैप फाइल जोड़ना है।

जब swap गलत समाधान हो

Swap का उपयोग केवल अस्थायी या कम उपयोग होने वाले memory pressure के लिए किया जाता है। यदि कोई process लगातार बढ़कर crash हो रही है, तो swap उसे नहीं रोक सकता। इसके विपरीत, यह उस failure को पहचानना कठिन बना देता है, क्योंकि मशीन जल्दी fail होकर restart होने के बजाय paging में अतिरिक्त समय व्यतीत करती है।

इसके बजाय process पर सीमा (cap) लगाएँ। एक systemd service अपनी drop-in file में MemoryMax= और MemorySwapMax= स्वीकार करती है। इसी तरह आप application में बदलाव किए बिना systemd के साथ service के लिए memory और CPU को सीमित कर सकते हैं। Containers में भी यही नियंत्रण उपलब्ध होते हैं। इन्हें सेट करके ही आप एक Compose service को पूरे सर्वर के resources खत्म करने से रोक सकते हैं। ये दोनों तरीके kernel द्वारा score के आधार पर किसी भी process को kill करने के बजाय, एक स्पष्ट log के साथ process को बंद करने की सुविधा देते हैं।

यह कार्य सर्वर के नए और स्थिर होने पर करें। Swap file बनाना और memory limit सेट करना कुछ ही मिनटों का काम है, और इसे नए VPS पर शुरुआती दस मिनट के अन्य कार्यों के साथ ही पूरा किया जाना चाहिए।

FAQ

क्या swap जोड़ने से मेरा 1 GB VPS, 2 GB VPS की तरह काम करने लगेगा?

नहीं। Swap, RAM की तुलना में बहुत धीमा होता है, और kernel केवल उन्हीं pages को वहां भेजता है जिन्हें वह 'cold' मानता है। यह केवल spikes के लिए अतिरिक्त जगह देता है और ऐसी memory को रखने का स्थान है जिसे allocate तो किया गया लेकिन कभी इस्तेमाल नहीं किया गया। यदि आपका workload machine की कुल RAM से अधिक memory का सक्रिय रूप से उपयोग करता है, तो swap, out of memory (OOM) kill को लगातार होने वाली paging में बदल देता है। इससे सर्वर चालू तो रहता है, लेकिन इतना धीमा हो जाता है कि उसका उपयोग करना असंभव हो जाता है। ऐसी स्थिति में, RAM बढ़ाएं या उस process को सीमित करें जो अधिक memory ले रही है।

1 GB या 2 GB VPS को कितनी swap की आवश्यकता होती है?

2 GB दोनों के लिए पर्याप्त है, और इसके बाद RAM बढ़ने के साथ इसे बढ़ाने की आवश्यकता नहीं होती। Swap में cold anonymous pages रहते हैं, और सर्वर पर वास्तव में cold memory की मात्रा उस तरह नहीं बढ़ती जैसे कुल RAM बढ़ती है। RAM का दोगुना swap रखने का पुराना नियम hibernation से आया है, जो पूरी memory image को disk पर लिखता है, जबकि VPS कभी hibernate नहीं होता। 4 GB से अधिक swap रखने का मतलब है कि आप उस storage पर एक लंबी और धीमी विफलता (failure) को आमंत्रित कर रहे हैं जिसे आप अन्य guests के साथ साझा करते हैं।

क्या swap को रोकने के लिए vm.swappiness को 0 पर सेट करना सही तरीका है?

नहीं, और यह वह काम नहीं करता जो इसके नाम से लगता है। vm.swappiness = 0 swap को disable नहीं करता है। यह kernel को निर्देश देता है कि वह anonymous pages को तब तक reclaim न करे जब तक कि memory लगभग खत्म न हो जाए, जिससे OOM kill होने की संभावना कम होने के बजाय बढ़ जाती है। यह सारा reclaim भार page cache पर डाल देता है, जिससे file reads बार-बार disk पर जाने लगते हैं। यदि आप बिल्कुल भी swap नहीं चाहते हैं, तो sudo swapoff -a चलाएं और fstab line को हटा दें। यदि आप कम swapping चाहते हैं, तो vm.swappiness = 10 का प्रयास करें और बदलाव से पहले व बाद में vmstat में si और so columns की तुलना करें।

क्या मुझे swap file के बजाय zram का उपयोग करना चाहिए?

जब आपके पास CPU headroom हो और disk space कम हो, तब zram का उपयोग करें। जब स्थिति इसके विपरीत हो, तब swap file का उपयोग करें। zram pages को compress करके RAM में रखता है, इसलिए यह disk I/O से पूरी तरह बचता है, लेकिन हर page in और page out पर CPU की लागत बढ़ती है। साथ ही, यह जो जगह लेता है, वह वह RAM है जो अब applications को नहीं मिल पाती। कम CPU क्षमता वाले VPS पर, यह लागत उसी संसाधन पर पड़ती है जिसकी आप पहले से ही कमी महसूस कर रहे हैं। दोनों का एक साथ उपयोग करना सामान्य है: /etc/default/zramswap में PRIORITY के साथ zram को उच्च प्राथमिकता दें और overflow के लिए नीचे एक disk swap file रखें।

जब free command में memory उपलब्ध दिख रही थी, तब OOM killer क्यों चला?

free केवल एक क्षण की स्थिति बताता है, जबकि allocation किसी भी पल हो सकता है। यदि कोई process memory reclaim होने की गति से अधिक तेजी से memory का बड़ा block मांगती है, तो उसे kill कर दिया जाता है, भले ही औसत स्थिति सामान्य दिख रही हो। Kernel log को sudo journalctl -k --grep "Out of memory" के साथ पढ़ें, जो kill की गई process और उस समय उसके resident size का नाम बताता है। फिर जांचें कि क्या यह kill पूरी machine के बजाय किसी cgroup limit के कारण हुआ है, क्योंकि यदि किसी container या systemd unit में MemoryMax= सेट है, तो वह अपनी सीमा पर पहुँचते ही kill हो जाता है, भले ही host पर memory खाली हो।