منذ أن قمت بترحيل منتدى كبيري إلى 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 الخاصة بك.
Hmm. I would tend to agree, except for the kernel errors that started first. The VM had been running since 06/Jul without a single kernel oops until this morning. Here’s the full output of that instant. Notice the page_fault_oops and handle_mm_fault and xfs_filemap_map_pages stuff:
I kind of think the same thing, except that this is somewhat of a repeat issue, feels slightly not random enough. I suspect that Hetzner probably doesn’t use ECC RAM, that’s probably how they can offer so much for the price. Even their dedicated servers apparently don’t/didn’t have ECC. But even so Hetzner is generally regarded as quite reliable in terms of their infrastructure.
تخميني هو هذا . حاول التخلص من كل من 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. قد تكون هذه التحسينات ممتعة ولكنها تزيد حاليًا من تعقيد تثبيتك. بمجرد أن يعمل مثيلك بشكل جيد، يمكنك إضافتها مرة أخرى واحدة تلو الأخرى ومعرفة أين تحدث الأعطال.