2010-06-09 7 views
5

मेरी साइट पर कभी-कभी ट्रैफ़िक के काफी अनुमानित विस्फोट होते हैं जो थ्रूपुट को सामान्य से 100 गुना अधिक बढ़ाते हैं। उदाहरण के लिए, हमें एक टेलीविज़न शो में दिखाया जा रहा है, और मुझे शो के एक घंटे बाद उम्मीद है, मुझे सामान्य से 100 गुना अधिक ट्रैफिक मिलेगा।प्रदर्शन के लिए MySQL में स्थायित्व को कम करें

मेरे समझ है कि MySQL (InnoDB) आम तौर पर अलग-अलग स्थानों के एक झुंड में अपने डेटा रखता है:

  • रैम बफ़र
  • commitlog
  • द्विआधारी लॉग
  • वास्तविक टेबल
  • सब के सब मेरे डीबी दास

पर उपर्युक्त स्थान यह बहुत अधिक "स्थायित्व" है क्योंकि मैं एक ईसी 2 नोड पर हूं और अधिकांश चीजें एक ही नेटवर्क पाइप में जाती हैं (फाइल सिस्टम नेटवर्क संलग्न होते हैं)। इसके अलावा ड्राइव बस धीमी हैं। डेटा उच्च मूल्य नहीं है और भीड़ आने पर आउटेज की उच्च संभावना होने की बजाय डेटा हानि के कुछ मिनटों का एक छोटा सा मौका लेना चाहता हूं।

इन ट्रैफिक विस्फोटों के दौरान मैं केवल उन सभी I/O केवल करना चाहता हूं यदि मैं इसे बर्दाश्त कर सकता हूं। मैं जितना संभव हो उतना रैम में रखना चाहता हूं (मेरे पास डेटा आकार की तुलना में रैम का एक उचित हिस्सा है जो एक घंटे से अधिक छुआ जाएगा)। यदि बफर दुर्लभ हो जाते हैं, या I/O चैनल बहुत अधिक भारित नहीं होता है, तो निश्चित रूप से, मैं चीजों को दास को भेजने के लिए प्रतिबद्धता या बाइनरी लॉग पर जाना चाहता हूं। यदि, और केवल तभी, I/O चैनल अधिभारित नहीं है, तो मैं वास्तविक तालिकाओं पर वापस लिखना चाहता हूं।

दूसरे शब्दों में, मैं माईएसक्यूएल/इनो डीबी को कैश एल्गोरिदम के माध्यम से "लिखना" कैश एल्गोरिदम का उपयोग करने के लिए चाहता हूं। क्या मैं इसे ऐसा करने के लिए मना सकता हूं?

यदि यह संभव नहीं है, तो मुझे सामान्य MySQL लेखन-प्रदर्शन अनुकूलन युक्तियों में रूचि है। अधिकांश दस्तावेज़ पढ़ने के प्रदर्शन को अनुकूलित करने के बारे में हैं, लेकिन जब मुझे उपयोगकर्ताओं की भीड़ मिलती है, तो मैं उन सभी के लिए खाता बना रहा हूं, इसलिए यह एक लेखन-भारी वर्कलोड है।

उत्तर

1

बड़े हिस्से के लिए, InnoDB पहले से ही ऐसा करता है।

जब आप डेटा करते हैं, तो यह रिकवरी उद्देश्यों के लिए लॉग फ़ाइल में लिखा जाता है लेकिन टेबलस्पेस (डेटा) में संशोधन केवल पृष्ठभूमि प्रक्रिया ('चेकपॉइंट') के रूप में किया जाता है।

आप निर्दिष्ट कर सकते हैं कि कितने IOPS (http://en.wikipedia.org/wiki/IOPS) आप नए InnoDB विज्ञप्ति (innodb_io_capacity) में है कि पृष्ठभूमि प्रक्रिया के लिए समर्पित करना चाहते हैं, और आप अपने innodb_log_file_size सेट कि बड़ा पर्याप्त InnoDB बस थोड़ी देर के लिए पीछे गिर जाते हैं और वापस ऊपर पकड़ेगा प्रदान की बाद में।

यदि पृष्ठभूमि कार्य पर InnoDB बहुत पीछे आता है तो यह आपके लॉग फ़ाइलों के अंत तक पहुंचने पर प्रदर्शन में तेज डुबकी बना सकता है, और उसे वापस चक्र करना होगा।इन बेंचमार्क पर 'none' लाइन देखें: http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/

3

यदि आप कुछ अतिरिक्त जोखिम के साथ रह सकते हैं, तो इन दो परिवर्तनों से आपके लेखन प्रदर्शन में काफी वृद्धि होगी।

सेट innodb_flush_log_at_trx_commit = 0
सेट sync_binlog = 0

इसके अलावा, आपके बफर पूल आकार सर्वर स्मृति के आसपास 70-80% होना चाहिए। लॉग फ़ाइल आकार बढ़ाना और लॉग बफर आकार कुछ डिग्री में भी मदद कर सकता है।

+0

धन्यवाद। मैं उन लोगों के साथ परेशान हूँ। –

संबंधित मुद्दे