समस्या एक MySQL उदाहरण के लिए विशिष्ट है जहां आपके पास डेटाबेस में परिवर्तनों की उच्च दर है। अपना 5GB आयात चलाकर, आप तेजी से गंदे पृष्ठ बना रहे हैं। जैसे ही गंदे पेज बनते हैं, पेज क्लीनर थ्रेड मेमोरी से डिस्क पर गंदे पेजों को कॉपी करने के लिए जिम्मेदार होता है।
आपके मामले में, मुझे लगता है कि आप हर समय 5GB आयात नहीं करते हैं। तो यह डेटा लोड की एक असाधारण उच्च दर है, और यह अस्थायी है। आप शायद चेतावनियों की अवहेलना कर सकते हैं, क्योंकि InnoDB धीरे-धीरे पकड़ में आ जाएगा।
यहां इस चेतावनी की ओर ले जाने वाले आंतरिक का विस्तृत विवरण दिया गया है।
प्रति सेकंड एक बार, पेज क्लीनर बफर पूल से डिस्क पर गंदे पृष्ठों को फ्लश करने के लिए बफर पूल को स्कैन करता है। आपके द्वारा देखी गई चेतावनी से पता चलता है कि इसमें फ्लश करने के लिए बहुत सारे गंदे पृष्ठ हैं, और उनमें से एक बैच को डिस्क पर फ्लश करने में 4 सेकंड से अधिक समय लगता है, जब यह उस काम को 1 सेकंड से कम में पूरा कर लेता है। दूसरे शब्दों में, यह जितना चबा सकता है उससे कहीं अधिक काट रहा है।
आपने innodb_lru_scan_depth . को कम करके इसे समायोजित किया है 1024 से 256 तक। यह बफर पूल में कितनी दूर तक पेज क्लीनर थ्रेड अपने एक बार-प्रति-सेकंड चक्र के दौरान गंदे पृष्ठों की खोज करता है। आप इसे छोटे काटने के लिए कह रहे हैं।
ध्यान दें कि यदि आपके पास कई बफर पूल इंस्टेंस हैं, तो इससे फ्लशिंग अधिक काम करेगी। यह innodb_lru_scan_depth . को काटता है प्रत्येक बफर पूल उदाहरण के लिए काम की मात्रा। तो हो सकता है कि आपने अनजाने में स्कैन की गहराई को कम किए बिना बफर पूल की संख्या बढ़ाकर इस अड़चन का कारण बना दिया हो।
innodb_lru_scan_depth . के लिए दस्तावेज़ीकरण "डिफ़ॉल्ट से छोटी सेटिंग आमतौर पर अधिकांश कार्यभार के लिए उपयुक्त होती है।" ऐसा लगता है कि उन्होंने इस विकल्प को एक मान दिया है जो डिफ़ॉल्ट रूप से बहुत अधिक है।
आप बैकग्राउंड फ्लशिंग द्वारा उपयोग किए जाने वाले IOPS पर innodb_io_capacity के साथ एक सीमा निर्धारित कर सकते हैं और innodb_io_capacity_max विकल्प। पहला विकल्प I/O थ्रूपुट पर एक सॉफ्ट लिमिट है InnoDB अनुरोध करेगा। लेकिन यह सीमा लचीली है; यदि फ्लशिंग नए डर्टी पेज निर्माण की दर से पीछे हो रही है, तो InnoDB इस सीमा से अधिक फ्लशिंग दर को गतिशील रूप से बढ़ाएगा। दूसरा विकल्प एक सख्त सीमा को परिभाषित करता है कि InnoDB फ्लशिंग दर को कितनी दूर तक बढ़ा सकता है।
यदि फ्लशिंग की दर नए गंदे पृष्ठ बनाने की औसत दर के साथ बनी रह सकती है, तो आप ठीक रहेंगे। लेकिन यदि आप लगातार गंदे पृष्ठों को फ्लश करने की तुलना में तेजी से बनाते हैं, तो अंततः आपका बफर पूल गंदे पृष्ठों से भर जाएगा, जब तक कि गंदे पृष्ठ innodb_max_dirty_page_pct से अधिक न हो जाएं। बफर पूल की। इस बिंदु पर, फ्लशिंग दर अपने आप बढ़ जाएगी, और फिर से पेज_क्लीनर को चेतावनी भेजने का कारण बन सकता है।
एक अन्य उपाय यह होगा कि MySQL को तेज डिस्क वाले सर्वर पर रखा जाए। आपको एक I/O सिस्टम की आवश्यकता है जो आपके पेज फ्लशिंग द्वारा मांगे गए थ्रूपुट को संभाल सके।
यदि आपको यह चेतावनी हर समय औसत ट्रैफ़िक के अंतर्गत दिखाई देती है, तो हो सकता है कि आप इस MySQL सर्वर पर बहुत अधिक लेखन क्वेरी करने का प्रयास कर रहे हों। यह कई MySQL इंस्टेंसेस पर राइट्स को स्केल करने और विभाजित करने का समय हो सकता है, प्रत्येक का अपना डिस्क सिस्टम है।
पेज क्लीनर के बारे में और पढ़ें:
- पेश है पेज_क्लीनर थ्रेड में InnoDB (संग्रहीत प्रति)
- MySQL-5.7 DML ओरिएंटेड वर्कलोड को बेहतर बनाता है
