مرحباً @rgrzesk
“timeout exceeded when trying to connect” يأتي من مهلة استحواذ pg-pool، لذا لم توفر المجموعة عميلاً في غضون DB_POSTGRESDB_CONNECTION_TIMEOUT، وليس لأن مقبس Cloud SQL غير قابل للوصول. DB_POSTGRESDB_POOL_SIZE القيمة الافتراضية هي 2، وفي مثيل Cloud Run واحد، استعلامات بدء التشغيل بالإضافة إلى حركة المرور الواردة تصطف خلف هذين الاتصالين، وهذا هو السبب في بقاء نقطة النهاية الجذرية في 200 بينما انتقلت استدعاءات DB المدعومة إلى 500. ارفع كليهما على المراجعة:
ثم حد من تزامن حاوية Cloud Run إلى ما يقارب ما يمكن للمجموعة تقديمه (10 إلى 20)، لذا لا يمكن للارتفاع المفاجئ أن يتفوق عليه مرة أخرى. يسمح Cloud Run بـ 100 اتصال لكل مثيل إلى Cloud SQL، لذا يبقى 10 بشكل جيد ضمن ذلك.
انتهاء المهلة الزمنية لاستحواذ pg-pool يخبرك أن لا عميل أصبح متاحاً قبل الموعد النهائي. لكن هذا لا يثبت أن التجمع كان صغيراً جداً. لأن هذا حدث مرة واحدة بعد ستة أشهر مستقرة، فإن زيادة التجمع قد تنقل الضغط فقط إلى Cloud SQL.
قم بمطابقة المراجعة المتأثرة مع رسم بياني اتصال Cloud SQL وسجل بدء تشغيل Cloud Run لتلك الطابع الزمني. إذا كانت كلا الاتصالات الموجودة مشغولة بينما كانت الطلبات في الانتظار، فإن تجمع أكبر أو تزامن حاوية أقل معقول. إذا كانت الاتصالات الجديدة تنتهي المهلة الزمنية، فإن حجم التجمع ليس السبب الجذري.
غيّر حداً واحداً في كل مرة واحفظ القيمة السابقة مسجلة. وإلا فإن الحادثة التالية لن تخبرك بأي تغيير ساعد.
