उपलब्ध RAM का 50% परीक्षण करने के लिए उपयोग करें:
आप यह देखने के लिए कि क्या यह मदद करता है, आप innodb_buffer_pool_size को बहुत कम कर सकते हैं:
#/etc/my.cnf
innodb_buffer_pool_size = 1M
अंगूठे का एक नियम आपके कम मेमोरी परीक्षण के लिए innodb_buffer_pool_size को उपलब्ध RAM के 50% पर सेट करना है। इसका मतलब है कि आप सर्वर और सब कुछ छोड़कर . शुरू करते हैं MySQL InnoDB। देखें कि आपके पास कितनी रैम है। फिर उसमें से 50% का उपयोग InnoDB के लिए करें।
एक साथ कई लो-मेमोरी सेटिंग आज़माने के लिए:
एक अधिक संभावित अपराधी उस सर्वर पर जो कुछ भी है, जैसे कि वेबसर्वर।
अपाचे?
क्या आप अपाचे और/या किसी अन्य वेबसर्वर का उपयोग कर रहे हैं? यदि हां, तो इसके RAM उपयोग को कम करने का प्रयास करें। उदाहरण के लिए Apache conf में, निम्न RAM सेटिंग्स पर विचार करें:
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
और अनुरोधों को इस तरह कैप करें:
MaxRequestsPerChild 300
फिर अपाचे को पुनरारंभ करें।
mod_wsgi:
यदि आप mod_python के साथ Apache का उपयोग कर रहे हैं, तो mod_wsgi के साथ Apache पर स्विच करें।
पिम्प्लर:
यदि यह अभी भी हो रहा है, तो संभवतः आपका Django लगातार बढ़ रहा है। पिम्प्लर के साथ Django मेमोरी प्रोफाइलिंग का प्रयास करें:
एसएआर:
एक बार-प्रति-दिन की विफलताओं की आपकी रिपोर्ट, फिर एक बार-प्रति-सप्ताह की विफलताएं, दैनिक या साप्ताहिक चलने वाले किसी प्रकार के क्रॉन जॉब की ओर इशारा कर सकती हैं। उदाहरण के लिए, शायद कोई बैच प्रक्रिया है जिसमें बहुत अधिक RAM, या डेटाबेस डंप आदि की आवश्यकता होती है।
RAM के उपयोग को ट्रैक करने के लिए और MySQL के मरने से एक घंटे पहले RAM स्पाइक्स देखने के लिए, SAR पर एक नज़र डालें, जो एक बेहतरीन टूल है:http://www.thegeekstuff.com/2011/03/sar-examples/
