worker_connections বাড়ানোর আগে NGINX প্রক্সি সকেটের বাজেট নির্ধারণ করুন
প্রক্সি সংযোগ সাধারণত ক্লায়েন্ট ও আপস্ট্রিম—দুটি সকেটই দখল করে; ওয়ার্কারের সংযোগ সীমা ও পরিষেবার ফাইল-ডেসক্রিপ্টর সীমা আলাদা করে দেখুন।
একটি দীর্ঘস্থায়ী প্রক্সি সংযোগ সাধারণত দুটি সকেট দখল করে: ক্লায়েন্টের এবং আপস্ট্রিমের। worker_connections উভয় দিক গোনে। তাই এটি worker_processes দিয়ে গুণ করলে প্রক্সি ব্যবহারকারীর ক্ষমতার কোনো প্রতিশ্রুতি পাওয়া যায় না।
সংযোগ ব্যর্থ হলে যে সীমা জানানো হয়েছে তা অনুসরণ করুন:
| প্রমাণ | যে সেটিং বা প্রক্রিয়া-অবস্থা দেখতে হবে |
|---|---|
| worker_connections শেষ হয়ে যাওয়া | ওয়ার্কারের সংযোগ বাজেট, আপস্ট্রিম সকেটসহ |
| অপারেটিং সিস্টেমের “অতিরিক্ত ফাইল খোলা আছে” | প্রকৃত পরিষেবা প্রক্রিয়া যে ফাইল-ডেসক্রিপ্টর সীমা উত্তরাধিকারে পায় |
শোনার সকেট, লগ ও অন্যান্য খোলা ফাইলও ডেসক্রিপ্টর খরচ করে। সংযোগ পুনর্ব্যবহার ও ট্রাফিকের মিশ্রণ ব্যবহারকারী ও সকেটের সম্পর্ক বদলে দেয়।
worker_rlimit_nofile পরিবেশের অনুমতির সাপেক্ষে ওয়ার্কারের সীমা সমন্বয় করে। systemd ইউনিট LimitNOFILE নির্ধারণ করতে পারে; ইন্টারঅ্যাকটিভ শেলের ulimit চালু পরিষেবা বদলায় না।
কর্মভারের সঙ্গে সীমা মিলিয়ে নিন এবং কে সেগুলো খরচ করছে তা দেখুন। অপ্রত্যাশিত ক্লায়েন্ট বা বারবার ব্যর্থ আপস্ট্রিম সংযোগ আগের যথেষ্ট বাজেট শেষ করে দিতে পারে। বড় প্রক্রিয়া-সংখ্যা বা মেমরি সীমা ডেসক্রিপ্টরের ঘাটতি মেরামত করে না।