इसके साथ आगे प्रयोग करने और रेडिस दृढ़ता के बारे में पढ़ने से, मुझे लगता है कि निम्नलिखित अवलोकन किए जा सकते हैं:
- आरडीबी (डिफ़ॉल्ट सेटिंग्स) का उपयोग करते समय, रेडिस हर बार
saveको फोर्क करेगा ऑपरेशन ट्रिगर होता है, जो (डिफ़ॉल्ट रूप से) हर 15 मिनट में एक बार न्यूनतम के रूप में . पर सेट होता है . जब रेडिस को अधिक लेखन किया जाता है, तो आरडीबी लिखता है जितनी बार प्रत्येक 60 सेकंड । - प्रत्येक कांटा "कॉपी-ऑन-राइट" मेमोरी आवंटन का उपयोग करेगा, जिसका अर्थ है कि स्मृति वास्तव में दोगुनी नहीं होगी - यह
psजैसे टूल पर दिखाई देगी ,htopऔर इसी तरह। - फोर्क अपने आप में काफी सीपीयू-सघन ऑपरेशन हो सकता है, विशेष रूप से xen-आधारित वर्चुअल होस्ट (जो कि हम वर्तमान में उपयोग कर रहे हैं) पर।
- लिखने का कार्य पूरी तरह से अधिलेखित लगता है मौजूदा आरडीबी फ़ाइल। यह न केवल परिवर्तन लिखता है, बल्कि संपूर्ण . को डंप करता है डिस्क पर डेटासेट.
तो 4Gb रैम और लगभग 750Mb के डेटा सेट के साथ एक मामूली वर्चुअल होस्ट पर (जिस समय मैंने प्रश्न पोस्ट किया था), यह "महंगा" होने लगता है। हमने उन सीपीयू/मेमोरी स्पाइक्स के साथ-साथ आईओ में वृद्धि देखी, यहां तक कि काफी मध्यम लोड/रेडिस उपयोग के तहत भी।
तो मेरे अपने प्रश्न का उत्तर देने के लिए - यह "अपेक्षित" व्यवहार प्रतीत होता है।
स्थिति में सुधार के लिए, हमने RDB और AOF के संयोजन का उपयोग करने के लिए अपने कॉन्फ़िगरेशन को बदलने का विकल्प चुना। AOF (केवल संलग्न करें फ़ाइल), ऐसा प्रतीत होता है कि केवल परिवर्तन लिखता है डिस्क के लिए। आप अभी भी AOF फ़ाइल को फिर से लिखने के लिए कॉन्फ़िगर कर सकते हैं (और चाहिए) (auto-aof-rewrite-percentage का उपयोग करके) और auto-aof-rewrite-min-size समायोजन)। स्नैपशॉट के लिए अभी भी RDB का उपयोग करना भी उचित है। हालांकि इस कॉन्फ़िगरेशन में, आप शायद पूर्ण पुनर्लेखन/स्नैपशॉट कम बार-बार कर सकते हैं और फिर भी बहुत अच्छा प्रदर्शन और बेहतर स्थायित्व बनाए रख सकते हैं।
