لا أريد أن أفسد هذا الاحتفال، ولكن في الواقع، ومن خلال قراءة المنشورات، لا يوجد تأكيد قاطع على أن عملية نسخ احتياطي Discourse هي المسبب للمشكلة.
لماذا لا نتأكد بنسبة 100% من أن هذه المشكلة ناتجة عن عملية النسخ الاحتياطي اليومية؟ فهناك أكثر من عملية تعمل يوميًا عبر ملفات crontab على المضيفين.
هل قام @pnoeric بتشغيل أمر du على نظام الملفات /var/discourse (خارج الحاوية)؟
في ملاحظاتك، كتب @pnoeric:
root@x-app:/var/www/discourse# du -h -d 1
لكن هذا الأمر أغفل تمامًا المجلد المشترك الخاص بـ Discourse الذي يتضمن جميع النسخ الاحتياطية والملفات المرفقة! كما أغفل جميع ملفات Docker (والصور) على المضيف (والتي يمكن أن تكبر حجمًا إذا لم يتم تقليم الصور بمرور الوقت).
المكان الصحيح لتشغيل هذا الفحص هو خارج الحاوية (وليس داخلها!):
على سبيل المثال (خارج الحاوية):
cd /var/discourse
/var/discourse# du -sh *
4.0K bin
4.0K cids
56K containers
12K discourse-doctor
24K discourse-setup
164K image
24K launcher
4.0K LICENSE
12K README.md
24K samples
8.0K scripts
62G shared
148K templates
كما ترون، على هذا المضيف، المجلد المشترك هو 62 جيجابايت.
وكذلك من مجلد /var في نظام الملفات (خارج الحاوية):
cd /var
# du -sh *
511M cache
20K composetest
62G discourse
1.6G docker
8.0K legacy
52G lib
4.0K local
0 lock
4.0K locks
5.7G log
24K logs
64K mail
4.0K opt
4.0K registry
4.0K shared
1.9M spool
48K tmp
25G linux_app
2.2G www
لستُ أحاول إفساد هذا الاحتفال، ولكن قبل الخروج واقتراح العديد من “الإصلاحات” لـ Discourse، سيكون من الجيد جدًا التأكد بنسبة 100% من أن عملية النسخ الاحتياطي اليومية (cron) لـ Discourse هي المشكلة الفعلية.
لم نواجه أي مشكلة مع عملية النسخ الاحتياطي الحالية لـ Discourse، بالإضافة إلى ذلك، فإن إدارة نظام الملفات على المضيف ليست مهمة خاصة بـ Discourse بحد ذاتها.
هنا:
du
Filesystem 1K-blocks Used Available Use% Mounted on
udev 32892500 0 32892500 0% /dev
tmpfs 6584232 2136 6582096 1% /run
/dev/md2 470927632 215969956 230966124 49% /
tmpfs 32921160 0 32921160 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 32921160 0 32921160 0% /sys/fs/cgroup
/dev/md0 482922 75082 382906 17% /boot
/dev/sda1 244988 4636 240353 2% /boot/efi
tmpfs 6584232 0 6584232 0% /run/user/1000
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/0f8be368b0154285423630ad50148ee2d5fdcb357c46125eafa7374ca34ef29a/merged
shm 524288 1620 522668 1% /var/lib/docker/containers/ca7b55fc5a0c123f7b2b1234ea210aa8286a34167cba9344b7929547bd323c9b/mounts/shm
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/7cd7e8b5b35b496eaed68753cc995e9303499a24721062055e2f06beb07e26c8/merged
shm 65536 0 65536 0% /var/lib/docker/containers/3cc0c90c3e3a5db6692e7b5d21727fbb1c13c8e07e48e4f6d954214fc03694a9/mounts/shm
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/31533fdf68033eed96dab4f9df89025ea3dab172ed48b6ce6431840a8df1c8ea/merged
shm 524288 0 522668 0% /var/lib/docker/containers/631fbabedda9a430dd8204ec66fb45c7514d948025124171b960ea424e28d5d4/mounts/shm
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/7a3ba2223ee93bc868b52b3707799d0fd7b4ca6dcc0df29f20c2c98a53903ff1/merged
shm 65536 0 65536 0% /var/lib/docker/containers/7a145366268c8ac5543a4555dc1bfc63c1e85a654e4c793e96fc2cc2e8514388/mounts/shm
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/add4bdd7bd88df7a0e05dff21896d3ef796f7cf2ff9759e0bb04b1953f16cd95/merged
shm 65536 0 65536 0% /var/lib/docker/containers/123743e122089b94660a6bdd2a9e55055ad91b6f75cce4ac760f36066bcf14d0/mounts/shm
overlay 470927632 215969956 230966124 49% /var/lib/docker/overlay2/b376ff32eaac0c58463e8b99b6db9ec0da3405c3f7a9f00b5430f10e07d372b0/merged
shm 524288 0 524288 0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm
لنلقِ نظرة على ملفات Docker:
# cd /var/lib
# du -sh docker
30G docker
وتم تقليم وتنظيف صور Docker لدينا بانتظام.
اقترح @bartv بشكل صحيح البدء من هنا:
سأبدأ بفهم أي مجلد هو المسؤول عن هذا التضخم. نهجي القياسي هو الدخول إلى /var/discourse ثم تشغيل du -h -d 1. خذ أكبر مجلد، ادخل إليه وكرر العملية حتى تجد المشتبه به. بمجرد العثور عليه، قد يعطيك ذلك تلميحًا عما يحدث.
هذا بداية جيدة، ولكن قد يكون هناك العديد من الأماكن الأخرى على نظام الملفات المضيف التي يمكن أن تملأ النظام، بما في ذلك Docker، وملفات النواة (core files)، وما إلى ذلك.
الرسم البياني الذي يظهر ارتفاعًا في النسبة المئوية مرة واحدة يوميًا لا يكفي للقول، بسلطة، أن عملية النسخ الاحتياطي اليومية (cron) لـ Discourse هي السبب الجذري. قد تكون كذلك، ولكنها قد لا تكون كذلك، بناءً على الأدلة حتى الآن!