Βρίσκοντας το πραγματικό όριο περιγραφικών αρχείων του Squid
Διαβάστε τα όρια διεργασίας του εκτελούμενου proxy πριν αλλάξετε ρυθμίσεις PAM ή αντιγράψετε μια σταθερή τιμή nofile από μια συνταγή χωρητικότητας.
Εξετάστε τον εκτελούμενο δαίμονα προτού εμπιστευτείτε το ulimit -n του κελύφους σύνδεσης. Για εγκατάσταση που χρησιμοποιεί squid.service, ξεκινήστε με:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceΔιαβάστε το /proc/PID/limits με το πραγματικό αναγνωριστικό διεργασίας. Σε ανάπτυξη πολλών διεργασιών, ελέγξτε και τον σχετικό worker. Μια τιμή αποθηκευμένη στη διαμόρφωση δεν αποδεικνύει ότι αυτή η διεργασία την κληρονόμησε.
| Έλεγχος | Εύρος |
|---|---|
Κέλυφος ulimit και PAM limits.conf | Οι απόγονοι του κελύφους ή οι συνεδρίες που χρησιμοποιούν πραγματικά τη ρύθμιση PAM |
systemd LimitNOFILE= | Διεργασίες που ξεκίνησαν βάσει της πολιτικής πόρων αυτής της υπηρεσίας |
Squid max_filedescriptors, όπου υποστηρίζεται | Όριο εφαρμογής εντός των περιορισμών του λειτουργικού συστήματος |
Μια υπηρεσία συστήματος δεν υιοθετεί αλλαγές PAM μόνο επειδή ένας διαχειριστής άλλαξε το αρχείο. Χρησιμοποιήστε drop-in ειδικό για την υπηρεσία όταν η αλλαγή του ορίου systemd είναι σκόπιμη. Το Squid τεκμηριώνει ότι το max_filedescriptors απαιτεί επανεκκίνηση για αλλαγή· αν μείνει ανορισμένο, κληρονομεί το μαλακό όριο του λειτουργικού συστήματος.
Διαστασιολογήστε το όριο με βάση τα περιγραφικά, όχι τους χρήστες. Οι πελάτες μπορούν να κρατούν πολλαπλά sockets, και οι εξερχόμενες συνδέσεις, τα αρχεία καταγραφής και οι βοηθητικές δίοδοι καταναλώνουν επίσης περιγραφικά. Η αύξηση του ορίου επιτρέπει μεγαλύτερη κατανάλωση χωρίς να δεσμεύει αμέσως σταθερή ποσότητα RAM ανά πιθανό περιγραφικό. Ούτε μια παλιά εκτίμηση μνήμης ανά socket ούτε το 65,535 αποτελούν καθολική απαίτηση χωρητικότητας ή όριο του Linux.
Μετά την αλλαγή της υπηρεσίας, συγκρίνετε τα όρια της νέας διεργασίας με τις επιδιωκόμενες τιμές. Αν εμφανίζονται αποτυχίες πολύ κάτω από αυτά, ερευνήστε τον πόρο που εξαντλείται πραγματικά.