توقف Discourse بسبب مشكلة في اتصال PSQL

[jimmy0017]

لقد كنا نتلقى هذه الرسالة باستمرار على منتدانا. (كل 3-4 ساعات تقريبًا). لدينا 16 نواة معالج و 32 جيجابايت من ذاكرة الوصول العشوائي. لا أعتقد أن الموارد تمثل مشكلة.

عفوًا
واجه البرنامج الذي يشغل منتدى المناقشة هذا مشكلة غير متوقعة. نعتذر عن الإزعاج.

تم تسجيل معلومات مفصلة حول الخطأ، وتم إنشاء إشعار تلقائي. سنلقي نظرة عليه.

لا يلزم اتخاذ أي إجراء إضافي. ومع ذلك، إذا استمرت حالة الخطأ، يمكنك تقديم تفاصيل إضافية، بما في ذلك خطوات إعادة إنتاج الخطأ، عن طريق نشر موضوع مناقشة في فئة ملاحظات الموقع.

يُظهر سجل الإنتاج

app/models/user_auth_token.rb:125:in `lookup'
lib/auth/default_current_user_provider.rb:131:in `current_user'
lib/current_user.rb:35:in `current_user'
app/controllers/application_controller.rb:1047:in `rate_limit_crawlers'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:393:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-silence_logger.rb:27:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:236:in `call'
خطأ غير متوقع في Message Bus : ActiveRecord::ConnectionNotEstablished : فشل الاتصال بالخادم على "172.17.0.2"، المنفذ 5432: FATAL:  remaining connection slots are reserved for non-replication superuser connections

خطأ غير متوقع في Message Bus : ActiveRecord::ConnectionNotEstablished : فشل الاتصال بالخادم على "172.17.0.2"، المنفذ 5432: FATAL:  remaining connection slots are reserved for non-replication superuser connections

خطأ غير متوقع في Message Bus : ActiveRecord::ConnectionNotEstablished : فشل الاتصال بالخادم على "172.17.0.2"، المنفذ 5432: FATAL:  remaining connection slots are reserved for non-replication superuser connections

خطأ غير متوقع في Message Bus : ActiveRecord::ConnectionNotEstablished : فشل الاتصال بالخادم على "172.17.0.2"، المنفذ 5432: FATAL:  remaining connection slots are reserved for non-replication superuser connections

لقد قمنا بتعيين التكوين التالي في

UNICORN_WORKERS: 32
UNICORN_SIDEKIQS: 2

ولـ psql

db_shared_buffers: "4096MB"

يرجى إخباري بما يمكنني فعله آخر لتحسين التكوين والتأكد من أن الخادم لن يتعطل.

[pfaffman (Jay Pfaffman)]

سأمنح postgres (db_shared_buffers) 16 جيجابايت على الأقل إن لم يكن 20.

لكنك بحاجة إلى إجراء المزيد من اتصالات قاعدة البيانات. لا أتذكر كيف يتم ذلك.

أعتقد أنه max_connections في /etc/postgresql/postgresql.conf (داخل الحاوية التي تشغل postgres) الذي تحتاج إلى تغييره.

[RGJ (Richard - Communiteq)]

@pfaffman

ولكنك تحتاج إلى إنشاء المزيد من اتصالات قاعدة البيانات

أعتقد ذلك أيضًا.

@pfaffman

سأعطي postgres (db_shared_buffers) 16 جيجابايت على الأقل إن لم يكن 20

هل أنت متأكد من ذلك؟ هذا يبدو مرتفعًا. انظر PostgreSQL: Documentation: 13: 19.4. Resource Consumption

إذا كان لديك خادم قاعدة بيانات مخصص به 1 جيجابايت أو أكثر من ذاكرة الوصول العشوائي، فإن قيمة بداية معقولة لـ shared_buffers هي 25٪ من الذاكرة في نظامك. هناك بعض أعباء العمل حيث تكون الإعدادات الأكبر لـ shared_buffers فعالة، ولكن نظرًا لأن PostgreSQL يعتمد أيضًا على ذاكرة التخزين المؤقت لنظام التشغيل، فمن غير المرجح أن يؤدي تخصيص أكثر من 40٪ من ذاكرة الوصول العشوائي لـ shared_buffers إلى العمل بشكل أفضل من كمية أقل.

وهذا ليس خادم قاعدة بيانات مخصص، فهناك 32 عملية unicorn عليه أيضًا.

[pfaffman (Jay Pfaffman)]

@RGJ

هل أنت متأكد من ذلك؟ هذا يبدو كثيراً.

أنا دائماً أرجع إليك في الأمور كهذه، واعتقدت أنني أقتبس نصيحة قدمتها في الماضي، لذا، لا لست متأكداً.

من الواضح أن الاتصالات هي المشكلة وزيادة ذاكرة الوصول العشوائي إلى 25% من 32 جيجابايت قد تساعد بشكل عام، ولكنها ليست سبب الخطأ.

تحرير:

@RGJ

تجاهل كل النصائح التي تجدها على الإنترنت واضبطها على 40-50% من ذاكرتك.

ها! هذا بالضبط ما أتذكره، إلا أنه يبدو أنني كنت سأتجاوز 50%. . .

[RGJ (Richard - Communiteq)]

@pfaffman

اعتقدت أنني كنت أقتبس نصيحة قدمتها في الماضي

أعترف بالذنب نوعًا ما

@RGJ

تجاهل كل النصائح التي تجدها على الإنترنت واضبطها على 40-50٪ من ذاكرتك.

لكن هذا كان في الماضي …

@pfaffman

من الواضح أن الاتصالات هي المشكلة وزيادة ذاكرة الوصول العشوائي إلى 25٪ من 32 جيجابايت قد تساعد بشكل عام، ولكنها ليست سبب الخطأ.

[Falco]

@jimmy0017

قمنا بتعيين التكوين التالي في

UNICORN_WORKERS: 32
UNICORN_SIDEKIQS: 2

لماذا؟ هذه هي أسباب نفاد فتحات الاتصال لديك.

[jimmy0017]

أعتقد أنني رأيت في مكان ما أن UNICORN WORKER يجب أن يكون 2 * CPU. لذلك قمت بالحساب ليكون 32. هل يجب أن أقلل الحجم؟

[jimmy0017]

لقد حاولنا تغيير إعداد المهلة لـ PSQL عن طريق تشغيل ALTER ROLE discourse SET statement_timeout = '30000';. وهذا الاستعلام هو الذي تم حظره، مرة كل ساعتين.

لست متأكدًا مما إذا كان لديك أو لدى أي شخص آخر أي فكرة عما حدث؟

[Falco]

@jimmy0017

أعتقد أنني رأيت في مكان ما أن UNICORN WORKER يجب أن يكون 2 * CPU. لذلك قمت بالحساب ليكون 32. هل يجب أن أقلل؟

لا، يرجى إزالة هذا والسماح للقيم الافتراضية بالعمل. هذه هي الحالة الكلاسيكية للتحسين المبكر.

[RGJ (Richard - Communiteq)]

@jimmy0017

لقد حاولنا تغيير إعداد المهلة لـ PSQL عن طريق تشغيل ALTER ROLE discourse SET statement_timeout = '30000'; .

@jimmy0017

لست متأكدًا مما إذا كان لديك أو لدى أي شخص آخر أي فكرة عما حدث؟

نعم، لقد لمست أشياء لا ينبغي لك لمسها