የመግቢያ ሼልውን 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 ጣሪያ አይደለም።

ከአገልግሎቱ ለውጥ በኋላ የአዲሱን ሂደት ገደቦች ከታሰቡት እሴቶች ጋር ያወዳድሩ። ከእነሱ በጣም በታች ውድቀቶች ከተከሰቱ፣ በትክክል የሚያልቀውን ሀብት ይመርምሩ።

ተዛማጅ ጽሑፎች