مرحبًا!
لديّ Discourse مُثبتًا على Docker، ويبدو أنه لا يستخدم مساحة التبديل (swap) أبدًا حتى عندما تكون الذاكرة العشوائية (RAM) مستنفَدة، مما يتسبب في انهياره أو ظهور رسالة خطأ fatal error: out of memory allocating heap arena map عند محاولة إعادة البناء، ما لم أُعيد تشغيل النظام كل بضع ساعات، فلا يبدو أن الأمر يعمل.
هل يعرف أحد كيفية حل هذه المشكلة؟
شكرًا،
كيان
بافتراض أنك تعمل على نظام لينكس، ماذا يُظهر الأمر free -h؟ (يفضل أن يكون ذلك مباشرة بعد إعادة التشغيل، وكذلك قبل حدوث الخطأ بوقت قصير.)
ربما تم ضبط swappiness على 0؟
cat /proc/sys/vm/swappiness
مرحبًا!
كان الرقم 40، وقد قمت بتعيينه الآن إلى 60.
يقوم النظام دائمًا بتخزين أجزاء كبيرة من ذاكرة الوصول العشوائي (RAM) مؤقتًا، ولا يتم استخدام مساحة التبديل (swap) أبدًا حتى عندما تكون استهلاك ذاكرة الوصول العشوائي مرتفعًا.
أعتقد أن الجزأين الرئيسيين من المخرجات اللذين يجب التركيز عليهما هما 5.5 جيجابايت من الذاكرة المتاحة و 0 بايت من مساحة التبديل المستخدمة. أو ربما الـ 9 جيجابايت من مساحة التبديل الحرة. مجموع 5.5 جيجابايت + 9 جيجابايت يخبرك بمدى هامش الأمان المتاح لديك. كمية الذاكرة المستخدمة للمخازن المؤقتة (buffers) والذاكرة المؤقتة (cache) ديناميكية ولا ينبغي أن تسبب نقصًا في الموارد أبدًا.
أعتقد أنه مع وقت فشل لا يتجاوز بضع ساعات، سأقوم بتشغيل أمر vmstat 5 والتقاط مخرجاته بطريقة تتيح لك رؤية اللحظات الأخيرة. كنتُ أستخدم في السابق مهمة مجدولة (cron job) لتشغيل vmstat 5 5 داخل ملف سجل كل 10 دقائق.
من الممكن أن يؤدي برنامج غير مستقر إلى استهلاك جميع الموارد المتاحة بسرعة كبيرة. وفي هذه الحالة، قد يكون سجل أمر ps uax كل بضع دقائق - للحصول على بعض لقطات الشاشة في اللحظات الحاسمة - مفيدًا للغاية.
من الممكن أيضًا أن تكون هناك حدود أخرى سارية. يُفترض أن هذا تثبيت قياسي على نظام تشغيل قياسي، دون تشغيل أي شيء آخر وبدون أي تكوين خاص؟
مرحبًا!
كيف يمكنني كتابة مخرجات أمر vmstat 5 إلى ملف سجل كل 10 دقائق؟ وكيف يمكنني جعل أمر ps uax يكتب إلى ملف سجل كل بضع دقائق؟
نعم، هذه تثبيت قياسي لنظام Ubuntu Server 18.04. يحتوي فقط على برامج مثل Apache وDocker وما إلى ذلك.
تذكرت للتو أيضًا أن لدي Varnish Cache مثبتًا، وهو ما يفسر الذاكرة العشوائية (RAM) التي يتم تخزينها مؤقتًا. لكنني لا أفهم سبب عدم استخدام Discourse لذاكرة التبديل (swap) أيضًا. لقد قمت بتعيين تخصيصها قبل بضعة أيام باستخدام أمر docker لتحديد حد الذاكرة المؤقتة، لكنه لم يفعل شيئًا.
إليك سطرًا واحدًا بسيطًا وفعالًا (رغم أن استخدام cron طريقة أفضل)
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
سيتم تشغيله إلى الأبد: لإيقافه، اكتب touch /tmp/stop
ستظهر السجلات في /var/log/monitor.log - استخدم tail -99 لرؤية آخر السجلات، أو less للتنقل فيها. ستحتاج إلى العثور على الأقسام في السجل التي تظهر تطور المشكلة.
يبدو أنك تطرح السؤال الخطأ هنا. فالنواة (kernel) في لينكس هي المسؤولة عن إدارة الذاكرة الافتراضية، بما في ذلك استخدام المخازن المؤقتة (buffers) والذاكرة التبديلية (swap). إذا أبلغ الأمر free عن وجود ذاكرة تبديلية مُهيأة، فهذا هو الوضع الطبيعي ولا يتعين عليك فعل أي شيء.
سؤالك الحقيقي هو: لماذا لا يعمل Discourse بشكل جيد؟ ولماذا يحتاج إلى إعادة تشغيل؟ ولماذا أرى رسالة fatal error؟
أنصحك بشدة بإعادة تسمية هذا الموضوع إلى:
Why “fatal error: out of memory allocating heap arena map”?
لكنني أيضًا قلق لأنك تبدو وكأن لديك عدة ملاحظات منفصلة:
وليس واضحًا لي بالضبط كيف تتفاعل هذه الملاحظات.
سيكون من الجيد سماع إجاباتك على هذه الأسئلة!
هًم، ماذا فعلت بالضبط؟ ماذا يُظهر الأمر التالي:
docker stats --no-stream --no-trunc
في عمود MEM USAGE / LIMIT و MEM %؟
(في حالتي، قيمة LIMIT أقل قليلاً من الذاكرة الفيزيائية للآلة. ربما يعني هذا أن أي عملية تعمل داخل الحاوية غير مرجح أن تسبب استخدام الذاكرة المؤقتة (swap)، وقد تفشل عملية ما في تخصيص ذاكرة حتى لو كان استخدام الذاكرة المؤقتة قليلاً أو معدوماً.)
مرحبًا!
أعتقد أن Discourse تعطل، لأنه عند الدخول إلى النطاق، أحصل على خطأ Nginx 502 Bad Gateway. ومع ذلك، فإن حاوية Docker لا تزال تعمل.
نعم، باستثناء الحالات النادرة.
أعيد بنائها لأن ذلك غالبًا ما يصلح خطأ 502 Bad Gateway لفترة من الوقت.
كما أعيد تشغيل الخادم لأرى ما إذا كان ذلك سيصلح الخطأ، وغالبًا ما ينجح، ولكن من المرجح ألا ينجح، وإعادة البناء تصلحه لفترة من الوقت.
سأحصل أيضًا على سجل الأخطاء قريبًا.
عند تشغيل /var/log/monitor.log - باستخدام tail -99، أحصل على: -bash: /var/log/monitor.log: تم رفض الإذن
(من لقطة الشاشة الخاصة بك، أرى أن الحاوية المسماة “app” لديها حد للذاكرة يبلغ 7.8 جيجابايت وتستخدم فقط 3%، لذا فهذا أمر جيد. تعديل: لكن قد يكون من المشبوه أنها تستخدم 100% من وحدة المعالجة المركزية.)
نحن بحاجة فقط إلى النظر في نهاية ملف السجل هذا، لذا
tail -199 /var/log/monitor.log
قد يعطينا ما نحتاجه. لكن قد نحتاج إلى النظر في جزء أكبر منه: ربما يمكنك ضغط ملف السجل وإرفاقه، أو مشاركته بطريقة أخرى. ما هو حجم ملف السجل؟
ls -l /var/log/monitor.log
أعتقد أن 100% تعني نواة واحدة، لأن النظام يعمل بشكل جيد.
log.txt (25.0 KB)
199 سطرًا من سجل الأحداث.
monitor.txt (39.3 كيلوبايت)
إليك سجل كامل 
شكرًا لك. يبدو كل شيء سليمًا، لكن هذه مجرد لقطة واحدة. ما يجب أن يحدث هو إرفاق قسم جديد إلى السجل كل 10 دقائق. انتظر حتى تكتشف المشكلة في نظام discourse الخاص بك، ثم شارك آخر بضعة أقسام.
يجب أن أقول إنني لا أعرف ما الذي يحدث.
لاحظت أن الثلاثة unicorns تستهلك قدرًا كبيرًا من وحدة المعالجة المركزية، ولا أعرف السبب في ذلك.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \_ unicorn worker[2] -E production -c config/unicorn.conf.rb
يمكنك تشغيل top والضغط على shift+m لفرز الاستخدام حسب الذاكرة العشوائية (RAM) ورؤية ما يستهلك أكبر قدر من الذاكرة العشوائية. هل يمكنك نشر النتيجة هنا؟
