অনুরোধের ফ্রিকোয়েন্সি হ্রাস পেলে প্রতিক্রিয়া সময় কেন বিস্ফোরিত হয়?

Question

---

সংশোধন : প্রতিক্রিয়া সময় ( %D) হয় না এমএস! 1

এটি এই প্যাটার্নের অদ্ভুততা সম্পর্কে কিছুই পরিবর্তন করে না তবে এর অর্থ এটি কার্যতভাবে কম ধ্বংসাত্মক।

---

প্রতিক্রিয়া সময় ব্যর্থতার অনুরোধের সাথে বিপরীতভাবে সম্পর্কযুক্ত কেন?

কম ব্যস্ততা হ্যান্ডলিংয়ের অনুরোধ করলে সার্ভারের দ্রুত প্রতিক্রিয়া করা উচিত নয়?

কীভাবে কম চাপের সাথে অ্যাপাচি "সুবিধা" নেওয়ার কোনও পরামর্শ?

এই নিদর্শন পর্যায়ক্রমিক। এর অর্থ এটি প্রভাবিত হবে যদি প্রতি মিনিটে প্রায় 200 টি অনুরোধের নিচে নেমে আসে - যা ঘটেছে (প্রাকৃতিক ব্যবহারকারী-ক্রিয়াকলাপের কারণে) গভীর রাত থেকে ভোর সকাল পর্যন্ত।

---

অনুরোধগুলি খুব সহজ পোষ্টগুলি 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

এই অনুরোধগুলি প্রতি মিনিটে পৌঁছেছে বা অনুরোধগুলি প্রতি মিনিটে হ্যান্ডেল করা হয়েছে ?

— ব্যবহারকারী 253751

আপনি এই ডেটা রেকর্ড এবং প্লট করতে কোন সফ্টওয়্যার ব্যবহার করেছেন?

— সত্যই

@ উইলিডার: অ্যাপাচি 2-র সাথে রেকর্ড করা হয়েছে এবং আর

— রাফেল

@ মিম্বিস: লগ কনফিগারেশনটি যা আমি যুক্ত করেছি তা দেখুন - আমি মনে করি এটি "আগমন"

— রাফেল

Answer 1

এটি ডেটা সেন্টারে সাধারণ আচরণ। আপনার প্রতিক্রিয়ার সময়টি ধীর সময়টির সাথে মিল রয়েছে যা সাধারণত ব্যাচ উইন্ডো বলে। এটি এমন সময়কাল যখন ব্যবহারকারীর ক্রিয়াকলাপটি কম হবে এবং ব্যাচ প্রক্রিয়াগুলি চালিত হতে পারে। ব্যাকআপগুলিও এই সময়ের মধ্যে করা হয়। এই ক্রিয়াকলাপগুলি সার্ভার এবং নেটওয়ার্কগুলির সংস্থানগুলির উপর চাপ সৃষ্টি করতে পারে যার ফলে পারফরম্যান্স সমস্যাগুলি দেখা যায়।

কয়েকটি সংস্থান রয়েছে যা সমস্যার কারণ হতে পারে:

• উচ্চ সিপিইউ লোড। অনুরোধটি প্রক্রিয়া করার জন্য এটি অ্যাপাচি সময়ের স্লাইসের জন্য অপেক্ষা করতে পারে।
• উচ্চ মেমরি ব্যবহার। এটি বাফারগুলি ফ্লাশ করতে পারে যা ডিস্ক থেকে না পড়ে অ্যাপাচি সংস্থানগুলি সরবরাহ করতে সক্ষম করে। এটি অ্যাপাচি কর্মীদের পেজিং / অদলবদল করতে পারে।
• উচ্চ ডিস্ক ক্রিয়াকলাপ। এটি ডিস্ক আই / ও ক্রিয়াকলাপটি পরিবেশন করা সামগ্রীতে সংশ্লিষ্ট বিলম্বের সাথে সারিবদ্ধ হতে পারে।
• উচ্চ নেটওয়ার্ক ক্রিয়াকলাপ। এটি প্যাকেটগুলির সংক্রমণ, পুনরায় চেষ্টা বৃদ্ধি এবং অন্যথায় পরিষেবা হ্রাস করার জন্য সারিবদ্ধ হতে পারে।

আমি sarএভাবে জারি করা তদন্ত করতে ব্যবহার করি । প্রতিদিনের ডেটা ফাইলগুলিতে ডেটা atsarসংগ্রহ করতে ব্যবহার করা যেতে পারে sar। পারফরম্যান্স যখন স্বাভাবিক থাকে তখন দিনের বেলায় সিস্টেমের আচরণ কেমন হয় এবং পারফরম্যান্স পরিবর্তনশীল হলে রাতারাতি এটি পরীক্ষা করে দেখা যায়।

আপনি যদি সিস্টেমটি muninবা অন্য কোনও সিস্টেমের সাহায্যে নজরদারি করছেন যা গ্রাফগুলি এবং সংস্থানগুলি ব্যবহার করে তবে আপনি সেখানে কিছু সূচক পেতে পারেন। আমি এখনও sarআরও সুনির্দিষ্ট

ব্যাচের প্রক্রিয়াগুলিতে তাদের প্রভাব হ্রাস করার জন্য এমন সরঞ্জাম রয়েছে niceএবং ioniceএটি প্রয়োগ করা যেতে পারে। এগুলি কেবল সিপিইউ বা আই / ও ইস্যুগুলির জন্য কার্যকর। তারা মেমরি বা নেটওয়ার্ক ক্রিয়াকলাপের সাথে সমস্যাগুলি সমাধান করার সম্ভাবনা কম।

ব্যাকআপ ক্রিয়াকলাপটি একটি পৃথক নেটওয়ার্কে সরানো এবং নেটওয়ার্কের তর্ককে হ্রাস করা। কিছু ব্যাকআপ সফ্টওয়্যার ব্যবহার করা হবে এমন ব্যান্ডউইথ সীমাবদ্ধ করতে কনফিগার করা যেতে পারে। এটি নেটওয়ার্কের বিরোধকে সমাধান করতে পারে।

ব্যাচ প্রক্রিয়াগুলি কীভাবে ট্রিগার হয় তার উপর নির্ভর করে আপনি সমান্তরালে চলমান ব্যাচ প্রক্রিয়াগুলির সংখ্যা সীমাবদ্ধ করতে সক্ষম হতে পারেন। এটি সম্ভবত ব্যাচ প্রক্রিয়াগুলির কার্য সম্পাদনকে উন্নত করতে পারে কারণ তারা সম্ভবত একই সংস্থার বিতর্কটি अनुभव করছে।

Comments

একটি লিঙ্ক sarদরকারী হতে পারে। আমি এটি পেয়েছি: en.wikedia.org/wiki/Sar_(Unix)

— রজার লিপসক্বে

এটি কেবল ব্যাকআপই নয়, ভিএম সরবরাহকারীরা একই সময়ে আরও বেশি ভিএম এর একই মেশিনগুলিতে ডাউনটাইম এড়াতে পারে এবং শক্তি সঞ্চয় করতে কয়েকটি র্যাক বন্ধ করে (বা সত্যই, তাদের ব্যাচের কাজে উত্সর্গ করে)

— জেনস টিমারম্যান

Answer 2

এই সম্পর্কটি অন্য দিকে ঘটতে পারে যদি অনুরোধ প্রেরকরা একটি নতুন জমা দেওয়ার আগে পূর্ববর্তী অনুরোধটি শেষ হওয়ার জন্য অপেক্ষা করে। সেক্ষেত্রে ক্লায়েন্ট-সাইড সারিবদ্ধ হওয়ার কারণে অনুরোধের সময়গুলি (যে কোনও কারণেই) ট্র্যাফিক হ্রাস পাবে।

অথবা এটি আপনার পরিমাপের একটি নিদর্শন হতে পারে - উপরের গ্রাফটি যদি অনুরোধগুলি পৌঁছানোর বিপরীতে সম্পূর্ণ অনুরোধগুলি দেখায় তবে অনুরোধ প্রসেসিংয়ের সময় বাড়ার সাথে সাথে হার হ্রাস পাবে (সীমাবদ্ধ ক্ষমতা: ধরে নি))

Comments

অবশ্যই এটি সম্ভাব্য কারণগুলির পৃষ্ঠটি স্ক্র্যাচিং করছে তবে উদ্বোধনী সমস্যা বিবৃতিটি তেমন নজর দিতে পারে না। এই প্রক্রিয়া কি অন্য কিছু কথা বলে? এটি কী ধরণের অনুরোধগুলি সরবরাহ করে? কাজের চাপ কি সময়ের সাথে সাথে বদলে যায়? এবং তাই উপর ....

— ক্যারোল নোওয়াক

আকর্ষণীয় দৃষ্টিকোণ তবে লক্ষণগুলির সময়কাল এবং সময়কাল ভালভাবে যায় না

— রাফেল

Answer 3

যদিও @ বিলেঠরের উত্তর সঠিক হতে পারে, এটি কম লোডের সময়কাল সম্পূর্ণরূপে ব্যাকআপ প্রক্রিয়া দ্বারা গ্রহণ করা অসম্ভব বলে মনে হয় (অর্থাত্ পিরিয়ডগুলি যথাযথভাবে মেলে)।

একটি বিকল্প ব্যাখ্যা সহজভাবে ক্যাশে করা হয়। যদি কোনও প্রদত্ত স্ক্রিপ্ট / ডাটাবেস / যা কিছু সম্প্রতি ব্যবহার করা হয়নি তবে অপারেটিং সিস্টেমের বাকী অংশগুলির জন্য মেমরি মুক্ত করার জন্য প্রাসঙ্গিক ক্যাশেড ডেটা বাদ দেওয়া যেতে পারে। এটি কোনও ডাটাবেসে সূচী হতে পারে, বা কোনও ফাইল সম্পর্কিত O / S বাফার বা অন্য কিছু অনুরূপ। একটি ক্যোয়ারী তখন এই তথ্যটি পুনঃস্থাপন করতে চলেছে যদি এটি শেষ কোয়েরির পরে কিছুক্ষণ হয়ে থাকে। ব্যস্ত সময়কালে এটি ঘটে না কারণ শেষ ক্যোয়ারীটি ঘন ঘন হয়ে আসত। এটি ব্যস্ত সময়কালে আপনি কেন কম প্রতিক্রিয়ার সময় এবং উচ্চ প্রতিক্রিয়ার সময় দেখছেন তাও ব্যাখ্যা করবে ।

Comments

বিশেষত যদি ক্যোয়ারী ক্যাচিং এবং / অথবা ডিস্ক অ্যাক্সেস ক্যাচিং জড়িত থাকে। একদিকে যেমন যদি কোনও "থ্রেডের পুনরায় ব্যবহার" কৌশল থাকে তবে তাও সহায়তা করে।

— ম্যাকেনজম

জড়িত কোনও ধরণের পাঠ্য নেই।

— রাফেল

@ রাফেল আমি খুব সন্দেহ করে আপনি "গ্যারান্টিযুক্ত কোনও ধরণের পড়া নেই" এর গ্যারান্টি দিতে পারেন। একটি তুচ্ছ স্তরে, ধরুন আপাচে পৃষ্ঠাগুলি পেজযুক্ত হয়েছে কারণ র‌্যামের চেয়েও কিছু চাইছিল? ধরুন আপনার অ্যাপাচে এমপিএম থ্রেড / প্রক্রিয়াগুলির সংখ্যা হ্রাস করেছে যখন জিনিসগুলি অলস থাকে এবং নতুন তৈরি করার ক্ষেত্রে ওভারহেড থাকে? আপনি কি গুরুত্ব সহকারে বলছেন যে আপনি যদি straceঅ্যাপাচি প্রক্রিয়া চালিয়ে যান, আপনি কোনও read()সিস্টেম কল বা অনুরূপ দেখতে পাচ্ছেন না ? এটা বেশ অস্বাভাবিক হবে।

— abligh

@ অলিগ: ভাল, সঠিক, আমার "পরিষেবা" স্পষ্টভাবে ডিস্ক থেকে পড়া কিছুই প্রয়োগ করে না

— রাফেল

@ রাফেল যদি আপনি ওএস ক্যাশিংয়ের প্রভাব পরীক্ষা করতে চান (কেবলমাত্র), তবে ব্যস্ত সময়কালে echo 3 > /proc/sys/vm/drop_cachesপ্রতি 5 সেকেন্ডে এক মিনিটের জন্য করুন এবং দেখুন প্রতিক্রিয়ার সময় আপনি একই রকম প্রভাব পান কিনা see

— এবলিগ করুন

Answer 4

আপনি সেখানে যা দেখছেন তা আমার কাছে মনে হচ্ছে যেমন এটি কোনও পরিসংখ্যানগত সমস্যা হতে পারে। এটি নাও হতে পারে, @ বিলঠোরের উত্তরটি সঠিক হতে পারে তবে আমি এটি সম্পূর্ণতার জন্য পোস্ট করব।

প্রতিক্রিয়া সময়ের গ্রাফগুলি পারসেন্টাইল ভিত্তিক। 800-1000 অনুরোধগুলির একটি নমুনা পুল এটির জন্য একটি ভাল নমুনা গণনা, 50-100 অনুরোধের একটি পুল সম্ভবত এত বেশি নয়।

আপনি যদি ধরে নেন যে ধীর অনুরোধের সংখ্যা অনুরোধের পরিমাণের লিনিয়ার ফাংশন নয়, যেমন অনুরোধের প্রসার বৃদ্ধির ক্রমটি ধীর অনুরোধগুলির প্রসার বৃদ্ধির ক্রম হিসাবে আসে না, তবে অনুরোধের উচ্চতর পরিমাণের ফলাফল হবে নিম্ন গড় অনুরোধ সময়।

Comments

যদি পর্যবেক্ষণটি কেবল 50 থেকে 100 টি অনুরোধের সমন্বয়ে গঠিত ছিল তবে এটি কেবল এলোমেলো হতে পারে তবে আপনি যদি গ্রাফটি দেখেন তবে আপনি দেখতে পাবেন যে আমরা প্রায় 50 থেকে 100 টি অনুরোধের সাথে জড়িত 60 এক্স 5 পরীক্ষার বিষয়ে কথা বলছি - এটি অবশ্যই যথেষ্ট এলোমেলোতা বাতিল। এছাড়াও যদি আপনি ঘনিষ্ঠভাবে তাকান তবে আপনি দেখতে পাচ্ছেন যে প্রায় 2500 মাইল স্থিতিশীল গড় 50 তম পার্সেন্টাইল।

— রাফেল

অগত্যা, এই জাতীয় পরিসংখ্যানগুলি বেশিরভাগ ক্ষেত্রে কীভাবে আচরণ করে তা পুরোপুরি নয়। উদাহরণস্বরূপ, ১ ঘন্টা অনুরোধে 1000 অনুরোধ এবং 1 মিনিটের বেশি 1000 অনুরোধগুলি একই আচরণ করে না। এছাড়াও সম্ভবত এখানে ঘটছে না। ছোট নমুনার আকারগুলি অদ্ভুতভাবে আচরণ করে, এক্ষেত্রে এটি 60x5 নমুনা সেটগুলির মতো। প্যাটার্নটি অ-রৈখিক লোডের ফলাফল হতে পারে।

— কাইথর

Answer 5

মিথ্যা, বড় মিথ্যা এবং পরিসংখ্যান আছে।

আমার অনুমান: আপনি তিনটি স্বতন্ত্র বিভাগের অনুরোধ পেয়েছেন:

1. সাধারণ পরিবর্তনশীল স্ট্রিমটিতে বেশিরভাগ অনুরোধ থাকে এবং এগুলি 200-300 within এর মধ্যে শেষ হয়।
2. প্রতি মিনিটে প্রায় 20 টি অনুরোধের (এমনকি রাতে) স্থির হারে ছোট স্ট্রিম stream প্রতিটি সম্পূর্ণ করতে প্রায় 2.500 .s সময় নেয়।
3. প্রতি মিনিটে প্রায় 10 টি অনুরোধের (এমনকি রাতে) স্থির হারে ক্ষুদ্র স্ট্রিম। প্রতিটি 4.000 above এর উপরে ভালভাবে নেয়।

রাতে, প্রতি মিনিটে 50 টি অনুরোধগুলি যথাযথভাবে 20 + 20 + 10। এবং সুতরাং, 50% পার্সেন্টাইলের ফলাফল এখন দৃ stream় 2 স্ট্রিমের ফলাফলের উপর নির্ভর করে এবং 95% পার্সেন্টাইল স্ট্রিম 3 এর উপর নির্ভর করে যাতে এটি কখনও গ্রাফেও দেখাতে পারে না।

দিনের বেলাতে, 2 + 3 স্ট্রিমগুলি 95% পার্সেন্টাইলের উপরে ভালভাবে লুকানো থাকে।

Comments

স্রোত বলতে কী বোঝ? অনুরোধ ক্লায়েন্টদের একেবারে ভিন্নধর্মী যখন অনুরোধগুলি একেবারে একজাতীয় হয়।

— রাফেল

Answer 6

আমি এটি যত তাকাব, ততই আমি ভাবতে আগ্রহী যে ডেটা সংগ্রহের ক্ষেত্রে কোনও সমস্যা আছে।

প্রথমে, আপনার টিপিএস নিয়ে সত্যিই অদ্ভুত কিছু চলছে। সামগ্রিক প্যাটার্নটি দেখতে সাধারণ দেখায়, রাত ৯ টার দিকে খুব তীব্র বিরতি ঘটে এবং তারপরে আবার সকাল 7 টার দিকে। একটি সাধারণ চার্ট অফ-পিক আওয়ারগুলিতে রূপান্তরকালে খুব মসৃণ হবে।

এটি পরামর্শ দেয় যে প্রোফাইলে কোনও পরিবর্তন রয়েছে এবং আপনার কাছে সম্ভবত পৃথকভাবে 2 টি পৃথক ক্লায়েন্ট রয়েছে:

1. এটি কেবলমাত্র সকাল at টা (ইসহ) এবং রাত ৯ টা (ইশ) এর মধ্যে, উচ্চ পরিমাণে এবং and
2. আরেকটি যা সম্ভবত চতুর্দিকে, কম পরিমাণে সঞ্চালিত হয়।

দ্বিতীয় ইঙ্গিতটি প্রায় 18:00 টার দিকে। এর আগে এবং পরে বেশিরভাগ সময় আমাদের হাই ভলিউম প্রোফাইল থাকে - উচ্চ টিপিএস এবং কম বিলম্ব। তবে প্রায় 18:00 টার দিকে হঠাৎ করে 800-1000 আরপিএম থেকে 400 আরপিএমের থেকে কমতে হবে। সম্ভবত এটি কি কারণ হতে পারে?

তৃতীয় ইঙ্গিতটি 5 তম পার্সেন্টাইল প্রতিক্রিয়া বারের ধাপে ডাউন। আমি আসলে ন্যূনতম প্রতিক্রিয়া বারগুলি (তবে 5 তম পার্সেন্টাইল সম্ভবত আরও ভাল) দুটি কারণের জন্য দেখতে পছন্দ করি: এটি আমাকে পরিষেবা সময় বলে (যেমন প্রতিক্রিয়ার সময় বিয়োগ বিয়োগ), এবং প্রতিক্রিয়ার সময়গুলি ওয়েবুল বিতরণ অনুসরণ করে যার অর্থ মোড (বা সর্বাধিক সাধারণ মান) সর্বনিম্নের ঠিক উপরে।

সুতরাং 5 তম পার্সেন্টাইলের ধাপে ডাউন আমাকে বলেছে যে সিরিজটিতে হঠাৎ বিরতি রয়েছে এবং সার্ভিসের সময়টি প্রকৃতপক্ষে হ্রাস পেয়েছে যদিও ভিন্নতা এবং গড় প্রতিক্রিয়ার সময় উভয়ই অনেক বেড়েছে।

পরবর্তী পদক্ষেপ

এই পর্যায়ে আমি এর আগে এবং পরে উচ্চ-ভলিউমের নমুনাগুলির তুলনায় 18:00 লো-ভলিউম নমুনাগুলির তুলনায় আলাদা কি তা জানতে লগগুলিতে গভীর ডুব দেবো।

আমি খুঁজব:

• ভৌগলিক অবস্থানের পার্থক্য (ক্ষেত্রে বিলম্বিতা যদি $ অনুরোধ_কালকে প্রভাবিত করে)
• ইউআরএল মধ্যে পার্থক্য (কোনওটিই হওয়া উচিত নয়)
• এইচটিটিপি পদ্ধতিতে (পোষ্ট / জিইটি) পার্থক্য (কোনওটিই হওয়া উচিত নয়)
• একই আইপি থেকে বারবার অনুরোধ
• এবং অন্য কোনও পার্থক্য ...

বিটিডাব্লু, 18:00 "ইভেন্ট" আমার পক্ষে যথেষ্ট প্রমাণ যে ডেটা সেন্টারের ভিড় / ক্রিয়াকলাপের সাথে এটি করার কিছুই নয়। এটি সত্য হওয়ার জন্য, যানজটের কারণে টিপিএসে একটি ঝরে পড়তে হবে, যা 18:00 মিনিটে সম্ভব তবে এটি টেকসই টেকসই হওয়ার সম্ভাবনা কম, এবং রাত 9 টা থেকে সকাল 7 টার মধ্যে 10 ঘন্টার জন্য টিপিএসে সহজেই বক্ররেখা পড়তে পারে।