လော့ဂ်အင် shell ၏ ulimit -n ကို မယုံကြည်မီ လည်ပတ်နေသော daemon ကို စစ်ဆေးပါ။ squid.service အသုံးပြုသော တပ်ဆင်မှုအတွက် ဤသို့ စတင်ပါ-

systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service

အမှန်တကယ် လုပ်ငန်းစဉ် ID ဖြင့် /proc/PID/limits ကို ဖတ်ပါ။ လုပ်ငန်းစဉ်များစွာ ဖြန့်ကျက်မှုတွင် သက်ဆိုင်ရာ worker ကိုလည်း စစ်ဆေးပါ။ ဖွဲ့စည်းမှုတွင် သိမ်းထားသော တန်ဖိုးသည် ဤလုပ်ငန်းစဉ် ထိုတန်ဖိုးကို အမွေရခဲ့သည်ဟူသော သက်သေမဟုတ်ပါ။

ထိန်းချုပ်မှုအတိုင်းအတာ
Shell ulimit နှင့် PAM limits.confShell ၏ အဆက်အနွယ်များ သို့မဟုတ် PAM ဆက်တင်ကို အမှန်တကယ် အသုံးပြုသော ဆက်ရှင်များ
systemd LimitNOFILE=ထိုဝန်ဆောင်မှု၏ အရင်းအမြစ်မူဝါဒအောက်တွင် စတင်ခဲ့သော လုပ်ငန်းစဉ်များ
Squid max_filedescriptors (ပံ့ပိုးထားလျှင်)စက်လည်ပတ်ရေးစနစ်၏ ကန့်သတ်ချက်များအတွင်း အပလီကေးရှင်း ကန့်သတ်ချက်

စီမံခန့်ခွဲသူက ဖိုင်ကို ပြောင်းလိုက်ရုံဖြင့် စနစ်ဝန်ဆောင်မှုသည် PAM ပြင်ဆင်မှုများကို လက်ခံမည်မဟုတ်ပါ။ ၎င်း၏ systemd ကန့်သတ်ချက်ကို ပြောင်းလဲရန် သင့်လျော်ပါက ဝန်ဆောင်မှုသီးသန့် drop-in ကို အသုံးပြုပါ။ max_filedescriptors ကို ပြောင်းလဲရန် ပြန်လည်စတင်ရန် လိုအပ်ကြောင်း Squid က မှတ်တမ်းတင်ထားသည်။ မသတ်မှတ်ဘဲ ထားပါက OS ၏ ပျော့ကန့်သတ်ချက်ကို အမွေရမည်။

ကန့်သတ်ချက်ကို အသုံးပြုသူများအတွက် မဟုတ်ဘဲ ဖော်ပြချက်များအတွက် တွက်ချက်ပါ။ ဖောက်သည်များသည် socket အများအပြား ကိုင်ထားနိုင်သည်၊ အပြင်ထွက် ချိတ်ဆက်မှုများ၊ မှတ်တမ်းများနှင့် အကူအညီပိုက်များလည်း ဖော်ပြချက်များကို သုံးစွဲသည်။ ကန့်သတ်ချက်ကို မြှင့်ခြင်းဖြင့် ဖြစ်နိုင်သော ဖော်ပြချက်တစ်ခုစီအတွက် ပုံသေ RAM ကို ချက်ချင်း မသီးသန့်ထားဘဲ ပိုမို သုံးစွဲနိုင်စေသည်။ socket တစ်ခုစီအတွက် မှတ်ဉာဏ် ခန့်မှန်းချက်ဟောင်းလည်းဖြစ်၊ 65,535 လည်းဖြစ်၊ တစ်ကမ္ဘာလုံးဆိုင်ရာ စွမ်းရည်လိုအပ်ချက် သို့မဟုတ် Linux ၏ အမြင့်ဆုံးကန့်သတ်ချက် မဟုတ်ပါ။

ဝန်ဆောင်မှု ပြောင်းလဲပြီးနောက် လုပ်ငန်းစဉ်အသစ်၏ ကန့်သတ်ချက်များကို ရည်ရွယ်ထားသော တန်ဖိုးများနှင့် နှိုင်းယှဉ်ပါ။ ထိုတန်ဖိုးများထက် အလွန်နိမ့်သော နေရာတွင် မအောင်မြင်မှုများ ဖြစ်ပေါ်ပါက အမှန်တကယ် ကုန်ခမ်းနေသော အရင်းအမြစ်ကို စုံစမ်းပါ။

ဆက်စပ်ဆောင်းပါးများ