დაგეგმეთ NGINX პროქსი სოკეტები worker_connections-ის გაზრდამდე
პროქსირებული კავშირი ჩვეულებრივ იკავებს კლიენტისა და upstream-ის სოკეტებს; განასხვავეთ worker-ის კავშირების ლიმიტი სერვისის ფაილის დესკრიპტორების ლიმიტისგან.
ერთი ხანგრძლივი პროქსირებული კავშირი ჩვეულებრივ იკავებს ორ სოკეტს: კლიენტისას და upstream-ისას. worker_connections ორივე მხარეს ითვლის. ამიტომ მისი worker_processes-ზე გამრავლება პროქსის მომხმარებლებისთვის სიმძლავრის დაპირებას არ იძლევა.
როცა კავშირები ვერ ხერხდება, მიჰყევით მოხსენებულ ლიმიტს:
| მტკიცებულება | შესამოწმებელი პარამეტრი ან პროცესის მდგომარეობა |
|---|---|
| worker_connections-ის ამოწურვა | worker-ის კავშირების ბიუჯეტი, upstream სოკეტების ჩათვლით |
| ოპერაციული სისტემის შეტყობინება „ძალიან ბევრი ღია ფაილი“ | ფაილის დესკრიპტორების ლიმიტი, რომელსაც სერვისის ფაქტობრივი პროცესი მემკვიდრეობით იღებს |
მოსმენის სოკეტები, ლოგები და სხვა ღია ფაილებიც მოიხმარენ დესკრიპტორებს. კავშირების ხელახალი გამოყენება და ტრაფიკის ნარევი ცვლის მომხმარებლებსა და სოკეტებს შორის კავშირს.
worker_rlimit_nofile worker-ის ლიმიტებს გარემოს ნებართვების ფარგლებში ასწორებს. systemd ერთეულს შეუძლია LimitNOFILE-ის დაყენება; ინტერაქტიული გარსის ulimit მოქმედ სერვისს არ ცვლის.
განსაზღვრეთ ლიმიტები დატვირთვის მიხედვით და შეამოწმეთ, ვინ მოიხმარს მათ. მოულოდნელმა კლიენტებმა ან განმეორებით წარუმატებელმა upstream კავშირებმა შეიძლება ადრე საკმარისი ბიუჯეტი ამოწუროს. პროცესების უფრო დიდი რაოდენობა ან მეხსიერების ლიმიტი დესკრიპტორების ნაკლოვანებას არ ასწორებს.