لقد أجريت للتو مجموعة من الترقيات وقررت أن أسهل طريقة لحل أخطاء الذاكرة هي مضاعفة مساحة المبادلة إلى 4 جيجابايت. الجانب السلبي هو أنه في قطرة بسعة 1 جيجابايت، لا يوجد سوى 25 جيجابايت من أقراص SSD، لذا فإن فقدان 4 جيجابايت منها للمبادلة هو مقدار كبير من المساحة، وهي بالفعل ضيقة بعض الشيء مع 25 جيجابايت فقط.
إذًا، هل يجب علينا تغيير discourse-setup لجعل القيمة الافتراضية 3 جيجابايت؟
ما رأيك يا @Falco؟
إذا كان ذلك يحل المشكلة، فأنا مع ذلك تمامًا.
هل يمكنني أن أقترح بقوة أن يقوم برنامج تثبيت البرنامج النصي أيضًا بتعيين مُعدِّلَي النواة اللذين يؤثران على معالجة الذاكرة؟ سيكون من الجيد معرفة أن كل شخص لديه مشكلة على ما يبدو لديه على الأقل نقطة انطلاق لإعداد نواة جيد.
تبدو هذه فكرة معقولة بالنسبة لي. لا يمكنني تخيل أين يمكن أن تكون THP ذات قيمة في مثيل مخصص للنقاش، ويمكن أن يساعد الإفراط في الالتزام في تجنب OOM.
قد تفكر في تقديم القيام بكل من هذه بشكل منفصل، وتعيينها كاستجابة افتراضية، مع خيار عدم الافتراضي للخروج؟
أيضًا، يمكن للبرنامج النصي استخدام sysctl لمعرفة ما إذا كانت الإعدادات بحاجة إلى تغيير في المقام الأول قبل إجراء تغيير. إذا قام شخص ما بالفعل بإجراء هذه التغييرات بملفات مختلفة، فسيكون من المحتمل أن يكون مربكًا إنشاء تجاوزات مكررة. أعتقد أن ليس كل توزيعات Linux تأتي مع إيقاف تشغيل الذاكرة الزائدة في المقام الأول.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
هناك اعتبار ثانٍ، مع المخاطرة بتخفيف الرسالة المهمة حول المعلمات القابلة للضبط في النواة: النص البرمجي الحالي ينشئ فقط مساحة تبديل (swap) على جهاز ذي ذاكرة وصول عشوائي (RAM) منخفضة. أعتقد أن هذا خطأ، سواء لأن مساحة التبديل لا تزال مفيدة في زيادة الاستفادة من ذاكرة الوصول العشوائي (RAM)، ولكن الأهم من ذلك لأنها ستسبب مشاكل إذا قام شخص ما بإنشاء Discourse الخاص به على جهاز ذي ذاكرة وصول عشوائي (RAM) كبيرة، من أجل السرعة أو الراحة، ثم قام بتقليص حجمه إلى ذاكرة وصول عشوائي (RAM) صغيرة.
يجب أن يقوم الإعداد بإنشاء مساحة تبديل (swap) في جميع الحالات (ما لم يكن هناك ما يكفي بالفعل). من الصحيح وأحيانًا مفيد أن يكون لديك ملفات تبديل متعددة.
لست أنا من يقرر، وأنا أقوم بتعيين هذه الإعدادات على الأجهزة التي أقوم بإعدادها، ولكن هذا برنامج نصي shell يتم تشغيله بواسطة (معظم) كل من يقوم بتثبيت Discourse. يجب أن يكون بسيطًا قدر الإمكان، ونحن متأكدون من أن هذه الإعدادات تعمل على Raspberry Pi و Mac وأي هراء آخر يحاول الناس القيام به؟ وأي طريقة تستخدمها لاختبار ما إذا كانت مضبوطة بالفعل تعمل على كل هذه المنصات؟ يبدو الأمر صعبًا.
لقد كتبت discourse-setup وأجد أن إجراء تغييرات عليه أمر مخيف بعض الشيء.
تقديم عرض دائم لإنشاء مساحة مبادلة ليس فكرة سيئة. ربما نعرض دائمًا إعداد 3 أو 4 جيجابايت من مساحة المبادلة؟ ولكن بعد ذلك، ما مقدارها؟ قاعدة عامة عرفتها ذات مرة هي أن تكون مساحة المبادلة بنفس حجم ذاكرة الوصول العشوائي. وحاليًا، إذا لم تقم بإنشاء مساحة مبادلة، فإن خيارك الوحيد هو الخروج عن طريق الضغط على Control-C. لذا، إما أن نجبر الناس على إنشاء مساحة مبادلة أو نضيف سؤالًا آخر بنعم/لا (مما سيجعلني أعدل برامجي النصية التي تشغل discourse-setup 
) أوه! أو يمكننا التحكم فيه بواسطة مفتاح --skip-swap. يبدو هذا جيدًا بالنسبة لي. إذا كنت ذكيًا بما يكفي لمعرفة مساحة المبادلة، فيمكنك العثور على المفتاح لتخطيها؛ يمكننا إضافة ملاحظة حول المفتاح في تلك الرسالة التحذيرية.
وربما نضيف أيضًا ملاحظة حول --skip-connection-test عندما يفشل.
أعتقد أنه إذا كان لديهم مساحة مبادلة معدة بالفعل، فمن الآمن افتراض أنهم يعرفون ما يفعلونه.
شكرًا لك! ونعم، أتفهم تمامًا، كنت سأشعر بنفس الشيء. إنه يحتاج إلى تفكير واختبار دقيقين، بالتأكيد. وسيكون ذلك على الأقل على عدد قليل من الأجهزة الرخيصة لمقدمي الاستضافة، وعلى Pi أيضًا. لست متأكدًا بشأن ويندوز أو ماك - إذا كان من المتوقع دعمهما، فربما. أتوقع أن يتم استخدامهما بشكل أكبر كأجهزة تطوير، وهذا قصة مختلفة.
بالفعل. أي شيء يبدو ضروريًا في الوقت الحالي، ربما. يبدو أنه قد اتخذ خطوة للأعلى. لكنه يحزنني كثيرًا عدم معرفة ما إذا كانت هذه التقارير تتضمن تعديل التخصيص الزائد أم لا. أنا متأكد من أننا نعرف من المناقشات السابقة أن التخصيص الزائد يحدث فرقًا.
ونحن نعلم أن مساحة القرص محدودة في مثيل 25 جيجابايت، وبشكل أكبر في مثيل 20 جيجابايت. أقوم بالتشغيل على مثل هذه الأجهزة: قرص 25 جيجابايت وذاكرة وصول عشوائي 1 جيجابايت، والتي تحتاج بالفعل إلى مبادلة 2 جيجابايت وربما أكثر هذه الأيام؛ وقرص 20 جيجابايت مع ذاكرة وصول عشوائي 2 جيجابايت حيث لدي حاليًا مبادلة 1 جيجابايت.
لن أوصي بالمزيد من أسئلة نعم/لا. تبدو خيارات سطر الأوامر طريقًا أفضل.
إذا كنا سنغير هذا البرنامج النصي على الإطلاق، أعتقد أنني سأوصي بالعديد من ملفات المبادلة بحجم 1 جيجابايت، لأن ذلك يزيد من المرونة، ولا يهدر شيئًا، وهو أسهل وقت لاتخاذ هذا القرار.
لست متأكدًا من هذا. إذا كان أصغر مثيل مع نظام Ubuntu أو Debian عادي يحتوي بالفعل على بعض المبادلة - يجب التحقق من ذلك - فسنبدأ في مواجهة مشاكل إذا لم تكن كافية. من الأفضل بكثير قياس ذاكرة الوصول العشوائي + المبادلة باستخدام free، وضبطها كالمعتاد للتكوينات التي تقل عن 1 جيجابايت (AWS أعتقد، ربما Oracle)، ثم إضافة ملفات مبادلة بحجم 1 جيجابايت حتى عدد متفق عليه، أيًا كان ذلك حاليًا. نأمل أن يكون إجمالي 4 جيجابايت كافيًا، مع ضبط تخصيص النواة الزائد بشكل مناسب.
يسعدني المساعدة.
هممم. نعم. أتمنى لو فكرت في التحقق من ذلك في التقارير التي قمت بتعديلها للتو.
هممم. أنا أميل إلى أن واحداً أفضل، لكن المتعدد يضيف المرونة، ويمكن حينئذٍ أن يكون من الممكن جعل discourse-setup يضيف ملف swap آخر إذا كانت هناك حاجة إلى المزيد من الـ swap، مما يعني أنه يمكننا أن نطلب من الجميع تشغيل discourse-setup لـ “إصلاح” مشكلة الـ swap الخاصة بهم. وربما أيضاً مشكلة الـ overcommit كذلك - ربما نحاول صراحةً القيام بذلك فقط لنظام لينكس، بما أن هذا هو كل ما نهتم به.
أنا لا أتفق. مساحة المبادلة ليست شيئًا جيدًا عالميًا. كانت مهمة لجعل كود VM أكثر توازنًا عند عدم المبادلة في ظروف معينة، لكن خوارزميات VM قد تغيرت.
كان ذلك يعتمد على افتراضات قديمة جدًا من كود النواة لم تعد تنطبق.
أيضًا، عند التفكير في القياس: لا أعرف حتى ما الذي تريد قياسه لمساحة المبادلة والذاكرة عند استخدام zswap. هذه على الأرجح حالة “أولاً لا تسبب ضررًا” على الرغم من ذلك.
أنا متأكد من أن العيب الوحيد لـ “الكثير من التبديل” هو استخدام مساحة أكبر على القرص مما هو ضروري تمامًا. إنه أحد الأسباب التي تجعل من المفضل أن يكون لديك عدة ملفات تبديل متواضعة الحجم - يمكن للمرء إيقاف التبديل وإزالتها تدريجيًا، إذا كانت هناك حاجة لاستعادة مساحة القرص. أيضًا، أعتقد أن لينكس يقوم بعمل جيد بشكل معقول في استخدامها تدريجيًا:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
الوضع الذي نجد أنفسنا فيه هو أن المثيلات الرخيصة محدودة للغاية في كل من ذاكرة الوصول العشوائي ومساحة القرص، ويستخدم Discourse المزيد والمزيد، مع تطور العديد من الحزم بداخله. ولكن لا يزال، أعتقد أن هناك طرقًا للتنقل بحكمة، لمساعدة أولئك الذين ليسوا في وضع يسمح لهم فقط برفع أيديهم ومضاعفة أو مضاعفة فاتورتهم الشهرية.
التبديل بطيء بما يكفي لدرجة أنني لن أعتبر “بالكاد هناك مساحة الآن” سببًا لإضافة أكثر من 1 جيجابايت إلى الاقتراح الافتراضي في هذه المرحلة. كل 1 جيجابايت هي مساحة تبديل كبيرة، كما هو ملاحظ في مثيل Discourse مخصص.
نعم، بشكل افتراضي، يستخدم Linux مساحة التبديل بترتيب الأولوية، ومن الممكن استخدام نفس الأولوية عبر أجهزة متعددة لتقسيم مساحة التبديل بشكل صريح. ولكن إضافة الكثير من مساحة التبديل للمواقع الصغيرة ليست ذات قيمة كبيرة، كما أقترح.
لذلك، إذا كان الناس بعد حوالي عقد من الزمان يتعثرون بشكل متقطع في 2 جيجابايت، فأقترح الانتقال إلى 3 جيجابايت بدلاً من 4 جيجابايت كافتراضي. وكمية مساحة التبديل اللازمة لمثيل Discourse مخصص لا ينبغي أن تزداد بشكل خاص مع الذاكرة، لأن المحتوى الذي سيتم تبديله فعليًا لا يتغير كثيرًا.
فكرة زيادة مساحة التبديل مع المزيد من الذاكرة تأتي بشكل أساسي من الحوسبة للأغراض العامة، بناءً على افتراض عام بأنه كلما احتجت إلى ذاكرة وصول عشوائي أكبر، زاد الطلب المحتمل. ولكن ضغط مساحة التبديل على مثيل Discourse متخصص من غير المرجح أن يتبع هذا النمط، أعتقد.
صفحات THP خاصة بالمنصات التي تدعم الصفحات الكبيرة، وهي ليست كل المنصات. الطريقة العامة للتعامل مع ذلك هي معرفة ما إذا كانت موجودة. على أحد Raspberry Pi لدي:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
على النقيض من ذلك، فإن الإفراط في التخصيص هو معلمة VM عامة لنظام Linux على مدى العقود القليلة الماضية. على نفس Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
تحليل المخرجات من free في shell أمر مزعج نوعًا ما. بالحديث بصفتي المؤلف الأصلي لـ procps، لهذا سأبحث فقط عن SwapFree في /proc/meminfo. 
أتفق على أنه في عوالمنا المقيدة بالتكاليف، لم يعد توسيع التبديل حسب حجم ذاكرة الوصول العشوائي خطة رائعة. تبدو الفكرة التالية بعد ذلك تاريخيًا هي أن ذاكرة الوصول العشوائي ضخمة ولا تحتاج إلى تبديل. بعد ذلك تأتي الحكمة بأن بعض التبديل مفيد لأنه يسمح باستخدام أفضل لذاكرة الوصول العشوائي. (في عالم غير مقيد، لدينا فقط كميات هائلة من ذاكرة الوصول العشوائي، ولكن هذا مجال متخصص.)
ما نراه في هذين الشهرين الماضيين هو أن المزيد من الأشخاص يعانون من مشاكل نفاد الذاكرة وفشل إعادة البناء. المزيد من الأشخاص يجدون أن ترقيات الويب تفشل ولكن سطر الأوامر يعمل. من منظور دعم بسيط، ومن منظور سمعة المنتج، أعتقد أننا بحاجة إلى تغيير في النصيحة المعتادة والإعداد المعتاد. أعتقد أن 3 جيجا من التبديل هو أبسط تغيير وأصغر تغيير ويجب أن نفعله إذا لم نفعل شيئًا آخر.
لكنني ما زلت أعتقد أن ملفات التبديل المتعددة الأصغر هي خيار أكثر حكمة - وقد رأينا مواضيع دعم هنا تشير إلى ذلك. وما زلت أعتقد أنه سيكون من الأفضل محاولة تحديد حجم ذاكرة الوصول العشوائي + التبديل لأن هذا هو العامل المحدد، الشيء الذي يسبب مشاكل للناس. قد يكون هناك طرق مختلفة للقيام بهذا الحساب. تنطبق التحذيرات المعتادة حول التكتيكات التي يمكن صيانتها وفهمها ولها طول عمر.
أما بالنسبة للصفحات الضخمة الشفافة، ففهمي هو أن “الشفاف” هو ما يسبب المشاكل: يمكن للنواة أن تترنح، تدمج وتفك الدمج، مقابل خسارة في الأداء ولا فائدة كبيرة. أنا متأكد من أن الصفحات الضخمة غير مستحسنة للأنظمة الأصغر.
الأمر يتعلق بخصائص عبء العمل أكثر من حجم النظام. على نظام بذاكرة وصول عشوائي (RAM) بحجم 1 جيجابايت مع عمليات مستقرة نسبيًا ذات أجزاء من ذاكرة الوصول العشوائي، يمكن للصفحات الضخمة الافتراضية بحجم 2 ميجابايت تقليل تبديل TLB وتحسين الأداء؛ لا تغطي TLB المخططات لذاكرة وصول عشوائي بحجم 1 جيجابايت. إنها بشكل عام مجرد مقايضة بين وحدة المعالجة المركزية التي تقضي وقتًا في البحث عن الذاكرة لدمجها وفقدان ذاكرة التخزين المؤقت لـ TLB، وهناك العديد من أعباء العمل على أجهزة بحجم 1 جيجابايت التي يمكن أن تستفيد بشكل كبير من THP. (العديد من التوصيات لتعطيله تأتي من وقت مبكر من تنفيذه؛ لقد تم تحسينه بشكل كبير منذ ذلك الحين.) التوصية بتعطيل THP لـ Discourse ليست بسبب حجم ذاكرة الوصول العشوائي البالغ 1 جيجابايت، بل هي خاصة باستخدام redis مع الاستمرارية على القرص وهو شيء يستخدمه Discourse:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
للأسف، عندما يكون لدى نواة Linux صفحات ضخمة شفافة ممكّنة، يتكبد Redis عقوبة تأخير كبيرة بعد استدعاء
forkالمستخدم للاستمرار على القرص. الصفحات الضخمة هي سبب المشكلة التالية:
…