Squid-এর প্রকৃত ফাইল-ডেসক্রিপ্টর সীমা খুঁজে বের করা
PAM সেটিংস পরিবর্তন বা ক্যাপাসিটি রেসিপি থেকে নির্দিষ্ট nofile মান কপি করার আগে চলমান প্রক্সির প্রক্রিয়া সীমা পড়ুন।
লগইন শেলের ulimit -n বিশ্বাস করার আগে চলমান ডেমনটি পরীক্ষা করুন। squid.service ব্যবহার করা ইনস্টলেশনের জন্য শুরু করুন:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceপ্রকৃত প্রক্রিয়া আইডি ব্যবহার করে /proc/PID/limits পড়ুন। বহু-প্রক্রিয়া স্থাপনায় সংশ্লিষ্ট ওয়ার্কারও দেখুন। কনফিগারেশনে সংরক্ষিত মান এই প্রক্রিয়া এটি উত্তরাধিকার পেয়েছে তার প্রমাণ নয়।
| নিয়ন্ত্রণ | পরিসর |
|---|---|
শেল ulimit এবং PAM limits.conf | শেলের উত্তরসূরি বা যে সেশনগুলি প্রকৃতপক্ষে PAM সেটিং ব্যবহার করে |
systemd LimitNOFILE= | সেই পরিষেবার রিসোর্স নীতির অধীনে চালু হওয়া প্রক্রিয়া |
Squid max_filedescriptors, যেখানে সমর্থিত | অপারেটিং সিস্টেমের সীমার মধ্যে অ্যাপ্লিকেশন সীমা |
প্রশাসক ফাইলটি পরিবর্তন করেছেন বলে সিস্টেম পরিষেবা PAM সম্পাদনা গ্রহণ করে না। systemd সীমা পরিবর্তন উপযুক্ত হলে পরিষেবা-নির্দিষ্ট drop-in ব্যবহার করুন। Squid নথিভুক্ত করে যে max_filedescriptors পরিবর্তন করতে পুনরায় চালু করা প্রয়োজন; সেট না করলে OS-এর নরম সীমা উত্তরাধিকার হয়।
সীমাটি ব্যবহারকারীর জন্য নয়, ডেসক্রিপ্টরের জন্য মাপুন। ক্লায়েন্টরা একাধিক সকেট ধরে রাখতে পারে, এবং সামনের সংযোগ, লগ ও সহায়ক পাইপও ডেসক্রিপ্টর খরচ করে। সীমা বাড়ালে প্রতিটি সম্ভাব্য ডেসক্রিপ্টরের জন্য নির্দিষ্ট RAM আগেই সংরক্ষণ না করেই বেশি খরচ সম্ভব হয়। পুরনো মেমরি-প্রতি-সকেট অনুমান বা 65,535 কোনোটিই সর্বজনীন ধারণক্ষমতার প্রয়োজন বা Linux-এর ঊর্ধ্বসীমা নয়।
পরিষেবা পরিবর্তনের পরে নতুন প্রক্রিয়ার সীমা উদ্দেশ্যমান মানের সাথে তুলনা করুন। তাদের অনেক নিচে ব্যর্থতা ঘটলে, প্রকৃতপক্ষে যে সম্পদ শেষ হচ্ছে তা তদন্ত করুন।