تحسين النود للحمل العالي: دليل الـ RAM والـ CPU والـ SSD

CPU: صراع الميكروثانية وعزل الكورات

الأغلبية يعتقدون إن أهم شيء للنود هو كثرة الكورات. لكن في الحقيقة، لمعالجة المعاملات والوصول للكونسنسس، الـ Single-Core Performance وتقليل التأخير وقت الـ Context Switching هو الشيء الحاسم والفاصل. لو المعالج جالس يتنقل طول الوقت بين وضعيات توفير الطاقة أو ينقل الـ Thread الخاص بالنود من كور لثاني، بتضيع عليك ميلي ثواني ثمينة وتشوف الـ TPS ينهار.

• 1. وضع المعالج في حالة التأهب القصوى

  بشكل افتراضي، نظام Linux يستخدم حاكم (governor) من نوع powersave أو schedutil، وهذول ينزلون تردد الـ CPU أول ما يقل الضغط. بالنسبة لنود عليها ضغط عالي، هذا يعتبر انتحار: لأنه على بال ما "يصحى" المعالج عشان يعالج البلوك الجديد، بتكون الشبكة طارت وطوفتك بمسافات.

  عشان كذا، نحول كل الكورات فوراً لوضع الأداء الأقصى:

  cpupower frequency-set --governor performance

  تفصيلة صغيرة وقليل اللي يعرفها: في كيرنل Linux الحديثة مع معالجات Intel، الـ governor اللي اسمه intel_pstate ممكن يسحب على الإعدادات الكلاسيكية. عشان تقفل على التردد الأقصى وتثبته خاوة (بما فيه الـ Turbo Boost)، لازم تنفذ الآتي:

  echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
  # (العلاقة عكسية: 0 يعني إن الـ Turbo Boost شغال ونشط طول الوقت)
  echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

• 2. عزل الكورات لعملية النود (CPU Pinning)

  لما الـ Scheduler حق نظام التشغيل يمشور الـ Thread الثقيل للفاليقيتور بين كورات فيزيائية مختلفة، الـ Cache L1/L2 حق المعالج يصير له إنفاليديشن طول الوقت، وهذا يسمى Cache Thrashing. إحنا بنربط النود بكورات معينة بشكل صارم، ونترك عمليات النظام تشتغل على الكور 0 والكور 1.

  نفترض إن سيرفس النود عندنا اسمها validator.service. بنحتاج نعدل الـ CPUAffinity في الـ Config حق Systemd.

  [Service]
  # نربط العملية بالكورات الفيزيائية من 2 إلى 7 (ونتجنب 0 و 1)
  CPUAffinity=2-7
  # نعطي العملية أعلى أولوية للـ scheduler (سواء Realtime/FIFO أو أعلى قيمة Nice)
  Nice=-20

RAM: ترويض الـ OOM Killer وسحر الـ HugePages

الميموري في نودز البلوكشين تطير بلمح البصر. قواعد البيانات مثل (LevelDB و RocksDB) تخزن كاش لأحجام عملاقة من الـ State Tree. لو خلصت الـ RAM، نظام Linux ما عنده يما ارحميني: بيصفي عملية النود حقتك فوراً عن طريق الـ OOM Killer.

• 1. تيونق الـ Swap وعدوانية الكاش

  انسى خرافة إن الـ SSD السريع يغنيك عن الـ Swap. الـ Swap مطلوب، لكن كإيرباق للأمان وليس كتوسعة للـ RAM. لو النود دخلت في مرحلة الـ Swapping النشط، بتطلع برة الكونسنسس مباشرة بسبب التأخير (Latency) الكارثي اللي بيصير.

  نضبط سلوك الـ Virtual Memory في ملف /etc/sysctl.conf:

  # نقلل رغبة النظام في رمي الصفحات للـ swap لأقل درجة (يشتغل بس وقت النقص الحقيقي)
  vm.swappiness=10
  # نجبر النظام يمسك الكاش حق الـ file system في الميموري بشكل أقوى
  vm.vfs_cache_pressure=50
  # نتجنب الحالات اللي النظام فجأة "يتجمد" فيها عشان يرمي الـ dirty pages على الديسك
  vm.dirty_background_ratio=3
  vm.dirty_ratio=10

• 2. تفعيل الـ HugePages لـ RocksDB/LevelDB

  الحجم الافتراضي لصفحة الميموري في Linux هو 4 كيلوبايت. لما النود تتعامل مع قاعدة بيانات بحجم 500 جيجابايت، الـ Page Table بتكبر بشكل مرعب، والمعالج بيضيع وقت طويل في الـ TLB (Translation Lookaside Buffer) misses. الانتقال لـ HugePages (حجم الصفحة 2 ميجابايت أو 1 جيجابايت) بيسرع التعامل مع الميموري بشكل دراماتيكي.

  نشيك على الدعم ونحجز مثلاً 2048 صفحة بحجم 2 ميجابايت (يعني إجمالي 4 جيجابايت) مباشرة في الـ Runtime:

  sysctl -w vm.nr_hugepages=2048

  وعشان نثبتها بشكل دائم وتتحمل مع بداية تشغيل النظام، ضيف في ملف /etc/sysctl.conf:

  vm.nr_hugepages = 2048

  بعد كذا، في ملف الكونفيج حق النود حقتك (لو كان كليينت قابل للتعديل مكتوب بـ Go/Rust ويستخدم RocksDB)، لازم تفعل فلاق use_direct_reads=true وتضبط الـ memory allocator (مثلاً تستخدم jemalloc بدل الـ glibc malloc الافتراضي، لأنه أذكى بمراحل في التعامل مع الـ memory fragmentation تحت الضغط العالي).

SSD/NVMe: استراتيجيات النجاة لمنظومة الديسك

الديسك هو عنق الزجاجة الأكبر لأي نود. عدد عمليات القراءة والكتابة في الثانية (IOPS) والـ Latency في الكتابة هم اللي يحددون إذا كانت النود حقتك بتقدر تسوي فاليقيت للبلوكات في الوقت المناسب أو لا. ديسكات الـ NVMe التجارية العادية (حتى التوب منها مثل Samsung EVO) تحترق وتنتهي صلاحيتها في نودز مثل Solana أو Ethereum خلال شهور بسيطة بسبب استهلاك الـ TBW (Terabytes Written)، وأدائها يطيح بقوة أول ما يتملى الـ SLC Cache.

تحليل مقارن لمواصفات الديسكات المناسبة للنودز

DWPD - Drive Writes Per Day (عدد مرات إعادة كتابة الديسك بالكامل يومياً خلال فترة الضمان).

1. اختيار نظام الملفات ومعاملات التهيئة (Mounting)

انسى موضوع الـ ZFS تماماً لقواعد بيانات RocksDB/LevelDB إلا لو كنت حوت وعارف تظبط الـ fine-tuning بتاعها بالملي. الـ Double caching (في الـ ARC بتاع ZFS وجوه الـ DB نفسها) مع الـ overhead بتاع الـ CoW (Copy-on-Write) هيخلي الـ IOPS بتاعك في الأرض على المدى الطويل. حبيب الملايين الـ EXT4 أو الـ XFS القديم المستقر هو خيارنا الصح.

تعديل عمل الـ mount للقرص لازم يكون بـ flags توقف الشغل الزيادة بتاع تحديث الـ metadata. إنك تقعد تكتب وقت آخر دخول (last access time) للملف مع كل "عطسة" من النود دي رفاهية مش مكانها هنا وهتضيع الأداء ع الفاضي.

السطر الصح جوه ملف الـ /etc/fstab:

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

تفصيص المعاملات "للقلوب القوية فقط":

• noatime,nodiratime — بيقفل تماماً تسجيل وقت الدخول للملفات والفولدرات. وده بيشيل من عليك جبل من عمليات الكتابة الطفيلية (parasitic writes) اللي بتبوظ الأداء في الخلفية.
• data=writeback — وضع بيخلي الـ metadata بتاعة نظام الملفات تتكتب براحتها بعد ما الداتا الفعلية تكون نزلت خلاص على القرص. تنبيه: لو الكهرباء فصلت فجأة، في ريسك إن بنية نظام الملفات (FS structure) تضرب. بس إحنا أكيد بنبني نود قوية وبنأمنها بـ UPS أو شغالين في داتا سنتر Tier III، صح ولا لأ؟ عشان السرعة القصوى إحنا بنقبل الـ trade-off ده وإحنا مغمضين.
• barrier=0 — بيعطل حواجز الكتابة (write barriers). وده بيمنع نظام الملفات إنه يجبر الـ disk cache على التفريغ (flush) في أوقات معينة. على أقراص الـ enterprise اللي فيها حماية ضد فصل الكهرباء (Power Loss Protection, PLP)، الـ flag ده آمن تماماً وبيدي طفرة خرافية في سرعة الكتابة العشوائية (random write).

Network Stack: تظبيط الكيرنل عشان يستحمل ملايين الحزم (Packets)

النود في الأساس عبارة عن شبكة ربط مركزية (network hub). بتفضل فاتحة طول الوقت مئات وآلاف الاتصالات المتزامنة (TCP/UDP) مع الـ peers التانيين. نظام الـ Linux العادي متظبط عشان سيرفر مكتب أو موقع ويب على قده، عشان كده أول ما بيحصل هجوم أو ضغط ترانزكشنز مفاجئ (وقت الـ hype)، الـ network buffers بتتملي وتفيض، والنود بتبدأ تعمل drop للحزم وتلاقي نفسك بره الـ consensus والسينك طار.

هنعمل تعديلات حاسمة على معاملات الشبكة في الكيرنل عن طريق ملف /etc/sysctl.conf:

# الحد الأقصى للملفات المفتوحة والـ descriptors (عشان نتفادى مشكلة "Too many open files")
fs.file-max = 2097152
# زيادة الحد الأقصى لطابور حزم الشبكة الواردة
net.core.netdev_max_backlog = 100000
# الحد الأقصى للـ sockets المستنية اتصال (حماية من الـ backlog overflow)
net.core.somaxconn = 65535
# تظبيط الـ buffers للـ TCP (الحجم الأدنى، والافتراضي، والأقصى بالـ bytes)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# السماح بإعادة استخدام الـ sockets اللي في حالة TIME_WAIT
net.ipv4.tcp_tw_reuse = 1
# إلغاء الـ TCP Slow Start بعد فترة الخمول — النود لازم ترد فوراً وفي كسر من الثانية طول الوقت
net.ipv4.tcp_slow_start_after_idle = 0

بعد ما تعدل الملف، لازم تطبق التغييرات دي لايف فوراً (on the fly):

sysctl -p

ما تنساش ترفع الـ limits لليوزر اللي مشغل بروسيس النود (مثلاً: validator). جوه ملف /etc/security/limits.conf بنكتب:

validator soft nofile 1048576
validator hard nofile 1048576

ثغرة هندسية (Alpha Hack): رمي الـ WAL على الـ RAM-Disk

إستراتيجية مشهورة بس بين الحيتان، وفعالة بشكل مش طبيعي للـ setups المخصصة للـ high-throughput. أي قاعدة بيانات معاملات (بما فيها RocksDB) بتكتب العملية الأول في الـ WAL (Write-Ahead Log) على القرص، وبعدين تأكد الترانزكشن. دي عملية تزامنية (synchronous)، وطول ما القرص ما ردش إن الـ WAL اتكتب، البروسيس بيفضل واقف مستني.

لو عندك RAM بزيادة ومفيش مشكلة في المساحة، تقدر تكريت RAM-disk صغير (tmpfs) مخصص بس للفولدر بتاع wal للنود، وتسيب قاعدة البيانات الكبيرة والتقيلة (SST files) شغالة على الـ Enterprise NVMe بتاعك.

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

• الريسك: أول ما السيرفر يفصل أو يعمل ريستارت، كل الداتا اللي على الـ RAM-disk هتطير في ثانية.
• الحل: لحسن الحظ، معظم الـ blockchain clients الحديثة ذكية كفاية إنها تعمل restore للـ state وقت الريستارت عن طريق الـ snapshots أو تعمل سينك من الـ peers، بشرط إن بنية الـ SST files على القرص الأساسي تكون سليمة والـ WAL مقفول صح أو تم التغاضي عنه. قبل ما تطبق الإستراتيجية دي في الـ production، لازم تقرأ الـ documentation بتاعة الـ client اللي شغال بيه وتشوف هو بيتعامل ازاي مع الـ WAL logs!

مراقبة الـ Bottlenecks (اختناقات الأداء) في الوقت الفعلي

حتى أقوى عملية تيونينج (Tuning) مالها أي قيمة بدون مراقبة مستمرة للمقاييس (Metrics). لما النود (Node) يبدأ يتأخر عن الشبكة (يـ لاق)، الأدوات التقليدية مثل top أو htop غالباً بتعرض لك استهلاك الـ CPU بنسبة %100، بس هالمؤشر يعتبر فخ تضليلي. المعالج ممكن يكون ببساطة في حالة خمول (Idle) وقاعد ينتظر وصول البيانات من الديسك أو الشبكة.

المؤشر الأساسي اللي لازم أي مهندس بنية تحتية (Infra Engineer) يخليه عينه عليه وما يغفل عنه أبداً هو io_wait ومقاييس الـ PSI (Pressure Stall Information).

كيف تقرأ مؤشرات أداة iostat

شغّل الأمر iostat -xmd 1 وقت الذروة (Peak Load) على النود، وركّز على معاملين حاسمين: %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

مؤشر الانهيار الحرج (Critical Degradation): إذا قارب الـ %util على %100، فهذا يعني إن الديسك عندك قاعد يلفظ أنفاسه الأخيرة من الضغط المستمر. بس الأخطر والأهم هو معامل الـ await (متوسط وقت معالجة الطلب بالملي ثانية). بالنسبة لديسكات الـ Enterprise NVMe في شبكات البلوكشين، قيمة الـ await المفروض ما تتجاوز 0.5 إلى 1.0 ملي ثانية بأي حال من الأحوال. إذا بدت تظهر لك أرقام في حدود 5.0 إلى 10.0 ملي ثانية، النود حرفياً مش ملاحق في كتابة البلوكات الجديدة على الديسك، و النتيجة الحتمية إنه بيفقد التزامن (Desync) وبيطير برة قائمة الـ Active Validators.

Checklist: مصفوفة التحسين النهائية للـ Production

عشان نسهل عليك الشغل، جمعنا كل نقاط التحسين الحرجة في جدول عمل موحد، تقدر تستخدمه لعمل تفتيش (Audit) لأي سيرفر (Bare-metal) قبل ما تشغل النود.

الخلاصة: بنية تحتية خالية من نقاط الضعف

تحسين أداء نود ذو إنتاجية عالية (High-Throughput Node) هو دايماً عبارة عن موازنة (Trade-off) بين السرعة الخارقة وأمان حفظ البيانات. لما تقفل الـ Write Barriers لنظام الملفات أو تنقل اللوغز (Logs) للـ RAM-disk، إنت كذا جالس تتحمل ريسك فقدان آخر ثواني من الترانزاكشنز في حال صار التماس أو انقطاع مفاجئ للكهرباء عن السيرفر. لكن في بنية الـ Web3 الحديثة، وبما إن سرعة الكونسنسس (Consensus) صارت تنحسب بالمئات من الملي ثانية، التعديلات الهجومية هذي هي الطريقة الوحيدة عشان تضمن مكانك في التوب ضمن الـ Validator Set وتضمن الـ Uptime بدون ما تطوفك أي بلوكات. طبق هالإعدادات خطوة بخطوة، واختبرها دايماً على الـ Testnet أولاً، وعينك ما تغيب عن داشبورد الـ I/O عندك.