एक रात का batch job database connection खत्म कर रहा है और API timeout हो रही है। आप इसे कैसे ठीक करते हैं?

batch job को throttle या रोककर तुरंत का नुकसान बंद करें, फिर दोनों workload को अलग करें ताकि वे आपस में होड़ ही न कर सकें। अगर job ज्यादातर read करती है तो उसे read replica पर भेजें, उसे सख्त सीमा वाला अपना connection pool दें, और काम को रुकावटों के साथ टुकड़ों में बांटें ताकि वह database पर कभी कब्जा न करे। लंबे समय के लिए interactive traffic के लिए capacity रिजर्व करें और यूजर को पता चलने से पहले connection pool भरने पर alert करें।

पहले खून बहना रोकिए। batch job को रोकिए या throttle कीजिए, क्योंकि interactive रास्ता वही है जो ग्राहक महसूस करते हैं और batch एक घंटे बाद चल सकती है और किसी को फर्क नहीं पड़ेगा। लुभावना हल यह लगता है कि अधिकतम connection बढ़ा दो, और उससे आमतौर पर हालत बिगड़ती है, क्योंकि हर connection की memory और scheduling लागत होती है और आपके पास सिर्फ व्यस्त database के बजाय एक ऐसा database आ जाता है जो पिस रहा है। तो असली हल isolation है। अगर job ज्यादातर read करती है तो वह read replica पर चली जाती है, जिससे primary पर से load पूरी तरह हट जाता है। उसे अपने credentials और सख्त सीमा वाला अपना pool मिलता है, जिसका आकार ऐसा हो कि पूरी तरह भर जाने पर भी API के लिए खूब गुंजाइश बचे। और खुद job टुकड़ों में बंट जाती है, तो वह एक विशाल transaction जो lock पकड़े रखे और replication lag बढ़ा दे, उसकी जगह छोटे batch में एक छोटी रुकावट और statement timeout के साथ process करती है। फिर रोकथाम: pool utilization और लंबी चलने वाली query पर ऐसे थ्रेशोल्ड पर alert जो यूजर को दिखने से पहले बज जाए, ताकि हमें यह support ticket के बजाय monitoring से पता चले।