स्वीकार्य लोड औसत

9

हमने शुक्रवार को अपने नए लिनक्स / एक्जिम / स्पैमाससैट मेल सर्वर को तैनात किया (हमेशा एक अच्छा विचार है कि एक लंबे सप्ताहांत से पहले दिन को तैनात करें जब कोई प्रवेश न हो)। 15 मिनट के औसत पर लोड लगभग 1.3 होवर कर रहा है।

मशीन उत्तरदायी है, और मेल उचित समय में वितरित किए जाते हैं। क्या हम मान सकते हैं कि यह स्वीकार्य है?

लोड की एक निश्चित राशि को कैसे स्वीकार्य माना जाता है या स्वीकार्य नहीं है? क्या मैट्रिक्स का उपयोग किया जाता है?

linux email

— Zimmy-डब-Zongy-Zong-DUBBY
स्रोत

3

कितने सीपीयू, कितनी रैम? क्या यह x / GDM चल रहा है?

— टिम हावलैंड

आप दैनिक आधार पर कितना मेल हैंडल करते हैं?

— बॉमगार्ट सेप

11

अंगूठे का मूल नियम: यदि सिस्टम उत्तरदायी है, यदि यह समय पर काम कर रहा है, तो आप ठीक हैं।

दो से कम भार एक चिंता का विषय नहीं है। मैंने सिस्टम को चार या पाँच मारा है और फिर भी ठीक काम करता है, हालाँकि यह एक संकेतक होगा कि नेटवर्क या ड्राइव के साथ बहुत सारे कतारबद्ध मुद्दे हैं (I / O मुद्दे सिस्टम के बहुत संवेदनशील होने के बावजूद उच्च भार का कारण बन सकते हैं)।

समय-समय पर अपने मेल कतार की लंबाई की जाँच करें और उस प्रकृति के असंदिग्ध मुद्दों और समस्याओं के लिए लॉग। यदि डिलीवरी कतार अपेक्षाकृत कम रहती है तो ठीक है।

आप डिस्क औसत और नेटवर्क I / O जानकारी प्राप्त करने के साथ बहुत कुछ कर सकते हैं, लेकिन यदि आप वितरण समस्या नहीं देख रहे हैं (मैंने पंद्रह मिनट पहले संदेश भेजा था और यह अभी तक नहीं आया है!) और आप कंसोल के माध्यम से सिस्टम पर काम कर सकते हैं। या ssh) बहुत विलंबता के बिना, आपको ठीक होना चाहिए।

— बार्ट सिल्वरस्ट्रिम
स्रोत

18

लोड औसत एक ऐसा मूल्य है जो कर्नेल द्वारा आवश्यक प्रोसेसर की संख्या का एक विचार देता है जब वे प्रतीक्षा किए बिना सभी कार्य को चलाने में सक्षम हो।
आपके मामले में, यदि आपके पास 2 या अधिक सीपीयू / कोर है। कोई समस्या नहीं है। यदि आपके पास 1 कोर वाला केवल 1 सीपीयू है तो इसका मतलब है कि आपके ऐप को चलाने के समय और कर्नेल को चलाने के समय के बीच 'बहुत अधिक' समय है। एक लोड> "सीपीयू / कोर की संख्या" एक मेल सिस्टम के लिए एक समस्या नहीं होगी जब तक कि यह बहुत लंबे समय तक बहुत अधिक मूल्य तक न पहुंच जाए।
बेशक वे देने के लिए कोई नियम और मूल्य नहीं है और जब आप अपना मेल थोड़े समय में प्राप्त करते हैं तो यह ठीक है। लेकिन आपको संभवतः अपने सर्वर पर बारीकी से देखना शुरू करना होगा जब लोड 'लंबे' अवधि (~ 1 घंटे) के लिए अक्सर सीपीयू / कोर की 2 * संख्या से अधिक हो।
फिर से एक मेल सर्वर के लिए यह एक बड़ी समस्या नहीं होगी, लेकिन इसका मतलब यह होगा कि आप सर्वर थोड़ा ओवरलोडेड हैं।

— त्रिज्या
स्रोत

+1 महान और दिलचस्प सामान!

— मार्को Demaio

3

मैं एक बहुत अच्छे वेबपेज के लिए एक लिंक जोड़ता हूं blog.scoutapp.com/articles/2009/07/31/…

— त्रिज्या

3

ट्यूनिंग से संबंधित प्रश्नों के साथ हमेशा की तरह हाँ / कोई उत्तर नहीं है, यह सब निर्भर करता है :-)

कहा जा रहा है कि, 1.3 का लोड अधिक नहीं लगता है, खासकर यदि आपके पास मल्टी-कोर सीपीयू कॉन्फ़िगरेशन है। यदि लोड संख्या कोर की संख्या के समान है, तो सभी कोर हमेशा एक प्रक्रिया को चलाने के लिए तैयार हैं।

अंततः, यदि, जैसा कि आप कहते हैं, संदेशों को समय पर वितरित किया जा रहा है तो प्रदर्शन ठीक है :-)

top

आपको पर्याप्त वास्तविक समय के पास बुनियादी मैट्रिक्स देगा।

— डॉ जनवरी
स्रोत

3

htop और भी बेहतर और पढ़ने में आसान है

— Antoine Benkemoun

3

एक लोड औसत cpu की संख्या से कम है जिसका मतलब है कि आपके पास कुछ करने के लिए cpu बैठे हैं। समान का मतलब है कि वे इस समय काम कर रहे हैं। ग्रेटर का मतलब है कि ऐसी प्रक्रियाएं हैं जो चल सकती हैं, लेकिन लाइन की प्रतीक्षा में फंस गई हैं।

एक वीओआइपी सर्वर या मेम्चे जैसे सुपर टाइम संवेदनशील सामान के लिए आप चाहते हैं कि आपके लोड को अच्छी तरह से कोर की संख्या के नीचे होना चाहिए। अतुल्यकालिक सामान के लिए जो सामयिक बैकअप के साथ रह सकते हैं (ईमेल की तरह) आप आसानी से कोर की संख्या 4x चला सकते हैं।

याद रखने के लिए सबसे बड़ी चेतावनी यह है कि डिस्क या नेटवर्क i / o की प्रतीक्षा कर रहे हैं, लेकिन अन्यथा रनवेबल अभी भी लोड औसत में दिखाई देते हैं। इसलिए यदि आपको 56k उपयोगकर्ताओं के लिए एपीके सर्वर स्पोंडफीडिंग jpg मिल गया है, तो आप अगर आप इसे पीछे से फायरिंग कर रहे हैं तो इसकी तुलना में अधिक लोड औसत चला सकते हैं। आपके मामले में एक अटैचमेंट को ट्रांसफर करने के लिए हमेशा के लिए ले जाने वाले कुछ धीमी मेल करने वालों के लिए एक smtp कनेक्शन रन-कतार पर 1 प्रक्रिया दिखाएगा, लेकिन बिना किसी मुद्दे के जीमेल के लिए एक त्वरित वन-लाइनर ईमेल भेजने के लिए बीस बार बाधित हो सकता है।

धक्का को धक्का आता है, लोड औसत डॉव की तरह होता है। यह वास्तव में किसी भी तरह से "अर्थव्यवस्था" को मापता नहीं है, लोग इसका इस्तेमाल बहुत ही आसानी से सहसंबद्ध मेट्रिक क्यूज़ के रूप में करते हैं जो इसके बारे में बात करना आसान है। आपके द्वारा वास्तव में परवाह किए जाने वाले निगरानी मैट्रिक्स पर ध्यान केंद्रित करें, जैसे कि डिलीवरी कतार की गहराई और संदेश प्रति सेकंड।

— cagenut
स्रोत

2

आपके पास कितने कोर हैं? cat / proc / cpuinfo | grep प्रोसेसर | wc -l

(चेतावनी: हाइपरथ्रेडिंग अधिक कोर जैसा दिखता है, लेकिन ऐसा नहीं है)

यदि आपका लोड स्तर आपके प्रोसेसर की गिनती के अंतर्गत है, तो आप आमतौर पर ठीक हैं।

इसके अलावा शीर्ष पर एक नज़र डालें और '1' को हिट करें और आप प्रत्येक सीपीयू का अलग-अलग लोड देख सकते हैं।

— जोएल के
स्रोत

1

हाँ, यह बहुत स्वीकार्य है, और आम तौर पर एक मेल फिल्टर के साथ उम्मीद की जानी चाहिए।

हमारा सेटअप थोड़ा अलग है। हमारे पास SpamAssassin के लिए एक अलग सर्वर है, जबकि हमारा POP सर्वर वायरस के लिए स्कैन करने के लिए ClamAV चलाता है। पीओपी सर्वर आम तौर पर 2 के सर्वर लोड के तहत चल रहा है, लेकिन कभी-कभी 10 या अधिक तक स्पाइक्स होता है। दूसरी ओर हमारा SpamAssassin सर्वर 2 के आसपास तब तक चलता था, जब तक कि हम Openprotect.com फ़िल्टर स्थापित नहीं कर लेते, जब यह CPU उपयोग को दोगुना कर देता है और अब 5 से ऊपर स्पाइक्स के साथ लगभग 5 से नीचे चल रहा है। यह अभी भी स्वीकार्य है क्योंकि हम नहीं मेल में किसी भी तरह की देरी होती है जिसके परिणामस्वरूप मेल की कतार बढ़ती है (हम आने वाली SMTP के लिए qmail का उपयोग करते हैं), और CPU उपयोग / मेमोरी वार को खाली करने के लिए अभी भी जगह है।

संयोग से, मैं आपके सर्वर की निगरानी के लिए मुनिन को बहुत सलाह देता हूं । यह नेत्रहीन ऐतिहासिक डेटा को प्रदर्शित करने और आपको दिखाने के लिए कि आपको किन संसाधनों को छोड़ना है। शीर्ष (1) के साथ वास्तविक समय में निगरानी आपको अधिक मदद नहीं करती है। :)

ओह, और वैसे, लंबे सप्ताहांत से पहले शुक्रवार को तैनात करना पूरे सप्ताहांत के माध्यम से काम करने का एक शानदार तरीका है। खासतौर पर मेल सर्वर जैसे क्रिटिकल सिस्टम के लिए।

— एर्नी
स्रोत

यहां भी देखें collectd, जैसा कि यहां बताया गया है: serverfault.com/questions/67234/…

— वॉरेन

0

कैसे स्मृति comsumption है? यह स्थिर है या बढ़ रहा है?

लोड आदर्श से बाहर नहीं लगता है। यदि मेल सर्वर उत्तरदायी है, और मेल के माध्यम से जा रहा है मैं कहूँगा कि मेमोरी की खपत से परे विफलता का एकमात्र माप होगा यदि गलत ईमेल (स्पैम) के माध्यम से हो रहा है।

आज आप अपना पहला वास्तविक परीक्षण करेंगे। मैं शायद आज हल्के से इसकी निगरानी करूंगा। अगर कुछ गलत हो रहा है, तो अब समय होगा।

— Highstead
स्रोत