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 өзгөрүү үчүн кайра баштоо талап кылынат; коюлбай калса, ОСтин жумшак чеги мурасталат.
Чекти колдонуучуларга эмес, дескрипторлорго жараша өлчөңүз. Кардарлар бир нече сокетти кармай алат, ошондой эле сыртка багытталган байланыштар, журналдар жана жардамчы түтүктөр да дескрипторлорду сарптайт. Чекти көтөрүү ар бир мүмкүн болгон дескриптор үчүн дароо туруктуу RAM корутуудан тышкары көбүрөөк керектөөгө жол берет. Эски сокетке карата эстутум баасы да, 65,535 да универсалдуу сыйымдуулук талабы же Linux төбөсү эмес.
Кызматты өзгөрткөндөн кийин жаңы процесстин чектерин көздөлгөн маанилер менен салыштырыңыз. Жаңылыштыктар алардан кыйла төмөн болсо, чындап бүтүп жаткан ресурсту изилдеңиз.