High Load Node Optimization: RAM, CPU और SSD गाइड

CPU: माइक्रोसेकंड्स की जंग और कोर आइसोलेशन

ज्यादातर लोगों को लगता है कि नोड के लिए बस ढेर सारे कores होने चाहिए। असल में, ट्रांजैक्शन प्रोसेसिंग और कंसेंसस के लिए सिंगल-कोर परफॉर्मेंस (Single-Core Performance) और कॉन्टेक्स्ट स्विचिंग के दौरान होने वाले डिले को कम करना सबसे ज्यादा क्रिटिकल है। अगर आपका प्रोसेसर लगातार पावर-सेविंग मोड्स के बीच जंप कर रहा है या नोड के थ्रेड को एक कोर से दूसरे कोर पर पटक रहा है, तो आप कीमती मिलीसेकंड्स गंवा देंगे और आपका TPS धड़ाम से नीचे गिर जाएगा।

• 1. प्रोसेसर को फुल ऑन एक्शन मोड में डालना

  डिफॉल्ट रूप से, लिनक्स powersave या schedutil गवर्नर का यूज़ करता है, जो लोड कम होते ही CPU की फ्रीक्वेंसी को घटा देते हैं। हाई-लोड वाले नोड के लिए यह साक्षात मौत है: जब तक प्रोसेसर नए ब्लॉक को प्रोसेस करने के लिए 'जागता' है, तब तक नेटवर्क बहुत आगे निकल चुका होता है।

  बिना टाइम वेस्ट किए सारे कores को तुरंत मैक्सिमम परफॉर्मेंस मोड पर लॉक करें:

  cpupower frequency-set --governor performance

  एक छुपा हुआ पेंच जो कम ही लोग जानते हैं: इंटेल प्रोसेसर्स वाले मॉडर्न लिनक्स कर्नल्स पर intel_pstate गवर्नर कभी-कभी क्लासिक सेटिंग्स को भाव नहीं देता। मैक्सिमम फ्रीक्वेंसी (टर्बो बूस्ट के साथ) को पूरी तरह से लॉक करने के लिए, आपको यह कमांड चलानी होगी:

  echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
  # (उल्टा लॉजिक: 0 का मतलब है कि टर्बो बूस्ट चालू है और लगातार एक्टिव रहेगा)
  echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

• 2. नोड प्रोसेस के लिए कores को रिज़र्व करना (CPU Pinning)

  जब ओएस का शेड्यूलर वैलिडेटर के भारी-भरकम थ्रेड को अलग-अलग फिजिकल कores पर घुमाता रहता है, तो CPU का L1/L2 कैशे बार-बार डिलीट (invalidate) होता रहता है। इसे Cache Thrashing कहते हैं। हम नोड को बिल्कुल फिक्स कores अलॉट कर देंगे, और सिस्टम प्रोसेस के लिए कोर 0 और 1 को छोड़ देंगे।

  मान लेते हैं कि हमारे नोड की सर्विस का नाम validator.service है। हमें Systemd कॉन्फ़िग में CPUAffinity सेट करना होगा।

  [Service]
  # प्रोसेस को सीधे फिजिकल कोर 2 से 7 पर बांधें (0 और 1 को बाईपास करते हुए)
  CPUAffinity=2-7
  # शेड्यूलर की प्रायोरिटी को सबसे ऊपर सेट करें (Realtime/FIFO या सीधे मैक्सिमम Nice)
  Nice=-20

RAM: OOM Killer को काबू करना और HugePages का जादू

ब्लॉकचेन नोड्स में मेमोरी पानी की तरह बहती है। डेटाबेस (LevelDB, RocksDB) स्टेट ट्री (State Tree) के भारी-भरकम डेटा को कैशे में रखते हैं। अगर RAM फुल हो गई, तो लिनक्स बिना कुछ सोचे-समझे OOM Killer के ज़रिए आपके नोड की प्रोसेस को ऑन द स्पॉट उड़ा देगा।

• 1. स्वैप (Swap) ट्यूनिंग और अग्रेसिव कैशिंग

  इस मिथक को भूल जाइए कि फास्ट SSD होने पर स्वैप की ज़रूरत नहीं होती। स्वैप चाहिए, लेकिन एक सेफ्टी नेट (airbag) की तरह, न कि RAM बढ़ाने के लिए। अगर नोड एक्टिवली स्वैपिंग करने लगा, तो भयंकर डिले की वजह से वह कंसेंसस से सीधे बाहर (kick out) हो जाएगा।

  /etc/sysctl.conf में वर्चुअल मेमोरी सबसिस्टम का बिहेवियर सेट करें:

  # पेजेस को स्वैप में भेजने की आदत को ना के बराबर करें (केवल असली मेमोरी क्राइसिस के समय ही एक्टिव हो)
  vm.swappiness=10
  # सिस्टम को मेमोरी में फाइल सिस्टम कैशे को ज्यादा आक्रामक तरीके से होल्ड करने के लिए मजबूर करें
  vm.vfs_cache_pressure=50
  # उस सिचुएशन से बचें जहां सिस्टम डर्टी पेजेस को डिस्क पर डंप करने के लिए अचानक से 'फ्रीज' हो जाता है
  vm.dirty_background_ratio=3
  vm.dirty_ratio=10

• 2. RocksDB/LevelDB के लिए HugePages ऑन करना

  डिफॉल्ट रूप से लिनक्स में मेमोरी पेज का साइज 4 KB होता है। जब नोड 500 GB के डेटाबेस के साथ काम करता है, तो पेज टेबल (Page Table) का साइज बहुत ज्यादा फैल जाता है, और CPU का काफी टाइम TLB (Translation Lookaside Buffer) मिसेस में बर्बाद होता है। HugePages (2 MB या 1 GB पेज साइज) पर शिफ्ट होने से मेमोरी एक्सेस की स्पीड सीधे नेक्स्ट लेवल पर चली जाती है।

  सपोर्ट चेक करें और सीधे रनटाइम पर, मान लीजिए 2 MB वाले 2048 पेजेस (टोटल 4 GB) अलॉट करें:

  sysctl -w vm.nr_hugepages=2048

  इसे परमानेंट करने और सिस्टम बूट के समय ही अलॉट करने के लिए /etc/sysctl.conf में जोड़ें:

  vm.nr_hugepages = 2048

  इसके बाद, अपने नोड के कॉन्फ़िगरेशन फ़ाइल में (अगर आप RocksDB का यूज़ करने वाला कोई कस्टमाइज़्ड Go/Rust क्लाइंट चला रहे हैं) use_direct_reads=true फ्लैग को ऑन करना होगा और मेमोरी एलोकेटर को सेट करना होगा (उदाहरण के लिए, स्टैंडर्ड glibc malloc की जगह jemalloc का यूज़ करें, क्योंकि यह हैवी लोड के दौरान मेमोरी फ्रैगमेंटेशन को बहुत बेहतर तरीके से हैंडल करता है)।

SSD/NVMe: डिस्क सबसिस्टम को जिंदा रखने की स्ट्रेटेजी

डिस्क किसी भी नोड का सबसे बड़ा बॉटलनैक (bottleneck) होती है। इनपुट-आउटपुट ऑपरेशंस की संख्या (IOPS) और राइटिंग लेटेंसी (Latency) ही यह तय करती है कि आपका नोड टाइम पर ब्लॉक्स को वैलिडेट कर पाएगा या नहीं। नॉर्मल कंज्यूमर NVMe डिस्क्स (यहाँ तक कि टॉप-एंड Samsung EVO भी) Solana या Ethereum जैसे नोड्स पर TBW (Terabytes Written) खत्म होने के कारण कुछ ही महीनों में दम तोड़ देती हैं और कैशे फुल होते ही उनकी स्पीड एकदम बैठ जाती है।

नोड्स के लिए डिस्क्स की स्पेसिफिकेशन्स का कम्पेरिजन एनालिसिस

DWPD - Drive Writes Per Day (वॉरंटी पीरियड के दौरान हर दिन डिस्क को कितनी बार पूरी तरह से री-राइट किया जा सकता है)।

1. फाइल सिस्टम का चुनाव और माउंट पैरामीटर्स (Mount Options)

अगर आपको ZFS की बारीक सेटिंग करना नहीं आता, तो RocksDB/LevelDB डेटाबेस के लिए इसे भूल जाना ही बेहतर है। डबल कैशिंग (ZFS के ARC में और खुद DB में) और CoW (Copy-on-Write) का फालतू लोड लंबे समय में आपके IOPS की पूरी तरह से बैंड बजा देगा। पुराना और भरोसेमंद EXT4 या XFS ही हमारी असली पसंद है।

डिस्क को ऐसे फ्लैग्स के साथ माउंट करना जरूरी है जो मेटाडेटा अपडेट करने का फालतू काम बंद कर दें। नोड के हर छोटे-से एक्शन पर फाइल के आखिरी एक्सेस टाइम (last access time) को बार-बार लिखना एक ऐसा लक्ज़री शौक है जो हम बिल्कुल अफोर्ड नहीं कर सकते।

/etc/fstab में सही कॉन्फ़िगरेशन लाइन:

UUID=your-drive-uuid /mnt/node-data ext4 noatime,nodiratime,data=writeback,barrier=0,nobh,alloc_policy=contiguous 0 2

पैरामीटर्स का पूरा ब्रेकडाउन, जो कमजोर दिल वालों के लिए नहीं है:

• noatime,nodiratime — यह फाइलों और फोल्डर्स के एक्सेस टाइम को लिखना पूरी तरह से बंद कर देता है। इससे बैकग्राउंड में होने वाले ढेर सारे फालतू राइट ऑपरेशन्स (parasitic writes) खत्म हो जाते हैं।
• data=writeback — इस मोड में फाइल सिस्टम का मेटाडेटा तब लॉग हो सकता है जब एक्चुअल डेटा पहले ही डिस्क पर जा चुका हो। ध्यान दें: अचानक बिजली गुल होने पर FS स्ट्रक्चर करप्ट होने का रिस्क रहता है। लेकिन हम एक तगड़ा और फॉल्ट-टोलरेंट नोड सेटअप बना रहे हैं जो UPS पर है या फिर किसी Tier III डेटा सेंटर में होस्टेड है, सही कहा ना? तो स्पीड के लिए हम यह रिस्क आराम से ले सकते हैं।
• barrier=0 — यह राइट बैरियर्स को डिसेबल कर देता है। यह फाइल सिस्टम को कुछ खास इंटरवल्स पर डिस्क कैश को जबरन फ्लश करने से रोकता है। पावर लॉस प्रोटेक्शन (PLP) वाले एंटरप्राइज-ग्रेड डिस्क पर यह फ्लैग पूरी तरह से सेफ है और रैंडम राइट्स (random writes) में जबरदस्त स्पीड बूस्ट देता है।

नेटवर्क स्टैक (Network Stack): लाखों पैकेट्स के लिए कर्नल ट्यूनिंग

एक नोड असल में एक नेटवर्क हब की तरह काम करता है। यह लगातार पीयर्स (peers) के साथ सैकड़ों और हजारों चालू TCP/UDP कनेक्शंस बनाए रखता है। डिफ़ॉल्ट लिनक्स (Linux) किसी नॉर्मल ऑफिस सर्वर या एवरेज वेबसाइट के हिसाब से सेट होता है। इसलिए, जब अचानक ट्रांजैक्शन्स का भारी लोड (hype) आता है, तो नेटवर्क बफ़र्स तुरंत ओवरफ्लो हो जाते हैं, नोड पैकेट्स ड्रॉप करने लगता है और आप कंसेंसस (consensus) से बाहर हो जाते हैं।

तो चलिए, /etc/sysctl.conf के जरिए कर्नल के नेटवर्क पैरामीटर्स में कुछ एग्रेसिव बदलाव करते हैं:

# मैक्सिमम ओपन फाइल्स और डिस्क्रिप्टर्स (ताकि "Too many open files" का अड़ंगा ना फंसे)
fs.file-max = 2097152
# आने वाले नेटवर्क पैकेट्स की मैक्सिमम क्यू साइज (queue size) को बढ़ाएं
net.core.netdev_max_backlog = 100000
# कनेक्शन का इंतजार कर रहे सॉकेट्स की मैक्सिमम संख्या (बैकलॉग ओवरफ्लो से बचाव के लिए)
net.core.somaxconn = 65535
# TCP बफ़र्स की ट्यूनिंग (बाइट्स में मिनिमम, डिफ़ॉल्ट और मैक्सिमम साइज)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TIME_WAIT स्टेट में मौजूद सॉकेट्स को दोबारा इस्तेमाल करने की परमिशन दें
net.ipv4.tcp_tw_reuse = 1
# आइडल (idle) रहने के बाद TCP स्लो स्टार्ट को बंद करें — नोड को हमेशा हर मिलीसेकंड में तुरंत रिस्पॉन्स देना चाहिए
net.ipv4.tcp_slow_start_after_idle = 0

फाइल को एडिट करने के बाद, इन बदलावों को तुरंत लाइव अप्लाई करना न भूलें:

sysctl -p

जिस यूजर के नाम पर नोड प्रोसेस चल रहा है (जैसे: validator), उसके लिए लिमिट्स (limits) बढ़ाना मत भूलना। /etc/security/limits.conf फाइल में यह एंट्री डालें:

validator soft nofile 1048576
validator hard nofile 1048576

आर्किटेक्चरल हैक (Alpha): WAL को RAM-डिस्क पर ले जाना

कस्टम और हाई-थ्रूपुट सेटअप के लिए यह एक सीक्रेट लेकिन बेहद असरदार स्ट्रेटजी है। कोई भी ट्रांजैक्शनल डेटाबेस (RocksDB समेत) ट्रांजैक्शन को कन्फर्म करने से पहले ऑपरेशन को डिस्क पर WAL (Write-Ahead Log) में लिखता है। यह एक सिंक्रोनस (synchronous) ऑपरेशन है। जब तक डिस्क जवाब नहीं देती कि WAL लिख गया है, तब तक प्रोसेस रुका रहता है।

अगर आपके पास पर्याप्त रैम (RAM) बची है, तो आप सिर्फ अपने नोड की wal डायरेक्टरी के लिए एक छोटा RAM-डिस्क (tmpfs) बना सकते हैं, जबकि भारी-भरकम डेटाबेस स्टेट (SST फाइल्स) को अपने एंटरप्राइज NVMe पर ही रहने दे सकते हैं।

mkdir -p /mnt/node-data/wal
mount -t tmpfs -o size=8G tmpfs /mnt/node-data/wal

• रिस्क: सर्वर बंद या रीस्टार्ट होने पर RAM-डिस्क का सारा डेटा पलक झपकते ही गायब हो जाएगा।
• सॉल्यूशन: आजकल के ज्यादातर मॉडर्न ब्लॉकचेन क्लाइंट्स इतने समझदार हैं कि रीस्टार्ट होने पर स्नैपशॉट्स या पीयर्स से सिंक करके अपनी स्टेट को दोबारा रिकवर कर लेते हैं, बशर्ते मेन डिस्क पर SST फाइल्स का स्ट्रक्चर सही सलामत हो और WAL को सलीके से क्लोज या डिस्कार्ड किया गया हो। इस स्ट्रेटजी को लाइव करने से पहले, अपने स्पेसिफिक ब्लॉकचेन क्लाइंट का डॉक्यूमेंटेशन जरूर चेक कर लें कि वह WAL लॉग्स को कैसे हैंडल करता है!

Bottlenecks की रियल-टाइम मॉनिटरिंग

अगर आप मैट्रिक्स को लगातार ट्रैक नहीं कर रहे हैं, तो बड़े से बड़ा कस्टमाइज्ड ट्यूनिंग भी पूरी तरह बेकार है। जब आपका नोड नेटवर्क से पीछे छूटने (lag करने) लगता है, तो top या htop जैसे बेसिक टूल्स अक्सर 100% CPU यूटिलाइजेशन दिखाते हैं, जो कि एक गलत सिग्नल है। असल में, प्रोसेसर वहां पूरी तरह खाली (idle) बैठा हो सकता है और बस डिस्क या नेटवर्क से डेटा आने का इंतजार कर रहा होता है।

मेन इंडिकेटर, जिसे हर इंफ्रास्ट्रक्चर इंजीनियर को सबसे ज्यादा तवज्जो देनी चाहिए, वो है io_wait और PSI (Pressure Stall Information) मैट्रिक्स।

iostat टूल के पैरामीटर्स को कैसे डिकोड करें

जब नोड पर पीक लोड हो, तो iostat -xmd 1 कमांड चलाएं और दो सबसे क्रिटिकल पैरामीटर्स पर नजर रखें: %util और await।

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1           0.00     4.00 4500.00 1200.00   280.00    75.00   124.50     1.20    0.21    0.15    0.42   0.15  85.50

परफॉर्मेंस डाउन होने का डेंजर साइन: अगर %util 100% के करीब पहुंच रहा है, तो इसका मतलब है कि आपका डिस्क लगातार काम करके पूरी तरह चोक हो चुका है। लेकिन इससे भी कहीं ज्यादा इम्पॉर्टेंट पैरामीटर await है (यानी मिलीसेकंड में I/O रिक्वेस्ट का एवरेज प्रोसेसिंग टाइम)। ब्लॉकचेन नेटवर्क्स में एंटरप्राइज-ग्रेड NVMe डिस्क के लिए await की वैल्यू 0.5–1.0 ms से ऊपर बिल्कुल नहीं जानी चाहिए। अगर आपको वहां 5.0–10.0 ms के आसपास के नंबर्स दिख रहे हैं, तो नोड नए ब्लॉक्स को उतनी तेजी से राइट (write) नहीं कर पा रहा है, और वो पक्का डी-सिंक (desync) होकर एक्टिव वैलिडेटर सेट से बाहर हो जाएगा।

चेकलिस्ट: प्रोडक्शन के लिए अल्टीमेट ऑप्टिमाइजेशन मैट्रिक्स

आसानी के लिए, हमने सभी क्रिटिकल ऑप्टिमाइजेशन पॉइंट्स को एक सिंगल वर्किंग टेबल में डाल दिया है। नोड को लाइव करने से पहले आप किसी भी बेयर-मेटल सर्वर के ऑडिट के लिए इसका इस्तेमाल कर सकते हैं।

बॉटम लाइन: एक सॉलिड और फुलप्रूफ आर्किटेक्चर

एक हाई-थ्रूपुट नोड को ऑप्टिमाइज़ करना हमेशा एक्सट्रीम स्पीड और डेटा सेफ्टी के बीच का एक सीधा ट्रेड-ऑफ (समझौता) है। फाइल सिस्टम के राइट बैरियर्स को डिसेबल करके या लॉग्स को RAM डिस्क पर ले जाकर, आप अचानक पावर कट होने की स्थिति में पिछले कुछ सेकंड के ट्रांजैक्शन डेटा के लॉस का रिस्क खुद अपने ऊपर लेते हैं। हालांकि, आज के मॉडर्न वेब3 आर्किटेक्चर में, जहां कंसेंसस की स्पीड चंद सौ मिलीसेकंड्स में नापी जाती है, टॉप वैलिडेटर्स की लिस्ट में बने रहने और बिना ब्लॉक मिस किए स्टेबल अपटाइम बनाए रखने का यही एकमात्र तरीका है। इन सेटिंग्स को धीरे-धीरे स्टेप-बाय-स्टेप अप्लाई करें, इन्हें हमेशा पहले टेस्टनेट एनवायरनमेंट में टेस्ट करें और अपने I/O मॉनिटरिंग डैशबोर्ड्स पर लगातार नजर रखें।