د Squid د فایل ډیسکریپټر ریښتینې حد موندل
د PAM تنظیماتو د بدلولو یا د ظرفیت له ترکیب څخه د ثابت nofile ارزښت د کاپي کولو دمخه د روان پروکسي د پروسې حدود ولولئ.
د ننوتلو شیل ulimit -n ته د باور کولو دمخه روان ډیمون وګورئ. د هغې نصب لپاره چې squid.service کاروي، له دې سره پیل وکړئ:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service/proc/PID/limits د پروسې د ریښتیني ID سره ولولئ. په څو پروسیز وړاندې کولو کې، اړوند کارګر هم وګورئ. په ترتیباتو کې ساتل شوی ارزښت دا ثبوت نه دی چې دې پروسې هغه په میراث کې اخیستی دی.
| کنټرول | حدود |
|---|---|
شیل ulimit او PAM limits.conf | د شیل اولادونه یا هغه ناستې چې په رښتیا د PAM تنظیم کاروي |
systemd LimitNOFILE= | هغه پروسې چې د هغې خدمت د سرچینو پالیسۍ لاندې پیل شوې |
Squid max_filedescriptors، چیرې چې ملاتړ کیږي | د عملیاتي سیسټم د محدودیتونو په داخل کې د اپلیکیشن حد |
یو سیسټم خدمت یوازې د دې لپاره چې یو مدیر فایل بدل کړی، د PAM سمونې نه مني. کله چې د systemd حد بدلول مناسب وي، د خدمت ځانګړی drop-in وکاروئ. Squid مستند کوي چې max_filedescriptors د بدلولو لپاره بیا پیل ته اړتیا لري؛ که تنظیم نه شي، د OS نرم حد په میراث کې راځي.
حد د کاروونکو لپاره نه، بلکې د ډیسکریپټرونو لپاره اندازه کړئ. پیریدونکي کولی شي څو ساکټونه وساتي, او بهر ته وتونکي اړیکې، لاګونه او مرستندویه نلکې هم ډیسکریپټرونه کاروي. د حد لوړول د هر ممکن ډیسکریپټر لپاره سمدلاسه ثابته RAM نه ساتلو سره ډیر مصرف ته اجازه ورکوي. نه زوړ د هر ساکټ حافظې اټکل او نه 65,535 یو نړیوال ظرفیت غوښتنه یا د Linux سرحد دی.
د خدمت له بدلون وروسته، د نوي پروسې حدود د اټکل شوو ارزښتونو سره پرتله کړئ. که پاتې راتلل ډیر ښکته واقع شي، هغه سرچینه وڅیړئ چې واقعاً ختمیږي.