Squid-ის ფაილის დესკრიპტორების რეალური ლიმიტის დადგენა
წაიკითხეთ მომუშავე პროქსის პროცესის ლიმიტები, სანამ შეცვლით PAM-ის პარამეტრებს ან კოპირებთ ფიქსირებულ nofile მნიშვნელობას სიმძლავრის რეცეპტიდან.
შეამოწმეთ მომუშავე დემონი, სანამ დაეყრდნობით შესვლის გარსის 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-ის ცვლილებებს მხოლოდ იმიტომ, რომ ადმინისტრატორმა ფაილი შეცვალა. გამოიყენეთ სერვისისთვის სპეციფიკური drop-in, როცა მისი systemd ლიმიტის შეცვლა მიზანშეწონილია. Squid-ის დოკუმენტაციით max_filedescriptors-ის შეცვლას გადატვირთვა სჭირდება; დაუყენებელი დარჩენისას მემკვიდრეობით მიიღება OS-ის რბილი ლიმიტი.
განსაზღვრეთ ლიმიტი დესკრიპტორებისთვის და არა მომხმარებლებისთვის. კლიენტებს შეუძლიათ რამდენიმე სოკეტის შენახვა, ასევე გამავალი კავშირები, ჟურნალები და დამხმარე მილები დესკრიპტორებს მოიხმარენ. ლიმიტის გაზრდა მეტ მოხმარებას იძლევა იმის გარეშე, რომ დაუყოვნებლივ დაირეზერვოს ფიქსირებული RAM ყოველი შესაძლო დესკრიპტორისთვის. არც ძველი მეხსიერების შეფასება სოკეტზე და არც 65,535 არ არის უნივერსალური სიმძლავრის მოთხოვნა ან Linux-ის ჭერი.
სერვისის ცვლილების შემდეგ შეადარეთ ახალი პროცესის ლიმიტები განზრახულ მნიშვნელობებს. თუ ჩავარდნები ხდება მათზე მნიშვნელოვნად დაბლა, გამოიკვლიეთ რეალურად ამოწურული რესურსი.