منذ أن قمت بترحيل منتدى كبيري إلى Discourse هذا العام، كنت أرى أعطالًا غير متكررة مع عدم إمكانية الوصول إلى الجهاز الافتراضي السحابي عبر SSH ووجود تتبع استدعاء على وحدة التحكم الافتراضية. تحدث الأعطال كل 3 إلى 6 أسابيع تقريبًا دون أي نمط محدد. كنت في البداية أشغل Discourse على Clear Linux لأن هذا ما كنت أستخدمه للحصول على أداء أفضل قليلاً من النظام أثناء الترحيل الطويل والمكثف للمنتدى القديم إلى Discourse. لكنني بدأت أشك في أن Clear Linux قد يكون أقل استقرارًا بسبب كل تحسينات الأداء الغامضة، لذلك قمت بترحيل Discourse الخاص بي إلى Debian 12 Bookworm في وقت إصداره قبل حوالي 6 أسابيع.
للأسف، تعطل نظام Debian اليوم للمرة الأولى. إليك تسلسل الأحداث:
kernel: Voluntary context switch within RCU read-side critical section!
kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
يظهر journalctl آخر إدخال سجل في 06:40:50. لكن نظام التشغيل و Discourse استمرا في العمل. كان آخر إدخال مجرد ثرثرة قياسية من وكيل البريد المعبأ في حاويات Docker الذي أشغله على نفس الجهاز الافتراضي.
حوالي الساعة 08:30، تحققت من أن Discourse كان يعمل بشكل طبيعي.
08:46 في سجل أخطاء Discourse: Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
08:53 في سجل أخطاء Discourse: Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
09:01 في سجل أخطاء Discourse: Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
آخر منشور على Discourse كان في 09:17.
09:22 في سجل أخطاء Discourse: 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 في سجل أخطاء Discourse: Redis::TimeoutError (Connection timed out)
كانت هناك المزيد من سجلات Discourse المشابهة حتى الوقت الذي لاحظت فيه أن الموقع كان معطلاً حوالي الساعة 11:20.
عندما لم أتمكن من تسجيل الدخول عبر SSH، التقطت هذه لقطات الشاشة من عارض وحدة التحكم الافتراضية وأعدت تشغيل الجهاز الافتراضي بالقوة:
لقد كنت أدير خوادم Linux لفترة طويلة، وهذا التسلسل من الأحداث لا معنى له بالنسبة لي. تبدو سجلات Discourse مؤشرًا واضحًا على حدث نفاد الذاكرة، وتؤكد وحدة التحكم الافتراضية أن مكونًا من خادم البريد المعبأ في حاويات Docker الخاص بي على نفس الجهاز الافتراضي تم استبعاده بواسطة قاتل OOM. ولكن لا يوجد سجل لهذا الإجراء OOM في journalctl، والذي توقف عن العمل بشكل جيد قبل أن تبدأ الأنظمة الأخرى في الفشل. الحدث الأول الظاهر في 05:00:22 يذكر عملية postmaster (من PostgreSQL في حاوية تطبيق Discourse) عدة مرات، لكن قاعدة البيانات لم تتعطل تمامًا حتى بعد 09:17 عندما كان هناك منشور ناجح على Discourse.
حاليًا، بعد التشغيل طوال اليوم، يظهر النظام استخدامًا طبيعيًا للذاكرة، وهذا هو المكان الذي يستقر فيه عادةً:
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
الشيء الوحيد غير العادي قليلاً في تكويني هو أن مساحة التبديل هي في الواقع عبر Zram بدلاً من ملف تبديل أو قسم تبديل. لقد كنت أستخدم Zram لسنوات ولم أواجه مشكلة أبدًا. أيضًا، قمت بتثبيت الجهاز الافتراضي من الصفر باستخدام قرص تثبيت Debian للحصول على نظام ملفات XFS بدلاً من EXT4 القياسي الذي تستخدمه صور Debian لمزود السحابة. المضيف هو Hetzner، وبعد تثبيت Clear Linux الأولي لـ Discourse، قمت بإنشاء جهاز افتراضي مختلف للترحيل إلى Debian، لذلك من المفترض أنني على عقدة مضيف افتراضي مختلفة ولا أعتقد أنها مشكلة في الأجهزة. لذلك أتساءل عما إذا كان هذا مجرد شرط بسيط لنفاد الذاكرة، أم أنني وجدت حالة حافة في مزيج من النواة 6.1 + Zram + XFS + KVM/virtio؟ سأكون ممتنًا لأي رؤية قد تكون لديك.
يحتاج Postgres إلى المزيد من الذاكرة. يمكنك تعديل إعدادات الذاكرة هذه وربما إضافة ذاكرة وصول عشوائي، ولكن أعتقد أنك ستحتاج إلى تغيير تخصيصات ذاكرة Postgres الخاصة بك.
همم. أميل إلى الموافقة، باستثناء أخطاء النواة (kernel errors) التي بدأت أولاً. كانت الآلة الافتراضية تعمل منذ 06/يوليو دون أي خطأ في النواة (kernel oops) حتى هذا الصباح. إليك المخرجات الكاملة لتلك اللحظة. لاحظ تفاصيل page_fault_oops و handle_mm_fault و xfs_filemap_map_pages:
أنا أميل إلى التفكير في نفس الشيء، باستثناء أن هذه مشكلة متكررة إلى حد ما، ولا تبدو عشوائية تمامًا. أشك في أن Hetzner ربما لا تستخدم ذاكرة ECC، وهذا على الأرجح كيف يمكنهم تقديم كل هذا مقابل السعر. حتى خوادمهم المخصصة [يبدو] أنها لا تملك ذاكرة ECC. ولكن حتى مع ذلك، تُعتبر Hetzner بشكل عام موثوقة للغاية من حيث بنيتها التحتية.
تخميني هو هذا . حاول التخلص من كل من Zram و XFS (واحدًا تلو الآخر) وانظر ماذا يحدث. مع Zram كمشتبه به أول. يجب أن يعمل Discourse بشكل جيد مع التبديل العادي و ext4. قد تكون هذه التحسينات ممتعة ولكنها تزيد حاليًا من تعقيد تثبيتك. بمجرد أن يعمل مثيلك بشكل جيد، يمكنك إضافتها مرة أخرى واحدة تلو الأخرى ومعرفة أين تحدث الأعطال.
كقاعدة عامة، حاول الالتزام بتثبيت موصى به أولاً، ثم أضف الأشياء الذكية الخاصة بك.
شكراً على الرد. أعتقد أنني سأحاول تعطيل Zram وإضافة ملف مبادلة بحجم 2 جيجابايت. سيتطلب تغيير نظام الملفات إعادة بناء الجهاز الافتراضي بالكامل مع تثبيت جديد لـ Debian، ولا ينبغي أن يسبب XFS مشاكل على الإطلاق.
حسنًا، يبدو أن @RGJ كان على حق تمامًا بشأن XFS. شكرًا لك على توجيهي في الاتجاه الصحيح. (لقد كنت أستخدم XFS بشكل أساسي كخيار أول لي منذ حوالي عام 2002، لذلك كنت دائمًا أعتبر أنه قوي للغاية، وهو كذلك كنظام ملفات، ولكن يبدو أن هناك أخطاء متعلقة بالذاكرة.) حدثت نفس المشكلة بعد تعطيل zRAM، ثم أصدرت Debian تحديثًا لنواة 6.1 يتضمن تصحيحًا للأعطال مع XFS:
منذ أن قمت بتثبيت النواة 6.1.0-13، كان الخادم قيد التشغيل لمدة 42 يومًا دون مشاكل.
. حاول التخلص من كل من Zram و XFS (واحدًا تلو الآخر) وانظر ماذا يحدث. مع Zram كمشتبه به أول. يجب أن يعمل Discourse بشكل جيد مع التبديل العادي و ext4. قد تكون هذه التحسينات ممتعة ولكنها تزيد حاليًا من تعقيد تثبيتك. بمجرد أن يعمل مثيلك بشكل جيد، يمكنك إضافتها مرة أخرى واحدة تلو الأخرى ومعرفة أين تحدث الأعطال.