रिक्वेस्ट ड्रॉप्स के कारण रिस्पॉन्स टाइम विस्फोट क्यों होता है?

Question

---

सुधार : प्रतिक्रिया समय ( %D) μs नहीं एमएस है! 1

यह इस पैटर्न की अजीबता के बारे में कुछ भी नहीं बदलता है लेकिन इसका मतलब है कि यह व्यावहारिक रूप से कम विनाशकारी है।

---

फ्रीक्वेंसी अनुरोध करने के लिए रिस्पांस टाइम व्युत्क्रम से क्यों जुड़ा है?

जब सर्वर कम व्यस्त हो तो रिस्पॉन्स रिक्वेस्ट कम नहीं होनी चाहिए?

कोई भी सुझाव कि अपाचे को कम भार के "लाभ" कैसे लें?

यह पैटर्न आवधिक है। इसका मतलब है कि यह तब दिखाई देगा जब इंप्रेशन लगभग 200 अनुरोध प्रति मिनट से कम हो जाता है - जो कि (प्राकृतिक उपयोगकर्ता-गतिविधि के कारण) देर रात से सुबह तक होता है।

---

अनुरोध बहुत ही सरल POST हैं जो 1000 से कम वर्णों का JSON भेजते हैं - यह JSON संग्रहीत है (पाठ फ़ाइल में जोड़ा गया है) - यह बात है। जवाब सिर्फ "-" है।

ग्राफ में दिखाया गया डेटा अपाचे के साथ ही लॉग किया गया था:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

Comments

क्या यह संभव है कि कोई चीज कैश प्रेशर का कारण बन रही है, और परिणामस्वरूप यह डिस्क से चीजों को रीफ़्रेश करना है? डिस्क गतिविधि क्या दिखती है?

— TLW

क्या यह अनुरोध प्रति मिनट आ रहा है या अनुरोध प्रति मिनट नियंत्रित किया जाता है ?

— user253751

इस डेटा को रिकॉर्ड और प्लॉट करने के लिए आपने किस सॉफ्टवेयर का उपयोग किया? वास्तव में जिज्ञासु

— Délisson Junio

@wingleader: Apache2 के साथ रिकॉर्ड किया गया और

— Raffael

@immibis: लॉग कॉन्फ़िगरेशन देखें जो मैंने जोड़ा है - मुझे लगता है कि यह "आगमन" है

— राफेल

Answer 1

यह डेटा केंद्रों में सामान्य व्यवहार है। आपकी प्रतिक्रिया का समय धीमा होने से संबंधित है जिसे आमतौर पर बैच विंडो कहा जाता है। यह एक ऐसा समय है जब उपयोगकर्ता गतिविधि कम होने की उम्मीद है और बैच प्रक्रियाओं को चलाया जा सकता है। इस दौरान बैकअप भी किया जाता है। ये गतिविधियाँ सर्वर और नेटवर्क के संसाधनों को प्रभावित कर सकती हैं, जिससे प्रदर्शन की समस्याएँ जैसे आप देखते हैं।

कुछ संसाधन हैं जो समस्याएँ पैदा कर सकते हैं:

• उच्च CPU लोड। यह अनुरोध को संसाधित करने के लिए समय स्लाइस के लिए प्रतीक्षा करने के लिए अपाचे का कारण बन सकता है।
• उच्च स्मृति उपयोग। यह बफ़र्स को फ्लश कर सकता है जो अपाचे को डिस्क से पढ़ने के बिना संसाधनों की सेवा करने में सक्षम बनाता है। यह अपाचे श्रमिकों के पेजिंग / स्वैपिंग का कारण भी बन सकता है।
• उच्च डिस्क गतिविधि। इससे डिस्क I / O गतिविधि को सेवा सामग्री में संबंधित देरी के साथ कतारबद्ध किया जा सकता है।
• उच्च नेटवर्क गतिविधि। इससे पैकेट को ट्रांसमिशन के लिए कतार में खड़ा किया जा सकता है, रिट्रीट को बढ़ाया जा सकता है और अन्यथा सेवा को ख़राब कर सकता है।

मैं sarइस तरह से जारी जांच का उपयोग करता हूं । दैनिक डेटा फ़ाइलों में डेटा atsarएकत्र करने के लिए इस्तेमाल किया जा सकता है sar। यह देखने के लिए जांच की जा सकती है कि प्रदर्शन के सामान्य होने पर दिन के दौरान सिस्टम का व्यवहार कैसा होता है, और प्रदर्शन के परिवर्तनशील होने पर उसे ओवरनाइट कर दिया जाता है।

यदि आप सिस्टम muninया किसी अन्य प्रणाली के साथ निगरानी कर रहे हैं जो संसाधन उपयोग को इकट्ठा और रेखांकन करता है, तो आपको वहां कुछ संकेतक मिल सकते हैं। मुझे अभी भी sarअधिक सटीक लगता है ।

वहाँ की तरह उपकरण हैं niceऔर ioniceहै कि उनके प्रभाव को कम करने के लिए बैच प्रक्रियाओं के लिए लागू किया जा सकता है। वे केवल सीपीयू या आई / ओ मुद्दों के लिए प्रभावी हैं। वे मेमोरी या नेटवर्क गतिविधि के साथ मुद्दों को हल करने की संभावना नहीं है।

बैकअप गतिविधि को एक अलग नेटवर्क में ले जाना और नेटवर्क विवाद को कम करना। उपयोग किए जाने वाले बैंडविड्थ को सीमित करने के लिए कुछ बैकअप सॉफ़्टवेयर को कॉन्फ़िगर किया जा सकता है। यह नेटवर्क विवाद को हल कर सकता है।

बैच प्रक्रियाओं को कैसे ट्रिगर किया जाता है इसके आधार पर आप समानांतर में चलने वाली बैच प्रक्रियाओं की संख्या को सीमित करने में सक्षम हो सकते हैं। यह वास्तव में बैच प्रक्रियाओं के प्रदर्शन में सुधार कर सकता है क्योंकि वे समान संसाधन विवाद का सामना कर रहे हैं।

Comments

एक लिंक sarउपयोगी हो सकता है। मुझे यह एक मिला: en.wikipedia.org/wiki/Sar_(Unix)

— रोजर लिप्सकॉम्ब

यह न केवल बैकअप हो सकता है, वीएम प्रदाता ऊर्जा की बचत करने के लिए कुछ रैक से बिजली में एक ही मशीन से अधिक वीएम को स्थानांतरित कर सकते हैं (या वास्तव में, उन्हें बैच कार्यों के लिए समर्पित कर सकते हैं)

— जेन्स टिम्मरमैन

Answer 2

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

या यह आपके माप की एक कलाकृति हो सकती है - यदि ऊपर दिया गया ग्राफ़ पूर्ण अनुरोधों को दिखाता है , तो आने वाले अनुरोधों के विपरीत , दर अनुरोध के बढ़ने के समय कम हो जाएगी।

Comments

बेशक यह सिर्फ संभावित कारणों की सतह को खरोंच रहा है, लेकिन शुरुआती समस्या बयान देखने के लिए बहुत कुछ नहीं देती है। क्या यह प्रक्रिया कुछ और बात करती है? यह किस प्रकार के अनुरोध करता है? क्या समय के साथ कार्यभार बदल जाता है? और इसी तरह ....

— करोल नैक

दिलचस्प परिप्रेक्ष्य लेकिन लक्षणों की आवधिकता और अवधि के साथ अच्छी तरह से नहीं जाता है

— राफेल

Answer 3

हालांकि @ BillThor का जवाब सही हो सकता है, यह संभावना कम लगती है कि कम लोड की अवधि पूरी तरह से बैकअप प्रक्रियाओं द्वारा ली गई है (यानी कि अवधि ठीक मेल खाती है)।

एक वैकल्पिक स्पष्टीकरण बस कैशिंग है। यदि किसी दी गई स्क्रिप्ट / डेटाबेस / जो हाल ही में उपयोग नहीं किया गया है, तो शेष ऑपरेटिंग सिस्टम के लिए मेमोरी को खाली करने के लिए प्रासंगिक कैश्ड डेटा को गिरा दिया गया हो सकता है। यह किसी डेटाबेस, या O / S बफ़र्स पर फ़ाइल, या किसी अन्य चीज़ के संबंध में अनुक्रमित हो सकता है। एक क्वेरी तब इस जानकारी को पुनर्गठित करने जा रही है यदि यह अंतिम क्वेरी के बाद से कुछ समय के लिए है। व्यस्त अवधियों में यह घटित नहीं होगा क्योंकि अंतिम क्वेरी अक्सर होती थी। यह यह भी समझाएगा कि आप व्यस्त अवधि के दौरान कम प्रतिक्रिया समय और उच्च प्रतिक्रिया समय क्यों देख रहे हैं ।

Comments

खासकर अगर क्वेरी कैशिंग, और / या डिस्क एक्सेस कैशिंग शामिल हैं। एक तरफ के रूप में अगर कोई भी "थ्रेड री-यूज" रणनीति है, जो भी मदद करता है।

— मैकेंज़म

इसमें किसी तरह की कोई रीडिंग शामिल नहीं है।

— राफेल

@ राफेल मुझे बहुत संदेह है कि आप गारंटी दे सकते हैं "इसमें किसी भी तरह का कोई पढ़ना शामिल नहीं है"। एक तुच्छ स्तर पर, मान लीजिए कि अपाचे के पृष्ठ बाहर हैं क्योंकि कुछ और राम चाहते थे? मान लीजिए कि अपाचे के लिए आपके एमपीएम ने थ्रेड्स / प्रक्रियाओं की संख्या कम कर दी है, जबकि चीजें बेकार हैं और नए बनाने में ओवरहेड है? क्या आप गंभीरता से कह रहे हैं कि यदि आप straceअपाचे प्रक्रिया पर चलते हैं, तो आपको कोई read()सिस्टम कॉल या समान दिखाई नहीं देता है? यह बहुत असामान्य होगा।

— abligh

@ साभार: ठीक है, ठीक है, मेरी "सेवा" स्पष्ट रूप से डिस्क से कुछ भी पढ़ने को लागू नहीं करता है

— राफेल

@ राफेल यदि आप ओएस कैशिंग (केवल) के प्रभाव का परीक्षण करना चाहते हैं, तो एक व्यस्त अवधि के दौरान echo 3 > /proc/sys/vm/drop_cachesहर 5 सेकंड में एक मिनट के लिए करें और देखें कि क्या आपको प्रतिक्रिया समय पर समान प्रभाव मिलते हैं।

— अबूझ जूल 21'16

Answer 4

आप जो देख रहे हैं, वह मेरे लिए है, जैसे कि यह एक सांख्यिकीय मुद्दा हो सकता है। यह नहीं हो सकता है, @ बिलचोर का उत्तर सही हो सकता है, लेकिन मैं इसे पूर्णता के लिए पोस्ट करूंगा।

प्रतिक्रिया समय का ग्राफ प्रतिशत आधारित है। 800-1000 अनुरोधों का एक नमूना पूल इसके लिए एक अच्छा नमूना गणना है, 50-100 अनुरोधों का एक पूल शायद इतना नहीं है।

यदि आप मानते हैं कि धीमे अनुरोधों की संख्या अनुरोध मात्रा का रैखिक कार्य नहीं है, जैसे कि अनुरोधों में परिमाण में वृद्धि के कारण धीमी गति से अनुरोधों में परिमाण में वृद्धि होती है, तो उच्चतर अनुरोधों का परिणाम होगा कम औसत अनुरोध समय।

Comments

यदि अवलोकन केवल 50 से 100 अनुरोधों से युक्त था, तो वास्तव में यह केवल यादृच्छिकता हो सकती है, लेकिन यदि आप ग्राफ को देखेंगे तो आप देखेंगे कि हम 60 x 5 प्रयोगों के बारे में बात कर रहे हैं, जिनमें से प्रत्येक में लगभग 50 से 100 अनुरोध शामिल हैं - यह निश्चित रूप से पर्याप्त है बेतरतीबी से शासन करें। इसके अलावा अगर आप करीब से देखें तो आपको स्थिर मतलब 50 वाँ प्रतिशत दिखाई देगा जो लगभग 2500 मी।

— राफेल

जरूरी नहीं, यह काफी हद तक इस तरह के आँकड़े थोक में व्यवहार नहीं करते हैं। उदाहरण के लिए, 1 घंटे में 1000 अनुरोध और 1 मिनट से अधिक 1000 अनुरोध समान व्यवहार नहीं करेंगे। यहाँ भी शायद नहीं हो रहा है। छोटे नमूना आकार अजीब व्यवहार करते हैं, इस मामले में यह 60x5 नमूना सेट की तरह अधिक है। पैटर्न गैर-रैखिक लोडिंग का परिणाम हो सकता है।

— २१:१३ पर कैथार

Answer 5

झूठ, बड़े झूठ और आंकड़े हैं।

मेरी परिकल्पना: आपको अनुरोधों की तीन अलग-अलग श्रेणियां मिली हैं:

1. सामान्य परिवर्तनशील धारा जिसमें अधिकांश अनुरोध होते हैं और ये सभी 200-300 μs के भीतर पूरी होती हैं।
2. प्रति मिनट (रात में भी) लगभग 20 अनुरोधों की एक स्थिर दर पर छोटी धारा। प्रत्येक को पूरा करने के लिए लगभग 2.500 μs लगते हैं।
3. लगभग 10 अनुरोधों की निरंतर दर पर प्रति मिनट (रात में भी)। प्रत्येक 4.000 μs से ऊपर ले जाता है।

रात में, प्रति मिनट 50 अनुरोध 20 + 20 + 10 हैं। और इसलिए, 50% पर्सेंटाइल का परिणाम अब दृढ़ता से स्ट्रीम 2 के परिणाम पर निर्भर करता है। और 95% पर्सेंटाइल स्ट्रीम 3 पर निर्भर करता है, इसलिए यह ग्राफ पर भी कभी नहीं दिखा सकता है।

दिन के दौरान, धारा 2 + 3 95% प्रतिशत के ऊपर अच्छी तरह से छिपी हुई हैं।

Comments

धारा के साथ क्या मतलब है? अनुरोध बिल्कुल समरूप हैं, जबकि अनुरोध करने वाले ग्राहक बिल्कुल विषम हैं।

— राफेल

Answer 6

जितना अधिक मैं इसे देखता हूं, उतना ही मैं यह सोचने के लिए इच्छुक हूं कि डेटा संग्रह में कोई समस्या है।

सबसे पहले, आपके TPS के साथ वास्तव में कुछ अजीब चल रहा है। जबकि समग्र पैटर्न सामान्य दिखता है, लगभग 9pm पर एक बहुत तेज ब्रेक होता है, और फिर लगभग 7 बजे। ऑफ-पीक घंटों के लिए संक्रमण के दौरान एक सामान्य चार्ट बहुत चिकना होगा।

इससे पता चलता है कि प्रोफ़ाइल में एक परिवर्तन है, और आपके पास संभवतः 2 अलग प्रकार के ग्राहक हैं:

1. एक जो केवल 7am (ish) और 9pm (ish) के बीच, उच्च मात्रा में, और के बीच संचालित होता है
2. एक और जो संभवतः कम मात्रा में, घड़ी के आसपास संचालित होता है।

दूसरा संकेत 18:00 के आसपास है। अधिकांश समय से पहले और बाद में, हमारे पास उच्च मात्रा प्रोफ़ाइल है - उच्च टीपीएस और कम विलंबता। लेकिन लगभग 18:00 बजे अचानक 800-1000 RPM से 400 RPM से कम हो जाती है। संभवतः इसका क्या कारण हो सकता है?

तीसरा संकेत 5-प्रतिशतक प्रतिक्रिया समय में चरण-नीचे है। मैं वास्तव में दो कारणों से न्यूनतम प्रतिक्रिया समय (लेकिन 5 वाँ प्रतिशत बेहतर है) देखना पसंद करता हूं: यह मुझे सेवा समय (यानी प्रतिक्रिया समय शून्य से कम) बताता है , और प्रतिक्रिया समय एक वीबुल वितरण का अनुसरण करता है, जिसका अर्थ है कि मोड (या सबसे सामान्य मूल्य) न्यूनतम से ऊपर है।

इसलिए 5 वें प्रतिशत में चरण-दर-चरण मुझे कहता है कि श्रृंखला में अचानक ब्रेक है, और सेवा समय वास्तव में गिरा दिया गया है, हालांकि दोनों विचरण और औसत प्रतिक्रिया समय में बहुत वृद्धि हुई है।

अगला कदम

इस स्तर पर मैं लॉग में एक गहरा गोता लगाने के लिए पता लगाऊंगा कि पहले और बाद में उच्च-मात्रा के नमूनों की तुलना में 18:00 कम मात्रा के नमूनों के बारे में क्या अलग है।

मैं देखूंगा:

• भौगोलिक स्थिति में अंतर (मामले में विलंबता $ request_time को प्रभावित कर रही है)
• URL में अंतर (कोई भी नहीं होना चाहिए)
• HTTP विधि (POST / GET) में अंतर (कोई नहीं होना चाहिए)
• एक ही आईपी से बार-बार अनुरोध
• और किसी भी अन्य मतभेद ...

BTW, 18:00 "घटना" मेरे लिए पर्याप्त सबूत है कि यह डेटा सेंटर भीड़ / गतिविधि से कोई लेना-देना नहीं है। यह सच है कि भीड़ के कारण, TPS में एक गिरावट का कारण होगा, जो 18:00 पर संभव है, लेकिन 9:00 और 7 बजे के बीच 10 घंटे के लिए TPS में एक निरंतर, और सुचारू रूप से घुमावदार ड्रॉप होने की संभावना नहीं है।