لا يمكن زيادة db_shared_buffers (0.1٪ من إجمالي الذاكرة العشوائية) و db_work_mem (0.03٪ من إجمالي الذاكرة العشوائية)

[markersocial]

هذا أمر محير بعض الشيء

لدي نسخة Discourse تم ترحيلها حديثًا على خادم جديد.

أتلقى الخطأ في السجلات: PG::DiskFull (ERROR: could not resize shared memory segment \"/PostgreSQL.1759815625\" to 8388608 bytes: No space left on device )

إنه غريب، لأن الخادم السابق (64 جيجابايت من ذاكرة الوصول العشوائي) لم يكن لديه هذه المشكلة وكان لدي الإعدادات التالية:

db_shared_buffers: "25632MB"
db_work_mem: "160MB"

على الخادم الجديد (128 جيجابايت من ذاكرة الوصول العشوائي)، لا يمكنني الزيادة فوق الإعدادات الافتراضية الأساسية (حاولت مضاعفة القيم أدناه ثلاث مرات وأحصل على نفس خطأ PG DiskFull):

db_shared_buffers: "128MB"
db_work_mem: "40MB"

الجهاز السابق لديه Docker 27.x عليه (تم تثبيته تلقائيًا عبر مثبت Discourse). الجهاز الجديد قام بتثبيت docker.io حسب التعليمات (لذلك 26.x). حاولت التبديل إلى Docker 27.x لمعرفة ما إذا كان هذا هو السبب - لكنه لم يغير شيئًا. كلاهما على فرع Discourse المستقر، الإصدار 3.3.2.

يبدو أن shm_size قد يكون السبب الرئيسي:

PG throws could not resize shared memory segment error

This is due to the fact that docker by default restricts shared memory size to 64MB which makes pg10 run afoul of this limitation when doing a number of scatter/gather jobs in parallel: Outside the container: supermathie@host: ~ $ df -h /dev/shm Filesystem Size Used Avail Use% Mounted on none 63G 1.2M 63G 1% /run/shm Inside the container: supermathie@host: ~ $ docker exec -it postgres-master df -h /dev/shm Filesystem Size Used Avail Use% Mounted on shm …

على الرغم من أنني لا أعرف لماذا لم تكن مشكلة على الخادم السابق وهي كذلك على الخادم الجديد. الاختلاف الرئيسي الآخر هو أن الخادم القديم يستخدم Ubuntu 22.04 LTS والخادم الجديد يستخدم 24.04 LTS.

لقد جربت هذا أيضًا، ولكن التغييرات يتم استبدالها عند بدء تشغيل الحاوية مرة أخرى

Docker shm_size Option in app.yml

Hey @Ghan In the meantime (for testing purposes, see caveat below), you can change this directly with docker after the container is built, as follows: Edit the /var/lib/docker/containers/$CONTAINER_ID/hostconfig.json file directly. For example, change the value for ShmSize in the file above. Stop and restart the container. In our docker container hostconfig file, it looks like this: "ShmSize":536870912, [Screen Shot 2020-12-29 at 12.39.17 PM] HTH Caveat: Some people have posted that y…

يبدو أن shm_size مبرمج بشكل ثابت في المشغل:

launcher

launcher

launcher

أي رؤى أو مساعدة ستكون موضع تقدير!

[pfaffman (Jay Pfaffman)]

@markersocial

لا توجد مساحة متبقية على الجهاز

يشير إلى مساحة القرص الصلب، وليس ذاكرة الوصول العشوائي.

[markersocial]

@pfaffman

يشير إلى مساحة القرص الصلب، وليس ذاكرة الوصول العشوائي.

شكرًا @pfaffman - اعتقدت ذلك في البداية أيضًا، لكنني قرأت هذا الموضوع بعد ذلك:

PG throws could not resize shared memory segment error

After upgrading (with ‘launcher rebuild app’ times two) to Postgres 10, we’ve started seeing errors like this in /logs: Failed to handle exception in exception app middleware : PG::DiskFull: ERROR: could not resize shared memory segment "/PostgreSQL.682207201" to 283432 bytes: No space left on device : SELECT "topics"."id" AS t0_r0, "topics"."title" AS t0_r1, "topics"."last_posted_at" AS t0_r2, … Ideas? Looks like PG is unable to increase the size of a shared memory segment, can this be tuned …

هناك الكثير من المساحة الخالية أيضًا

[markersocial]

لذا فإن الإصلاح السريع بشريط لاصق هو ببساطة تحرير ملف المشغل مثل:

cd /var/discourse
vi launcher

ثم استبدل جميع التكرارات الثلاثة لـ
--shm-size=512m
بمقدار ذاكرة الوصول العشوائي المطلوب (لقد اخترت 50٪ من ذاكرة النظام).

ثم أعد البناء. ستحتاج إلى تحريره مرة أخرى في كل مرة يتم فيها تحديث المشغل.

يبدو أنه يقوم بالمهمة في الوقت الحالي.

[markersocial]

@mcdanlj

تكوين النواة (Kernel configuration)

يوصي Redis (أحد المكونات الأساسية التي يعتمد عليها Discourse) بشدة بتعطيل الصفحات الضخمة الشفافة عند استخدام الاستمرارية على القرص (وهو ما يفعله Discourse)، وأنا أيضًا أسمح بتجاوز تخصيص الذاكرة.

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

لذا للمتابعة في حال واجه شخص آخر هذه المشكلة - الحل أعلاه حلها بالنسبة لي. لم أعد بحاجة إلى تعديل shm-size في المشغل.

تم العثور على هذا بعد ملاحظة هذا التحذير أثناء إعادة البناء:
تحذير يجب تمكين تجاوز تخصيص الذاكرة! بدون ذلك، قد يفشل الحفظ في الخلفية أو النسخ المتماثل في ظل ظروف الذاكرة المنخفضة. وبما أنه معطل، يمكن أن يتسبب أيضًا في فشل دون ظروف الذاكرة المنخفضة، انظر https://github.com/jemalloc/jemalloc/issues/1328. لإصلاح هذه المشكلة أضف 'vm.overcommit_memory = 1' إلى /etc/sysctl.conf ثم أعد التشغيل أو قم بتشغيل الأمر 'sysctl vm.overcommit_memory=1' لتفعيل ذلك.