रेडिस सर्वर

Question

के लिए सर्वश्रेष्ठ ईसी 2 सेटअप हम एक बड़े पैमाने पर वेब एप्लिकेशन को तैनात कर रहे हैं जो केवल डेटा स्टोर के रूप में रेडिस का उपयोग करता है। मुझे लगता है कि हमारे रेडिस मास्टर का बेंचमार्क ईसी 2 पर प्रति सेकेंड 8000 लेनदेन है, जो समर्पित हार्डवेयर पर बताए गए बेंचमार्क से काफी कम है।

मैं समझता हूं कि ईसी 2 जैसी वर्चुअल मशीन पर रेडिस चलाने के लिए प्रदर्शन दंड है, लेकिन मुझे उन लोगों से कुछ पॉइंटर्स पसंद आएंगे जिन्होंने ईसी 2 पर उत्पादन वातावरण में रेडिस तैनात किया है, जिसे आपने ईसी 2 सेटअप प्राप्त करने के लिए सबसे प्रभावी पाया है रेडिस से अधिक।

धन्यवाद।

Answer 1

ईसी 2 वर्चुअलाइज्ड हार्डवेयर पर रेडिस चलाने के लिए शायद सबसे अच्छा वातावरण नहीं है, लेकिन यह एक लोकप्रिय है, और इस मंच पर रेडिस से सर्वश्रेष्ठ प्राप्त करने के लिए कई अंक हैं।

मैं http://redis.io/topics/benchmarks और http://redis.io/topics/latency के लेखकों में से एक हूं जो नीचे दिए गए अधिकांश विषयों को कवर करता है। यह मुख्य बिंदुओं का सारांश है।

वर्चुअलाइजेशन टोल

यह EC2 के लिए विशिष्ट नहीं है, लेकिन Redis काफी धीमी जब (अधिकतम समर्थित प्रवाह की अवधि में) एक वी एम पर चल रहा है। यह बुनियादी परिचालनों के तथ्य के कारण है, रेडिस क्लाइंट कनेक्शन (जैसे memcached, या अन्य कुशल कुंजी/मूल्य स्टोर) को संभालने के लिए आवश्यक एपोल/रीड/राइट सिस्टम कॉल पर ज्यादा ओवरहेड नहीं जोड़ता है। सिस्टम कॉल आमतौर पर वीएम पर अधिक महंगे होते हैं, और वे रेडिस गतिविधि (विशेष रूप से बेंचमार्क में) के एक महत्वपूर्ण हिस्से का प्रतिनिधित्व करते हैं। उस परिस्थितियों में, नंगे धातु की तुलना में अधिकतम थ्रूपुट की अवधि में 50% की कमी असामान्य नहीं है।

बेशक, यह हाइपरवाइजर की गुणवत्ता पर भी निर्भर करता है। ईसी 2 के लिए, ज़ेन का उपयोग किया जाता है।

अच्छा शर्तों

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

वास्तव में, Redis प्रदर्शन का मूल्यांकन करने के लिए, आप की जरूरत करने के लिए:

• रन redis-बेंचमार्क स्थानीय स्तर पर (सर्वर से एक ही मशीन पर), यह मानते हुए आप एक से अधिक vCPU कोर की है।

• रन redis-बेंचमार्क दूर से (एक अलग वी एम से), एक मशीन जिसका क्यूओएस विन्यास सर्वर मशीन

तो तुम मूल्यांकन करने और मशीनों और नेटवर्क के प्रदर्शन की तुलना कर सकते हैं के समान होता है।

ईसी 2 पर, आपके पास दूसरी पीढ़ी के एम 3 इंस्टेंस (या हाई-मेमोरी, या क्लस्टर कंप्यूट इंस्टेंस) के साथ सबसे अच्छे परिणाम होंगे ताकि आप धीमे पैरा-वर्चुअलाइजेशन पर भरोसा करने के बजाय एचवीएम (हार्डवेयर वर्चुअलाइजेशन) का लाभ उठा सकें।

कांटा मुद्दा

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

कुछ मामलों में, कांटा विलंबता कई सेकंड के लिए रेडिस इवेंट लूप को फ्रीज कर सकती है। रेडिस इंस्टेंस द्वारा प्रबंधित अधिक स्मृति, अधिक विलंबता।

ईसी 2 पर, एचवीएम सक्षम इंस्टेंस (एम 3, हाई-मेमोरी, क्लस्टर) का उपयोग करना सुनिश्चित करें, इससे समस्या कम हो जाएगी।

फिर, यदि आपके पास बड़ी मेमोरी आवश्यकताएं हैं, और आपका एप्लिकेशन इसे सहन कर सकता है, तो उसी मशीन पर कई छोटे रेडिस इंस्टेंस चलाने पर विचार करें, और अपने डेटा को दाढ़ी दें। यह एक स्वीकार्य स्तर पर कांटा संचालन के कारण विलंबता को कम कर सकता है।

हठ विन्यास

यह Redis से अच्छा प्रदर्शन प्राप्त करने के लिए एक प्रमुख मुद्दा (दोनों वी एम और नंगे धातु पर) है। तो ध्यान से http://redis.io/topics/persistence

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

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

रेडिस सर्वर चलाने वाली मशीन को कभी भी स्वैप नहीं करना चाहिए। यदि ऐसा होता है, तो परिणाम विनाशकारी होगा। कुछ अन्य स्टोरों के विपरीत, रेडिस वर्चुअल मेमोरी अनुकूल नहीं है।

लिनक्स के साथ, समझदार सिस्टम पैरामीटर सेट करना सुनिश्चित करें: vm.overcommit_memory = 1 और vm.swappiness = 0 (या फिर बहुत कम मूल्य)। पुराने कर्नेल संस्करणों का उपयोग न करें: वे कम स्वैपनेस लागू करने में काफी खराब हैं (जिसके परिणामस्वरूप बड़ी फाइल लिखी जाती है)।

यदि आप एओएफ का उपयोग करते हैं, तो fsync विकल्पों की समीक्षा करें। यह कच्चे प्रदर्शन और लेखन कार्यों की स्थायित्व के बीच एक व्यापार है। आपको एक विकल्प बनाने और रणनीति को परिभाषित करने की आवश्यकता है।

आपको ईसी 2 स्टोरेज विकल्पों से परिचित होने की भी आवश्यकता है। कुछ वीएम पर, आपके पास क्षणिक भंडारण और ईबीएस के बीच विकल्प है। कुछ अन्य लोगों पर, आपके पास केवल ईबीएस है।

अस्थायी भंडारण आमतौर पर तेज़ होता है, और आपको शायद ईबीएस की तुलना में कम समस्याएं मिलती हैं, लेकिन डिस्क विफलता या होस्ट के रीबूट के मामले में आप आसानी से अपना डेटा खो सकते हैं ... आप कल्पना कर सकते हैं कि आरडीबी स्नैपशॉट्स क्षणिक भंडारण, और उसके बाद परिणामस्वरूप फ़ाइलों को ईबीएस निर्देशिकाओं में कॉपी करना, प्रदर्शन और मजबूती के बीच एक व्यापार के रूप में।

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

अंत में, ईसी 2 के साथ प्रदर्शन मांग उदाहरणों के लिए एक बहुत ही सामान्य सेटअप मास्टर पर दृढ़ता को निष्क्रिय करना है, और इसे केवल गुलाम उदाहरण पर सक्रिय करना है। यह डेटा के लिए शायद कम सुरक्षित है, लेकिन यह मास्टर पर बहुत से संभावित विलंबता मुद्दों को रोक सकता है।