👐 👩🏿‍🤝‍👩🏾 🔠 MySQL क्वेरी किलर - DBMS अधिभार फ्यूज ✊ 💶 🗾

यह प्रक्रिया बताती है कि अतिभारित सिस्टम के डेटाबेस को ओवरलोड से कैसे बचाया जाए।

आपके प्रश्नों के अनुकूलित होने के बाद, सिद्धांत रूप में आपके पास ऐसी स्थितियाँ नहीं होनी चाहिए
1. एक अनुरोध दूसरों को ब्लॉक करता है
2. कुछ अनुरोध एक दूसरे को अवरुद्ध करते हैं
हम यह सुनिश्चित करने का प्रयास करते हैं कि ऐसी स्थितियाँ उत्पन्न न हों।

इसलिए, स्मार्ट "क्वेरी हत्यारा" प्रदर्शन के लिए एक अच्छा "चौकीदार" होगा
जो संदिग्ध परिस्थितियों को ट्रैक करेगा और डेटाबेस को मुक्त करेगा।

यह हत्यारा एक ऐसी स्थिति की अनुमति देता है जहां डेटाबेस भारी प्रश्नों की एक जोड़ी करता है।
लेकिन जब वह देखता है कि कई लंबे अनुरोध दिखाई देने लगते हैं, तो वह कार्रवाई करना शुरू कर देता है

नियुक्ति

क्वेरी हत्यारा के लिए करना है:
1. ट्रैकिंग स्थितियों जब:
1.1। कुछ अनुरोध लॉक और अन्य अनुरोधों को अवरुद्ध करते हैं
1.2। कम समय में शुरू की गई बड़ी संख्या में क्वेरी एक-दूसरे को रोकती हैं
2. ऐसी स्थितियों का प्रवेश
3. ऐसी स्थितियों को हल करना:
3.1। स्थितियों के लिए जब एक अनुरोध दूसरे को अवरुद्ध करता है - तालों के स्रोत को मारें: सबसे लंबे अनुरोध को मारें
3.2। उन स्थितियों के लिए जहां अनुरोध एक दूसरे को अवरुद्ध करते हैं - डेटाबेस को मुक्त करने का प्रयास करें: उन अनुरोधों की एक श्रृंखला को मारें जो कुछ कम सीमा से अधिक हैं

इसलिए, भले ही एक बार आपके द्वारा अनुकूलित कैश जनरेशन प्रक्रिया या कार्य अनुरोध फिर से विफल होने लगें, क्यूरी-किलर डेटाबेस को कैश पुनर्जनन के कारण झुकने की अनुमति नहीं देगा, लेकिन बस पुनर्जनन को मार देगा और त्रुटि लॉग को लॉग इन करेगा।
(कैश रीजनरेशन को अपनी मृत्यु की संभावना के लिए प्रदान करना चाहिए, और एक अस्थायी तालिका में उत्पन्न किया जाना चाहिए, जिसे बाद में लक्ष्य में बदल दिया गया है।)

तर्क - छद्म संहिता

नीचे क्वेरी-हत्यारा के लिए छद्म कोड है

-- CONSTANTS: SET @alert_query_duration:=10; SET @alert_queries_max_count:=6; SET @dangerous_query_duration:=15; SET @dangerous_queries_max_count:=30; SET @dangerous_queries_affect_duration_bottom:=5; -- Check long queries: SELECT @alert_queries_count:=COUNT(0) FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME>@alert_query_duration ORDER BY TIME DESC; IF (@alert_queries_count >= @alert_queries_max_count) THEN 1. Report to error_log: module = Query killer error = Maximum amount of long queries reached context = List of all long queries (which longer than @alert_query_duration) 2. Take actions: -- Check if there is a lot of dangerous queries already -- (which may cause each other locks): SELECT @dangerous_queries_count:=COUNT(0) FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME>@dangerous_query_duration ORDER BY TIME DESC; IF (@dangerous_queries_count >= @dangerous_queries_max_count) THEN -- KILL dangerous queries and queries, which probably might be already affected by them -- (so kill all queryes, where TIME>@dangerous_queries_affect_duration_bottom) ... ELSE -- KILL one query (the longes one) which probably locks all others ... END END

स्थितियों के उदाहरण

निम्नलिखित खतरनाक स्थितियों के उदाहरण हैं:

1. अनुरोध लॉक और इस तरह अन्य अनुरोधों को अवरुद्ध करता है
उदाहरण के लिए, एक संप्रदाय कैश उत्पन्न करने का अनुरोध एक मेज पर एक लंबा ताला बनाता है जिसे लगातार अपडेट किया जाना चाहिए - एक समान तस्वीर दिखाई देती है:

  97669965    root    localhost     gtf    289  Query CREATE TABLE gtf.cache_vw_... 99057101    root localhost:33092     gtf    284  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057467    root localhost:51863     gtf    276  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057499    root localhost:51868     gtf    275  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057840    root localhost:33164     gtf    267  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057907    root localhost:54313     gtf    266  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99057987    root localhost:59942     gtf    264  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i 99059528    root localhost:52062     gtf    229  Query UPDATE media INNER JOIN image_file USING(media_id) INNER JOIN i

यहां कैश टेबल बनाने का पहला अनुरोध मीडिया टेबल को अपडेट कर रहा है

2. कम समय में लॉन्च किए गए बड़ी संख्या में अनुरोध और एक दूसरे को ब्लॉक करना

ये अस्थायी का उपयोग करके प्रश्न हो सकते हैं ; फाइलसर्ट का उपयोग करना

 +------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+ | 1 | SIMPLE | vw | ref | fk_cache_vw_video_website1 | fk_cache_vw_video_website1 | 4 | const | 8643 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | mtc | eq_ref | PRIMARY,content_id | PRIMARY | 4 | gtf.vw.media_id | 1 | Using where | +------+-------------+-------+--------+----------------------------------+----------------------------------+---------+-----------------+------+----------------------------------------------+

जो, फिर भी, सामान्य मोड में काफी पवित्र हैं, लेकिन चरम भार पर डेटाबेस को मोड़ते हैं।

स्क्रिप्ट उन प्रणालियों में उपयोगी है जहां एक विकास पद्धति लागू होती है जो सिस्टम के सभी संभावित भागों के "समय से पहले" अनुकूलन का लक्ष्य नहीं रखती है,
और जहां प्रारंभिक अनुकूलन स्पष्ट अड़चन-एस में किया जाता है, और बाद में - सिस्टम के संचालन के दौरान पता चला।

MySQL क्वेरी किलर - DBMS अधिभार फ्यूज

नियुक्ति

तर्क - छद्म संहिता

स्थितियों के उदाहरण

More articles: