लोड पड़ने पर आपका API timeouts लौटाने लगता है, पर डेटाबेस का CPU कम है और queries तेज़ दिख रही हैं। आप कहां देखेंगे?

यह मेल connection pool के खत्म होने या ऐसी ही किसी concurrency सीमा की तरफ इशारा करता है, डेटाबेस के धीमे होने की तरफ नहीं। pool wait time और active बनाम idle connections देखें: requests connection के लिए कतार में हैं जबकि हर पकड़ने वाला उसे बहुत देर तक रोके है, अक्सर किसी ट्रांजैक्शन के अंदर धीमी external call की वजह से, किसी छूटे हुए timeout की वजह से, या ऐसे leaked connection की वजह से जो कभी लौटाया ही नहीं गया। पहले पकड़ने का समय ठीक करें, फिर pool का आकार सोच समझकर तय करें।

तेज़ queries पर धीमी requests का मतलब है कि समय किसी चीज़ के इंतज़ार में जा रहा है, और शक की सुई pool पर ही जाती है। मैं pool wait time और connections कितनी देर पकड़े जाते हैं, यह देखूंगा, साथ ही डेटाबेस की तरफ active बनाम idle in transaction sessions की गिनती। ढेर सारे idle in transaction ही असली सुराग हैं: किसी ने ट्रांजैक्शन खोला और फिर ऐसा काम किया जो डेटाबेस का काम है ही नहीं। लगभग हमेशा वजह यही होती है, किसी payment provider को HTTP call या कोई धीमा serialization कदम ट्रांजैक्शन के अंदर बैठा है, तो हर request पांच मिलीसेकंड की जगह एक सेकंड तक connection पकड़े रहती है और pool ट्रैफ़िक के छोटे से हिस्से पर ही खाली हो जाता है। हल यह है कि critical section छोटा किया जाए: external call ट्रांजैक्शन से पहले या बाद में करो, statement और transaction timeouts लगाओ, और पक्का करो कि हर रास्ता error पर भी अपना connection लौटा दे। इसके बाद ही मैं आकार को छूऊंगा, वह भी संभलकर, क्योंकि हर instance उसे गुणा कर देता है। पकड़ने का समय ठीक किए बिना pool बढ़ा देना बस कतार को डेटाबेस पर सरका देता है और एक धीमे endpoint को पूरे सिस्टम का outage बना देता है।