ऑपरेटिंग सिस्टम, स्थायी सेवाओं और वास्तविक समवर्तीता के लिए हेडरूम के साथ मेमोरी चुनें। यह मापने के बाद CPU चुनें कि कौन से कार्य व्यस्त हैं, क्या वे समानांतर चलते हैं और उपयोगकर्ताओं को वास्तव में कौन सी देरी का अनुभव होता है।
सामान्य कार्य और व्यस्त कार्य को अलग-अलग वर्णित करें
अकेले आगंतुक संख्या एक कमजोर साइज़िंग इनपुट है। एक अनुरोध कैश की गई फ़ाइल परोस सकता है जबकि दूसरा रिपोर्ट बनाता है या कई तालिकाओं को क्वेरी करता है। उन वेब वर्कर, डेटाबेस, कैश, कतार उपभोक्ताओं और रखरखाव कार्यों की सूची बनाएं जो VPS साझा करेंगे। सामान्य समवर्तीता और सबसे व्यस्त अपेक्षित ऑपरेशन का वर्णन करें। निर्धारित निर्यात, पैकेज अपडेट और तैनाती को अदृश्य पृष्ठभूमि गतिविधि मानने के बजाय शामिल करें।
मौजूदा प्रोजेक्ट के लिए, एक व्यस्त विंडो सहित एक प्रतिनिधि अवधि एकत्र करें। संसाधन उपयोग के साथ-साथ प्रतिक्रिया समय और त्रुटियाँ रिकॉर्ड करें। नए प्रोजेक्ट के लिए, वास्तविक अनुरोध आकार और डेटा आकार के साथ एक छोटा परीक्षण बनाएं। आपका प्रारंभिक अनुमान अपूर्ण होगा; उपयोगी लक्ष्य एक प्रलेखित प्रारंभिक बिंदु है जिसकी तुलना आप डिलीवरी के बाद मापे गए व्यवहार से कर सकें।
प्रक्रियाएँ जोड़ने से पहले मेमोरी बजट बनाएं
मेमोरी की मांग सिस्टम, स्थायी एप्लिकेशन सेवाओं, प्रति-वर्कर उपयोग और अस्थायी संचालन से आती है। किसी वर्कर के फुटप्रिंट को नियोजित समवर्तीता से गुणा करना एक मोटा योजना उपकरण है, गारंटी नहीं, क्योंकि साझा मेमोरी और कैश कुल को जटिल बनाते हैं। लोड के तहत वास्तविक प्रक्रियाओं का निरीक्षण करें। पर्याप्त जगह छोड़ें ताकि कोई रखरखाव कार्य एप्लिकेशन को हर शेष पृष्ठ के लिए प्रतिस्पर्धा करने पर मजबूर न करे।
डेटाबेस सेटिंग्स अप्रत्याशित रूप से मेमोरी उपयोग को कई गुना बढ़ा सकती हैं। PostgreSQL दस्तावेज़ करता है कि work_mem क्वेरी संचालनों पर लागू होता है, और कई संचालन या सत्र एक साथ चल सकते हैं। इसलिए अलगाव में मामूली दिखने वाली सेटिंग का सिस्टम पर बड़ा प्रभाव हो सकता है। अपने डेटाबेस का स्वयं का मार्गदर्शन पढ़ें, वास्तविक समवर्तीता का परीक्षण करें और हर विज्ञापित गीगाबाइट को एक कैश को न सौंपें।
CPU उपयोग को उपयोगी समानांतरता से अलग करें
प्रोसेसर गणना बताती है कि गेस्ट को कितने निष्पादन संसाधन प्रस्तुत किए जाते हैं, यह नहीं कि आपका सॉफ़्टवेयर उन्हें कितने कुशलता से उपयोग कर सकता है। एक व्यस्त थ्रेड एप्लिकेशन को सीमित कर सकता है जबकि अन्य कोर शांत रहते हैं। वर्कर जोड़ना स्वतंत्र अनुरोधों में मदद कर सकता है, लेकिन यह डेटाबेस विवाद और मेमोरी मांग को भी बढ़ा सकता है। यह मानने से पहले कि दोगुनी कोर संख्या दोगुना थ्रूपुट उत्पन्न करती है, एप्लिकेशन के समवर्तीता मॉडल की जाँच करें।
KVM आभासी मशीनों को उनका स्वयं का आभासी हार्डवेयर प्रदान करता है। यह हर vCPU लेबल को होस्ट और प्रोसेसर पीढ़ियों में समान बेंचमार्क में नहीं बदलता। जहाँ उपलब्ध हो वहाँ सूचीबद्ध CPU मॉडल और आवंटन शर्तों की तुलना करें, फिर अपने स्वयं के वर्कलोड के साथ सेवा का मूल्यांकन करें। एक छोटे सिंथेटिक स्कोर से खरीदारी निष्कर्ष निकालने से बचें जो एप्लिकेशन जैसा नहीं है।
केवल औसत नहीं, दबाव और प्रतीक्षा देखें
एक सिस्टम उच्च औसत CPU प्रतिशत बनाए बिना धीमा महसूस हो सकता है। प्रक्रियाएँ स्टोरेज, मेमोरी पुनर्प्राप्ति या किसी अन्य सेवा पर प्रतीक्षा कर सकती हैं। Linux कर्नेल की Pressure Stall Information समर्थित सिस्टम पर CPU, मेमोरी और I/O स्टॉल जानकारी उजागर करती है। ये संकेत सामान्य उपयोग मेट्रिक्स और एप्लिकेशन समय के साथ संसाधन विवाद की पहचान करने में मदद कर सकते हैं।
मेट्रिक्स को एक साथ पढ़ें। लगातार मेमोरी दबाव, स्वैपिंग, विफल आवंटन और धीमे अनुरोध एक व्यस्त कंप्यूट वर्कर से अलग हस्तक्षेप की ओर इशारा करते हैं। स्टोरेज प्रतीक्षा क्वेरी परिवर्तन या भिन्न डिस्क प्रोफ़ाइल को उचित ठहरा सकती है। बाहरी API विलंब को स्थानीय RAM जोड़कर ठीक नहीं किया जाएगा। यह चुनने से पहले कि किस संसाधन को बढ़ाना है, देखी गई बाधा की व्याख्या करें।
| देखा गया व्यवहार | जाँचने योग्य प्रश्न | संभावित अगला कदम |
|---|---|---|
| एक थ्रेड व्यस्त, अतिरिक्त कोर शांत | क्या यह कार्य समानांतर चल सकता है? | कार्य में सुधार करें या वर्कर डिज़ाइन बदलें |
| रिपोर्ट के दौरान मेमोरी दबाव | कितने संचालन ओवरलैप होते हैं? | समवर्तीता सीमित करें या परीक्षित हेडरूम जोड़ें |
| I/O प्रतीक्षा के साथ धीमे अनुरोध | कौन से पढ़ने या लिखने में देरी हो रही है? | क्वेरी और स्टोरेज व्यवहार का निरीक्षण करें |
| CPU और मेमोरी कम, अनुरोध धीमे | क्या कोई निर्भरता प्रतिक्रियाओं में देरी कर रही है? | डाउनस्ट्रीम कॉल मापें |
स्पष्ट धारणाओं के साथ एक योजना उदाहरण
दो वेब वर्कर, एक डेटाबेस और एक कतार उपभोक्ता वाले एक छोटे एप्लिकेशन की कल्पना करें। टीम सामान्य अनुरोधों और एक रिपोर्ट-निर्माण कार्य के दौरान उन सेवाओं को मापती है। यह पाती है कि एक साथ चार रिपोर्ट की अनुमति देने से सामान्य ट्रैफ़िक में देरी होते हुए मेमोरी मांग तेजी से बढ़ती है। तुरंत सबसे बड़ा प्लान खरीदने के बजाय, यह रिपोर्ट समवर्तीता को सीमित करती है और परिणाम को फिर से मापती है।
यदि समायोजित वर्कलोड को अभी भी अधिक मेमोरी की आवश्यकता है, तो अपग्रेड अब एक देखी गई आवश्यकता का उत्तर देता है। यदि कतार CPU-बाध्य रहती है और स्वतंत्र कार्य समानांतर चल सकते हैं, तो अधिक निष्पादन संसाधन उपयुक्त हो सकते हैं। ये उदाहरण निर्णय हैं, SwissOctet प्लान के लिए प्रदर्शन आंकड़े नहीं। अपने स्वयं के माप और बाधाएँ चुने गए कॉन्फ़िगरेशन के साथ रखें।
अगले माप के लिए एक स्पष्ट पथ छोड़ें
समीक्षा शुरू करने वाले संकेत तय करें: प्रतिक्रिया समय में गिरावट, बार-बार मेमोरी दबाव, बढ़ती कतारें या बदला हुआ कार्यभार। निगरानी को इतना हल्का रखें कि वह नई बाधा न बने। किसी सुविधा या बड़े डेटासेट को जोड़ने के बाद पुनर्मूल्यांकन करें, और जब असली समस्या अनियंत्रित प्रक्रिया या धीमी क्वेरी हो तो बार-बार अपग्रेड से बचें।
SwissOctet के VPS परिवार CPU और मेमोरी विशिष्टताएँ तथा चयनित संसाधन विकल्प दिखाते हैं। अतिरिक्त विकल्प जोड़ने के बाद अंतिम कॉन्फ़िगरेशन पढ़ें, जिसमें बिलिंग अवधि और कुल राशि शामिल हो। अपग्रेड व्यवस्थाओं पर भरोसा करने से पहले उन्हें लाइव ऑपरेटर के साथ पुष्ट करें। उपयोगी VPS आकार वह है जो मापे गए कार्यभार को उचित हेडरूम और समझने योग्य अगले कदम के साथ चलाता है।
आपकी व्यावहारिक चेकलिस्ट।
- सेवाओं और रखरखाव कार्य की सूची बनाएँ।
- सामान्य और व्यस्त अवधि की समवर्तीता मापें।
- स्थायी और अस्थायी मेमोरी का बजट बनाएँ।
- जाँचें कि क्या CPU कार्य समानांतर में चल सकता है।
- दबाव, उपयोग और अनुप्रयोग समय की तुलना करें।
- तय करें कि कॉन्फ़िगरेशन की समीक्षा कब करनी है।
महत्वपूर्ण विवरण।
क्या मुझे VPS का आकार मासिक विज़िटर के आधार पर तय करना चाहिए?+
विज़िटर संख्या को संदर्भ के रूप में लें, फिर अनुरोध की जटिलता, समवर्तीता, डेटा आकार और पृष्ठभूमि कार्य मापें। समान विज़िटर संख्या अलग-अलग लोड बना सकती है।
क्या अधिक RAM से सेवा हमेशा तेज़ होती है?+
नहीं। यह तब मदद करता है जब मेमोरी बाधा हो या उपयोगी कैशिंग संभव हो, लेकिन यह हर CPU, स्टोरेज या बाहरी निर्भरता की देरी को दूर नहीं करता।
क्या दोगुने vCPU से प्रदर्शन दोगुना हो जाता है?+
नहीं। समानांतरता, प्रोसेसर की विशेषताएँ, प्रतिस्पर्धा और अनुप्रयोग का डिज़ाइन तय करते हैं कि अतिरिक्त क्षमता कितनी उपयोगी है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Linux कर्नेल: प्रेशर स्टॉल सूचना docs.kernel.org
- PostgreSQL: संसाधन खपत www.postgresql.org
- KVM परियोजना: कर्नेल वर्चुअल मशीन www.linux-kvm.org
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।