নিবন্ধ ডিরেক্টরি
একটি সার্ভার একই সাথে কতজন ব্যবহারকারীকে সামলাতে পারবে তা নির্ভর করে না সার্ভারটিতে কতগুলো কোর আছে তার উপর, বরং প্রতিটি প্রসেস কী পরিমাণ মেমরি ব্যবহার করে তার উপর।
এই কথাটি উস্কানিমূলক মনে হতে পারে, কিন্তু পরিচালনা ও রক্ষণাবেক্ষণ শিল্পে এটিই সবচেয়ে বাস্তব এবং বেদনাদায়ক অভিজ্ঞতা।
কেন মেমোরিই মূল প্রতিবন্ধকতা?
অনেকেই ৮-কোর সিপিইউ এবং ২৪ জিবি মেমোরি সহ একটি ভিপিএস দেখে অবচেতনভাবে মনে করেন যে, তারা সহজেই শত শত পিএইচপি-এফপিএম প্রসেস চালাতে পারবেন।
তবে বাস্তবে, একটি একক PHP প্রসেসের RSS মেমরি ব্যবহার প্রায়শই 200MB পর্যন্ত হয়ে থাকে ।
কমান্ড লাইনের মাধ্যমে প্রকৃত পরীক্ষা করে এই ফলাফলটি পাওয়া গেছে:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP- এর জটিল ফ্রেমওয়ার্ক এবং মাল্টি-প্লাগইন পরিবেশে , বিশেষ করে OPcache অপটিমাইজেশন ছাড়া, ২০০ মেগাবাইটই স্বাভাবিক।
এর মানে হলো, সিপিইউ নয়, বরং মেমরিই হলো সর্বোচ্চ কনকারেন্সি নির্ধারণকারী চূড়ান্ত সীমা।
প্রস্তাবিত কনফিগারেশন ফাইল (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
প্যারামিটার গণনার যুক্তি এবং নির্ধারণের ভিত্তি
| কনফিগারেশন পরামিতি | মান নির্ধারণ করা | মূল গণনা এবং সেটআপ ভিত্তি |
|---|---|---|
| pm | dynamic | ডাইনামিক মোড কনকারেন্সি চাহিদার উপর ভিত্তি করে প্রসেসগুলোকে যথেচ্ছভাবে যোগ বা মুছে ফেলার সুযোগ দেয়, যা রেসপন্স স্পিড এবং মেমরি ইউটিলাইজেশনের মধ্যে ভারসাম্য রক্ষা করে। |
| pm.max_children | 80 | সিস্টেম কার্নেল বাদে মোট ২৪ জিবি মেমরি এবং মাইএসকিউএল/RedisNginx-এর পরে PHP-এর জন্য প্রায় ১৬ জিবি জায়গা বাকি থাকে।16,384 MB / 200 MB ≈ 81.9এটিকে ৮০-তে সেট করলে উচ্চ কনকারেন্সির সময় OOM (আউট অফ মেমোরি) সম্পূর্ণরূপে দূর করা যায়। |
| pm.start_servers | 16 | রিস্টার্ট করার পর সার্ভিসটি যাতে তাৎক্ষণিকভাবে বেসিক কনকারেন্সি পরিচালনা করতে পারে, তা নিশ্চিত করার জন্য স্টার্টআপের সময় প্রিহিটিং সিপিইউ কোরের সংখ্যার দ্বিগুণে (৮ কোর × ২ = ১৬) সেট করা হয়। |
| pm.min_spare_servers | 8 | সিপিইউ কোরের সংখ্যা ৮-এ সেট করুন, যাতে কম ট্র্যাফিকের সময়েও যেকোনো মুহূর্তে নতুন অনুরোধে সাড়া দেওয়া যায়। |
| pm.max_spare_servers | 24 | ট্র্যাফিক কমে যাওয়ার পরেও মৃদু ওঠানামা সামাল দেওয়ার জন্য, এটিকে সিপিইউ কোরের সংখ্যার ৩ গুণে (৮ কোর × ৩ = ২৪) সেট করুন, যাতে মাঝারি সংখ্যক প্রসেস চালু থাকে। |
| pm.max_requests | 500 | যদি কোনো একটি প্রসেস ২০০ মেগাবাইটের একটি বড় মেমরি বেসে পৌঁছে যায়, তবে রিকোয়েস্টের সংখ্যা কমিয়ে ৫০০ করলে প্রসেসটি ডেস্ট্রয় হয়ে যাবে এবং পুনরায় তৈরি হবে, যা ইমপ্লিসিট মেমরি লিক আরও দ্রুত পরিষ্কার করতে পারে। |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers ১০ সেকেন্ড ধরে কোনো অনুরোধ না এলে নিষ্ক্রিয় প্রসেসগুলো স্বয়ংক্রিয়ভাবে মুক্ত হয়ে সিস্টেম মেমরিতে ফিরে আসে। |
অপরিহার্য সহায়ক সেটিংস এবং অপ্টিমাইজেশন পরামর্শ
১. টাইমআউট হ্যাঙ্গওভার-রোধী ব্যবস্থা
request_terminate_timeout = 60s এটাই মূল বিষয়।
এটি ডাটাবেস ডেডলক বা থার্ড-পার্টি এপিআই ব্লকিংয়ের কারণে আটকে থাকা প্রসেসগুলোকে জোরপূর্বক বন্ধ করতে পারে।
এদিকে, Nginx-এর fastcgi_read_timeout এটি অবশ্যই কমপক্ষে ৬০ সেকেন্ড রাখতে হবে, অন্যথায় ক্লায়েন্ট সময়ের আগেই এটি পেয়ে যাবে। 504 Gateway Timeout.
২. স্মৃতিশক্তির প্রতিবন্ধকতা কাটিয়ে ওঠার কৌশল
সর্বোচ্চ ৮০টি কনকারেন্ট প্রসেস বলতে বোঝায় যে, চরম কনকারেন্সি পরিস্থিতিতে সিস্টেমটি একই সাথে সর্বোচ্চ ৮০টি ডাইনামিক HTTP রিকোয়েস্ট পরিচালনা করতে পারে।
ধারণক্ষমতা আরও বাড়াতে চাইলে, প্রতিটি প্রসেসের মেমরি ব্যবহার কমানোর দিকে মনোযোগ দেওয়া উচিত।
- OPcache সক্ষম করুন: এ
php.iniমাঝারি কনফিগারেশনopcache.enable=1এবংopcache.memory_consumption=256বাইটকোড ক্যাশিং একটি একক প্রসেসের মেমরি ব্যবহার ২০০ মেগাবাইট থেকে কমিয়ে ৬০~১০০ মেগাবাইটে আনতে পারে। - মেমরি_লিমিটের যুক্তিসঙ্গত নিয়ন্ত্রণ将
php.iniমধ্যমmemory_limitসীমাবদ্ধ128M或256Mস্বতন্ত্র অস্বাভাবিক স্ক্রিপ্ট প্রতিরোধ করতেসীমাহীনএটি অনেক মেমরি ব্যবহার করে।
যখন কোনো একটি প্রসেসের মেমোরি ব্যবহার ১০০ মেগাবাইটে নেমে আসে...pm.max_children এটিকে নিরাপদে আপগ্রেড করা যেতে পারে 150 এছাড়াও, যুগপৎ কার্যক্রমের সক্ষমতা প্রায় দ্বিগুণ হয়েছে।
উদ্ধৃত প্রামাণিক মতামত
অফিসিয়াল Nginx ডকুমেন্টেশনের সুপারিশ অনুযায়ী :
রিসোর্স নিঃশেষ হওয়া রোধ করতে FastCGI অ্যাপ্লিকেশনগুলোকে টাইমআউট নির্দেশনার মাধ্যমে সর্বদা পর্যবেক্ষণ করা উচিত।
(উৎস: এনজিনক্স ডক্স)
অফিসিয়াল পিএইচপি ম্যানুয়ালে স্পষ্টভাবে বলা আছে:
pm.max_children সর্বোচ্চ কতগুলো চাইল্ড প্রসেস তৈরি করা যাবে তা নির্ধারণ করে। এটিই সবচেয়ে গুরুত্বপূর্ণ নির্দেশিকা।
(উৎস: পিএইচপি-এফপিএম ডকুমেন্টেশন)
এই প্রামাণ্য মতামতগুলো আমাদের কার্যপদ্ধতির সাথে পুরোপুরি সামঞ্জস্যপূর্ণ, যা প্রমাণ করে যে অপ্টিমাইজেশনের যুক্তি কেবল অভিজ্ঞতার উপরই নয়, বরং প্রমিত সর্বোত্তম অনুশীলনের উপরও ভিত্তি করে গড়ে উঠেছে।
উপসংহার: আমার দৃষ্টিভঙ্গি এবং মূল উক্তি
উচ্চ-একযোগে কার্য সম্পাদনের পরিস্থিতিতে, সিপিইউ হলো ইঞ্জিন, মেমরি হলো জ্বালানি ট্যাঙ্ক, এবং পিএইচপি-এফপিএম হলো ফ্লিট ডিসপ্যাচার।
ইঞ্জিন যতই শক্তিশালী হোক না কেন, জ্বালানির ট্যাঙ্ক যথেষ্ট বড় না হলে কনভয় বেশি দূর এগোতে পারবে না।
প্রকৃত বিশেষজ্ঞরা অন্ধভাবে প্যারামিটারগুলোর সর্বোচ্চ সীমা নির্ধারণ করেন না, বরং অপচয় এবং ওভারফ্লো উভয়ই এড়াতে প্রতিটি প্রসেসের মেমরি ব্যবহার নির্ভুলভাবে গণনা করেন।
অপ্টিমাইজেশনের মূল কথা হলো সীমিত সম্পদের মধ্যে সর্বোত্তম ভারসাম্য খুঁজে বের করা।
এটি শুধু একটি প্রযুক্তি নয়, বরং একটি দর্শনও ।
সুতরাং, এই বিশ্বাস করা বন্ধ করুন যে "কোরের সংখ্যাই সবকিছু নির্ধারণ করে।" প্রকৃতপক্ষে যা কনকারেন্সি সীমা নির্ধারণ করে তা হলো মেমোরির উপর আপনার নিয়ন্ত্রণ।
পদক্ষেপ নিন এবং আপনার ভিপিএস-কে তার পূর্ণ সম্ভাবনায় অপ্টিমাইজ করুন, মেমোরির প্রতিটি কণার সর্বোচ্চ ব্যবহার নিশ্চিত করুন।
আশা করি, চেন ওয়েইলিয়াং-এর ব্লগে ( https://www.chenweiliang.com/ ) শেয়ার করা "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" শীর্ষক আর্টিকেলটি আপনার জন্য সহায়ক হবে।
এই নিবন্ধটির লিঙ্কটি নির্দ্বিধায় শেয়ার করুন: https://www.chenweiliang.com/cwl-34509.html