شكراً على كل التفاصيل. من الجيد أنك فعلت ذلك
ولكن أعتقد أن القيام بذلك سيستمر فقط حتى إعادة التشغيل التالية. بعد إعادة التشغيل، ستحتاج إلى القيام بذلك مرة أخرى. انظر MKJ’s Opinionated Discourse Deployment Configuration للحصول على نصائح لجعل هذا دائمًا.
يبدو من المحتمل أن تكون لديك ذاكرة قليلة جدًا (بالمعنى الذي أعنيه الذاكرة العشوائية + الذاكرة الافتراضية) ومع ذلك يجب أن يكون 2 + 4 كافيين. يرجى تشغيل التشخيصات السريعة التالية ونشر النتائج:
cat /etc/lsb-release
uptime
df -h /
free
swapon
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
يرجى أيضًا مشاركة ملف app.yml الخاص بك هنا - ولكن ليس كلمات المرور والرموز السرية الموجودة بداخله!
إذا كنت قادرًا على إعداد اتصالين SSH، يمكنك استخدام أحدهما لتشغيل إعادة بناء التطبيق واستخدام الآخر لمعرفة ما تفعله الآلة. أحب التناوب
vmstat 5 5
ps auxrc
من الممكن أن تقوم بالتبديل إلى قرص بعيد - تخزين متصل بالشبكة - وهذا معروف بأنه مشكلة. سيكون بطيئًا جدًا. ربما يتسبب في انتهاء المهلة وهذا هو المشكلة. ربما هناك طريقة لضبط مهلة الانتهاء.
وجدت هذا - ربما يساعد؟
(مهلة النظام الافتراضية هي 90 ثانية، على الأقل في بعض إصدارات systemd، لذا فهذا يناسب بشكل جيد جدًا).
يمكنك محاولة التحايل على هذا عن طريق زيادة TimeoutStartSec في وحدة systemd الخاصة بـ postgresql (أو حتى بشكل عام)، والتي ربما تخفي المشكلة فقط حتى لا يبدأ تشغيل الخدمة فجأة مرة أخرى.
تعديل: إذا كان الأمر كذلك، فقد تكون هذه النصيحة جيدة:
يمكنك إلغاء التعليق في
/etc/systemd/system.confالأسطر:DefaultTimeoutStartSec=90s DefaultTimeoutStopSec=90sوتغيير القيمة إلى ما تعتبره مناسبًا.