আমি একটি অপেক্ষাকৃত কম ট্রাফিক সাইট চালাচ্ছি যা সাইট আপডেটের পরে সপ্তাহে একবার দর্শকদের মধ্যে একটি বিশাল স্পাইক অনুভব করে। এই স্পাইকের সময়, সপ্তাহের বাকি অংশের তুলনায় সাইটের কার্য সম্পাদন অত্যন্ত দুর্বল। সার্ভারগুলিতে প্রকৃত লোডটি খুব কম থাকে, নির্ভরযোগ্যভাবে 10% সিপিইউ এর অধীনে এবং 30% র্যামের অধীনে (আমরা আসলে যা করছি তার জন্য হার্ডওয়্যারটি সম্পূর্ণ ওভারকিল হওয়া উচিত) তবে কোনও কারণে অ্যাপাচি পরিমাণের সাথে লড়াই করতে অক্ষম বলে মনে হচ্ছে অনুরোধ। আমরা আরএইচইল 5.7, কার্নেল 2.6.18-274.7.1.el5, x86_64 এ অ্যাপাচি 2.2.3 চালিয়ে যাচ্ছি।
অ্যাবি সহ বন্ধ ঘন্টা সময় এই আচরণ পুনরুত্পাদন করার চেষ্টা, আমি প্রায় 256 ব্যবহারকারী অতিক্রম করে যখন কর্মক্ষমতা একটি বড় ড্রপ খুঁজে পাচ্ছি। সবচেয়ে ছোট সম্ভাব্য ব্যবহারের ক্ষেত্রে পরীক্ষা চালিয়ে আমি আসতে পারি (স্থির পাঠ্য ফাইলটি পুনরুদ্ধার করা হচ্ছে, মোট 223 বাইট মোট) পারফরম্যান্স ধারাবাহিকভাবে 245 একযোগে অনুরোধের সাথে স্বাভাবিক:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 25 5.8 24 37
Processing: 15 65 22.9 76 96
Waiting: 15 64 23.0 76 96
Total: 30 90 27.4 100 125
Percentage of the requests served within a certain time (ms)
50% 100
66% 108
75% 111
80% 113
90% 118
95% 120
98% 122
99% 123
100% 125 (longest request)
তবে যত তাড়াতাড়ি আমি একসাথে 265 টি অনুরোধের জন্য ছদ্মবেশী হয়েছি, তাদের একটি উপসেট সম্পূর্ণ করার জন্য একটি অযৌক্তিক পরিমাণ সময় নেওয়া শুরু করে:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 13 195 692.6 26 3028
Processing: 15 65 21.3 72 100
Waiting: 15 65 21.3 71 99
Total: 32 260 681.7 101 3058
Percentage of the requests served within a certain time (ms)
50% 101
66% 108
75% 112
80% 116
90% 121
95% 3028
98% 3040
99% 3044
100% 3058 (longest request)
এই ফলাফলগুলি একাধিক রান জুড়ে খুব সামঞ্জস্যপূর্ণ। যেহেতু এই বাক্সে অন্য ট্র্যাফিক যাচ্ছে, তাই নিশ্চিতভাবেই নিশ্চিত না যে হার্ড কাটঅফটি কোথায় থাকবে, যদি তা থাকে তবে এটি সন্দেহজনকভাবে 256 এর কাছাকাছি বলে মনে হয়।
স্বাভাবিকভাবেই, আমি ধরে নিয়েছিলাম যে এটি থ্রেড সীমাটি প্রিফার্কে হয়ে গেছে, তাই আমি এগিয়ে গিয়ে উপলব্ধ থ্রেডের সংখ্যা দ্বিগুণ করার জন্য এবং থ্রেডের পুলটিকে ক্রমবর্ধমানভাবে সঙ্কুচিত হওয়া থেকে রোধ করার জন্য কনফিগারেশনটি সামঞ্জস্য করেছি:
<IfModule prefork.c>
StartServers 512
MinSpareServers 512
MaxSpareServers 512
ServerLimit 512
MaxClients 512
MaxRequestsPerChild 5000
</IfModule>
মোড_স্ট্যাটাস নিশ্চিত করে যে আমি এখন 512 টি উপলব্ধ থ্রেড নিয়ে চালাচ্ছি
8 requests currently being processed, 504 idle workers
তবে, এক সাথে 265 টি অনুরোধ করার চেষ্টা করা এখনও আগেরটির মতো প্রায় একই রকম ফলাফল দেয়
Connection Times (ms)
min mean[+/-sd] median max
Connect: 25 211 714.7 31 3034
Processing: 17 94 28.6 103 138
Waiting: 17 93 28.5 103 138
Total: 57 306 700.8 138 3071
Percentage of the requests served within a certain time (ms)
50% 138
66% 145
75% 150
80% 161
90% 167
95% 3066
98% 3068
99% 3068
100% 3071 (longest request)
ডকুমেন্টেশন (এবং স্ট্যাক এক্সচেঞ্জ) কেটে যাওয়ার পরে আমি আরও বাধা কনফিগারেশন সেটিংসের জন্য এই ক্ষতি করতে চেষ্টা করছি loss আমি কি অনুপস্থিত কিছু আছে? আমি অ্যাপাচি বাইরে উত্তর সন্ধান করা উচিত? অন্য কেউ এই আচরণ দেখেছেন? কোন সাহায্যের ব্যাপকভাবে প্রশংসা হবে।
সম্পাদনা করুন:
লাদাদাদাদের পরামর্শ অনুসারে আমি আপাচের বিরুদ্ধে সোজা হয়ে দৌড়ালাম। আমি কয়েকবার -t এবং -T দিয়ে চেষ্টা করেছি এবং সাধারণের থেকে কিছুই খুঁজে পেলাম না। আমি তারপরে বর্তমানে চলমান সমস্ত অ্যাপাচি প্রক্রিয়াগুলির বিরুদ্ধে স্ট্রেস-সি চালানোর চেষ্টা করেছি এবং এটি পেয়েছি:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
22.09 0.317836 5 62128 4833 open
19.91 0.286388 4 65374 1896 lstat
13.06 0.187854 0 407433 pread
10.70 0.153862 6 27076 semop
7.88 0.113343 3 38598 poll
6.86 0.098694 1 100954 14380 read
(... abdridged)
যদি আমি এই অধিকারটি পড়ছি (এবং আমার সাথে সহ্য করুন, কারণ আমি স্ট্রেসটি প্রায়শই ব্যবহার করি না) এই সমস্ত অনুরোধগুলি যে সময় গ্রহণ করছে তাতে সিস্টেম কলগুলির কোনওটিই দায়বদ্ধ করতে পারে না। এটি প্রায় দেখে মনে হচ্ছে অনুরোধগুলি এমনকি কর্মীর থ্রেডে যাওয়ার আগে বাধাটি ঘটছে।
সম্পাদনা 2:
বেশ কয়েকটি লোকের পরামর্শ অনুসারে, আমি নিজেই ওয়েব সার্ভারে আবার পরীক্ষা চালিয়েছি (আগে পরীক্ষাটি একটি নিরপেক্ষ ইন্টারনেট অবস্থান থেকে চালানো হয়েছিল)। ফলাফল বিস্ময়কর ছিল:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 11 6.6 12 21
Processing: 5 247 971.0 10 4204
Waiting: 3 245 971.3 7 4204
Total: 16 259 973.3 21 4225
Percentage of the requests served within a certain time (ms)
50% 21
66% 23
75% 24
80% 24
90% 26
95% 4225
98% 4225
99% 4225
100% 4225 (longest request)
নীচের লাইনের সময়টি ইন্টারনেট-ভিত্তিক পরীক্ষার অনুরূপ, তবে স্থানীয়ভাবে চালিত হলে ধারাবাহিকভাবে কিছুটা খারাপ হতে দেখা যায়। আরও মজার বিষয় হল, প্রোফাইলটি নাটকীয়ভাবে পরিবর্তিত হয়েছে। যদিও দীর্ঘকাল ধরে চলমান অনুরোধগুলির বেশিরভাগ সময় "সংযোগ" করতে ব্যয় করা হয়েছিল এখন বাধাটি প্রসেসিং বা ওয়েটিংয়ে রয়েছে বলে মনে হয়। আমার সন্দেহ হতে চলেছে যে এটি আসলে একটি পৃথক সমস্যা হতে পারে যা আগে নেটওয়ার্ক সীমাবদ্ধতার দ্বারা মুখোশধারী ছিল।
অ্যাপাচি হোস্টের মতো একই স্থানীয় নেটওয়ার্কে অন্য মেশিন থেকে আবার পরীক্ষা চালানো, আমি আরও অনেক যুক্তিসঙ্গত ফলাফল দেখছি:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.8 2 4
Processing: 13 118 99.8 205 222
Waiting: 13 118 99.7 204 222
Total: 15 121 99.7 207 225
Percentage of the requests served within a certain time (ms)
50% 207
66% 219
75% 220
80% 221
90% 222
95% 224
98% 224
99% 225
100% 225 (longest request)
এই দুটি পরীক্ষা এক সাথে অনেকগুলি প্রশ্ন উত্থাপন করে, তবে সেগুলি থেকে পৃথক করে, এখন কিছু পরিমাণ গুরুতর নেটওয়ার্কের বাধার জন্য নির্দিষ্ট পরিমাণ বোঝার আওতায় আসার জন্য বাধ্যতামূলক মামলা তৈরি করা দরকার। আমি মনে করি যে পরবর্তী পদক্ষেপগুলি পৃথকভাবে নেটওয়ার্ক স্তরটি তদন্ত করবে।