লগইন শ্বেলৰ 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 সীমা সলনি কৰা উপযুক্ত হ'লে সেৱা-নিৰ্দিষ্ট ড্ৰপ-ইন ব্যৱহাৰ কৰক। Squid এ নথিভুক্ত কৰে যে max_filedescriptors সলনি কৰিবলৈ পুনৰাৰম্ভ প্ৰয়োজন; ছেটিং নকৰা অৱস্থাত OS ৰ কোমল সীমা উত্তৰাধিকাৰ হয়।

সীমাটো ব্যৱহাৰকাৰীৰ বাবে নহয়, ফাইল বিৱৰণৰ বাবে মাপ কৰক। ক্লায়েন্টে কেইবাটাও ছকেট ৰাখিব পাৰে, আৰু আগলৈ যোৱা সংযোগ, লগ আৰু সহায়ক পাইপেও ফাইল বিৱৰণ খৰচ কৰে। সীমা বৃদ্ধি কৰিলে প্ৰতিটো সম্ভাব্য বিৱৰণৰ বাবে স্থিৰ RAM আগতীয়াকৈ সংৰক্ষণ নকৰাকৈ অধিক খৰচৰ সুযোগ দিয়ে। পুৰণি মেমৰি-প্ৰতি-ছকেট অনুমান বা 65,535 কোনো বিশ্বজনীন ধাৰণক্ষমতাৰ প্ৰয়োজন বা Linuxৰ ওপৰসীমা নহয়।

সেৱা পৰিৱৰ্তনৰ পিছত নতুন প্ৰক্ৰিয়াৰ সীমা অভিপ্ৰেত মানৰ সৈতে তুলনা কৰক। সেইবোৰৰ বহু তলত বিফলতা ঘটিলে, প্ৰকৃততে নিঃশেষিত হোৱা সম্পদটো অনুসন্ধান কৰক।

সম্পৰ্কিত প্ৰবন্ধ