हम एक m1.xlarge MySQL RDS सर्वर चला रहे हैं और उच्च CPU उपयोग के साथ कुछ समस्याएँ हैं। हमें कुछ सप्ताह पहले कुछ समस्याएं हुई थीं, जिनमें सीपीयू का उपयोग बड़े उदाहरण पर 100% तक पहुंच गया था। जब हमने आकार को कुछ समय के लिए स्थिर करने के लिए अपग्रेड किया, लेकिन सीपीयू का उपयोग धीरे-धीरे फिर से बढ़ गया।
पिछले हफ्ते या तो सीपीयू का उपयोग उच्च 90 के दशक में हुआ है, जो कि लगातार 100% या उससे ऊपर पहुंच रहा है, जो हमारे उत्पादन स्थल को एक समय पर रोक देता है। Db सर्वर को रिबूट करने के बाद, घंटों के भीतर सीपीयू उपयोग समान स्तर तक वापस चढ़ गया।
मैंने mysql सर्वर पर शो प्रक्रिया सूची चलाई है, और MySQL व्यवस्थापक के माध्यम से उसी की निगरानी कर रहा है। कोई विशेष रूप से लंबे समय तक चलने वाले प्रश्न या प्रश्नों की अधिक मात्रा प्रतीत नहीं होती है। नींद की अवस्था में कुछ समय तक लेटे रहने की प्रक्रिया होती है ... ये अलग-अलग श्रमिक डेमन हैं जो हमारे मुख्य ऐप के बाहर चल रहे हैं जो डेटाबेस के साथ संवाद करते हैं। मैंने सर्वर नाम के साथ प्रोसेसलिस्ट आउटपुट में कॉपी किया है जो कि वे क्या हैं, इसका विवरण देने के लिए बदल दिया गया है:
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
मुझे यह भी कहना चाहिए कि इस अवधि के दौरान साइट पर ट्रैफ़िक बेहद कम है, जो सामान्य पीक ऑवर्स के सापेक्ष होता है, जो पीक टाइम में हम देखते हैं उस लोड का लगभग 10%।
हमारे पास नई अवशेष निगरानी भी है जो हमें दिखाती है कि सबसे अधिक समय लेने वाले ऐप डेटाबेस कॉल्स क्या हैं। यह हमें दिखाता है कि एक विशेष कॉल जो कि हमारे ऐप द्वारा db में बिताए गए समय का ९९% खाता है, जैसे आईडी द्वारा एक सरल खोज है:
SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1(उपरोक्त प्रक्रिया सूची में चल रहे प्रश्नों के समान नहीं)
पिछले हफ़्ते में इस ऑपरेशन में धीमी गति से वृद्धि हुई है, समय के अनुरोधों के बीच मानक विचलन बढ़ने के साथ, और सेकंड के संदर्भ में इसे मापने में भी अधिकतम समय लगता है। मुझे लगता है कि यह सीपीयू उपयोग की समस्याओं का एक कारण के बजाय सिर्फ एक परिणाम है।
इस तालिका में लगभग 80,000 पंक्तियाँ हैं, इसलिए यह विशाल नहीं है। यह उम्मीद की जाती है कि डेटाबेस में अधिकांश एप्लिकेशन का समय इस तालिका में रिकॉर्ड देखने में व्यतीत होता है, ऐप की मुख्य कार्यक्षमता इसके आसपास आधारित है। मैंने कुछ समय पहले अपने ऐप सर्वर से प्रोडक्शन डेटाबेस तक स्वयं एक समान क्वेरी चलाई है, जबकि सीपीयू का उपयोग लगभग 100% रहता है, और यह 1 या 2 एमएस के भीतर प्रतिक्रिया करता है।
उपरोक्त सभी के आधार पर, हमें यकीन नहीं है कि हमारे डिबगिंग के साथ कैसे आगे बढ़ें। जरा सोचिए कि अगर किसी के पास कोई भी विचार हो तो इसका मूल कारण क्या हो सकता है और इनकी जांच कैसे की जाए? हमारे डीबी सर्वर को चलाने वाले अंतर्निहित सर्वर तक पहुंच एक अमेज़ॅन आरडीएस उदाहरण के बाद से सीमित है।