«انخفضت الذاكرة القصوى للعقدة بنسبة 23%» في XRPL 3.3.0 لا تعني متوسط الشبكة بالكامل. قارن مهندسو RippleX بين عقدتين على الشبكة الرئيسية: من 3.2.0 بلا trim إلى 3.3.0 مع trim، انخفضت قيمة RSS من 20.1 إلى 17.4 GiB (−13%)، ومن 19.4 إلى 15.0 GiB (−23%)؛ واستُخدم متوسط الفترة المستقرة بعد اليوم الخامس من التشغيل.
في Linux/glibc، بعد تنظيف ذاكرة التخزين المؤقت، يُستدعى malloc_trim(0) لإعادة صفحات الذاكرة الخاملة إلى النظام؛ أما المنصات الأخرى فلا تفعل شيئًا. هذا تحسين لـRSS، وليس تسريعًا للإجماع. العينة تقتصر على عقدتين مختلفتي الإعدادات، ولا يمكن تعميم النتائج. والأجدر بمشغلي العقد متابعة منحنيات العقدة نفسها عبر الزمن. هل تنظر إلى القيمة المطلقة بوحدة GiB، أم إلى التغير قبل الترقية وبعدها؟
المصادر: ملاحظات الإصدار https://xrpl.org/blog/2026/xrpld-3.3.0 |قياسات RippleX https://dev.to/ripplexdev/memory-in-an-xrpl-node-explicit-heap-trimming-after-cache-sweeps-4bi9 |إعلان XRPLF https://x.com/XRPLF/status/2118433306962505833
إفصاح: أشارك في فعالية محتوى Write to Earn على Binance Square؛ الأهلية والمكافآت وفقًا للمنصة، ولا ضمان لها. ليس نصيحة استثمارية.
$XRP #XRPL