Кіру қабығының 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 өзгеруі үшін қайта іске қосу қажет; орнатылмай қалса, ОЖ-ның жұмсақ шегі мұра етіледі.

Шекті пайдаланушыларға емес, дескрипторларға қарай өлшеңіз. Клиенттер бірнеше сокет ұстай алады, сонымен қатар сыртқа бағытталған қосылымдар, журналдар және көмекші құбырлар да дескриптор жұмсайды. Шекті көтеру әр мүмкін дескриптор үшін бірден тұрақты RAM қорын бөлмей, көбірек тұтынуға мүмкіндік береді. Не ескі сокетке шаққандағы жад бағамы, не 65,535 әмбебап сыйымдылық талабы немесе Linux төбесі емес.

Қызметті өзгерткеннен кейін жаңа процестің шектерін көзделген мәндермен салыстырыңыз. Ақаулар олардан әлдеқайда төмен болса, шын мәнінде сарқылып жатқан ресурсты зерттеңіз.

Қатысты мақалалар