Miklix

Η διαγραφή της προσωρινής μνήμης NGINX θέτει κρίσιμα σφάλματα αποσύνδεσης στο αρχείο καταγραφής σφαλμάτων

Δημοσιεύθηκε: 15 Φεβρουαρίου 2025 στις 11:23:53 π.μ. UTC

Αυτό το άρθρο εξηγεί πώς μπορείτε να διαγράψετε στοιχεία από την προσωρινή μνήμη του NGINX χωρίς να έχετε τα αρχεία καταγραφής σας γεμάτα με μηνύματα σφάλματος. Αν και δεν είναι γενικά μια συνιστώμενη προσέγγιση, μπορεί να είναι χρήσιμη σε ορισμένες περιπτώσεις ακμής.


Αυτή η σελίδα μεταφράστηκε μηχανικά από τα αγγλικά, προκειμένου να είναι προσβάσιμη σε όσο το δυνατόν περισσότερους ανθρώπους. Δυστυχώς, η αυτόματη μετάφραση δεν είναι ακόμη μια τελειοποιημένη τεχνολογία, οπότε μπορεί να προκύψουν λάθη. Αν προτιμάτε, μπορείτε να δείτε την πρωτότυπη αγγλική έκδοση εδώ:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Οι πληροφορίες σε αυτήν την ανάρτηση βασίζονται στην προσωρινή αποθήκευση FastCGI στο NGINX 1.4.6 που εκτελείται στον διακομιστή Ubuntu 14.04 x64. Μπορεί να ισχύει ή να μην ισχύει για άλλες εκδόσεις.

(Ενημέρωση 2025: Στο διάστημα που μεσολάβησε από τότε που έγραψα την αρχική ανάρτηση μέχρι τώρα, πολλά έχουν αλλάξει. Οι διακομιστές είναι ταχύτεροι και φθηνότεροι, οπότε στην πραγματικότητα δεν θα συνιστούσα την προσέγγιση που περιγράφεται σε αυτήν την ανάρτηση όπου προσπαθώ να μικρο-διαχειριστώ τη λήξη της προσωρινής μνήμης μόνο για να εξοικονομήσω μερικές επιπλέον γενιές δυναμικού περιεχομένου. Θα αφήσω το περιεχόμενο εδώ για μελλοντική αναφορά και σε περίπτωση που κάποιος το χρειάζεται πραγματικά για οποιονδήποτε λόγο. Δεν έχω επιβεβαιώσει ότι αυτό εξακολουθεί να λειτουργεί για τις τρέχουσες εκδόσεις του NGINX, όμως, αλλά νομίζω ότι το κάνει).

Μετά τη μετεγκατάσταση αρκετών ιστότοπων από το Apache στο NGINX, μου αρέσουν πολύ οι ενσωματωμένες δυνατότητες προσωρινής αποθήκευσης, οι οποίες λειτουργούν εξαιρετικά καλά στις περισσότερες περιπτώσεις χωρίς μεγάλη παρέμβαση από μένα.

Ωστόσο, για έναν από τους ιστότοπους, χρειαζόμουν πραγματικά τη δυνατότητα να καθαρίσω την προσωρινή μνήμη (τόσο πλήρως όσο και να αφαιρέσω μεμονωμένες καταχωρήσεις) μόνος μου. Η δωρεάν κοινοτική έκδοση του NGINX υποστηρίζει μόνο τη λήξη της προσωρινής μνήμης βάσει χρόνου (δηλαδή μπορείτε να τη ρυθμίσετε για να ελέγξετε αν κάτι έχει αλλάξει μετά από μια ώρα, μια μέρα κ.λπ.). Τι γίνεται όμως αν δεν υπάρχει αξιόπιστος τρόπος προσδιορισμού εκ των προτέρων πότε θα αλλάξει ένας συγκεκριμένος πόρος; Για παράδειγμα, δεν έχω ιδέα αν θα είναι μια ώρα, μια μέρα ή ένα χρόνο πριν επιστρέψω και επεξεργαστώ κάτι σε αυτήν την ανάρτηση - και γιατί μόνο προσωρινή μνήμη για μια ώρα εάν η προσωρινή αποθήκευση για μια ημέρα θα ήταν εντάξει;

Εδώ απαιτείται η δυνατότητα εκκαθάρισης της προσωρινής μνήμης με μη αυτόματο τρόπο (ή έχοντας την εφαρμογή ιστού σας να ειδοποιήσει το NGINX ότι κάτι πρέπει να καθαριστεί). Οι άνθρωποι πίσω από το NGINX γνωρίζουν σαφώς την ανάγκη για αυτό, καθώς η δυνατότητα υποστηρίζεται στην πληρωμένη έκδοση του προϊόντος τους - αλλά ενώ σίγουρα δικαιούνται να ρυθμίσουν την άδειά τους με όποιον τρόπο θέλουν, η τιμή είναι λίγο απότομη για μένα όταν αυτή η λειτουργία είναι η μόνη δυνατότητα επί πληρωμή που χρειάζομαι πραγματικά.

Ευτυχώς, αποδεικνύεται ότι μπορείτε απλώς να διαγράψετε μόνοι σας αρχεία από τον κατάλογο προσωρινής μνήμης και το NGINX θα το πάρει και θα πάρει ένα νέο αντίγραφο από το back-end σας χωρίς προβλήματα. Ωστόσο, εάν το κάνετε αυτό χωρίς να τροποποιήσετε τη διαμόρφωσή σας, είναι πιθανό να δείτε μια ολόκληρη δέσμη μηνυμάτων παρόμοιων με αυτό στο αρχείο καταγραφής σφαλμάτων μετά από λίγο:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

Φαίνεται ότι αυτά τα σφάλματα παρουσιάζονται όταν το ίδιο το NGINX προσπαθεί να διαγράψει καταχωρήσεις προσωρινής μνήμης μετά το χρόνο που καθορίζεται από την ανενεργή παράμετρο της οδηγίας fastcgi_cache_path . Η προεπιλογή για αυτό είναι μόνο 10 λεπτά, αλλά μπορείτε να το ορίσετε σε όποια τιμή θέλετε. Εάν το ορίσετε σε, ας πούμε, 10 χρόνια, είναι πιθανώς απίθανο να μην έχετε επανεκκινήσει τον διακομιστή στο μεταξύ, οπότε το ευρετήριο κλειδιών στη μνήμη θα είχε διαγραφεί στο μεταξύ. Εάν το κάνετε αυτό, πρέπει να βεβαιωθείτε ότι έχετε καθαρίσει μόνοι σας την προσωρινή μνήμη, το NGINX δεν θα το κάνει πλέον για εσάς.

Θεωρώ πραγματικά περίεργο το γεγονός ότι θεωρείται κρίσιμο σφάλμα ότι μια καταχώρηση προσωρινής μνήμης δεν μπορεί να διαγραφεί επειδή δεν υπάρχει. Το γεγονός ότι η ταξινόμηση της σοβαρότητάς του είναι τόσο υψηλή σημαίνει ότι είναι αδύνατο να απαλλαγούμε απλώς αγνοώντας τις καταχωρήσεις καταγραφής κάτω από ένα ορισμένο όριο. Μόλις ληφθεί ένα νέο αντίγραφο από το back-end, η καταχώρηση θα υπάρχει ξανά, οπότε αυτό θα πρέπει να είναι μια προειδοποίηση το πολύ, κατά τη γνώμη μου.

Τώρα, εάν η καταχώριση προσωρινής μνήμης δεν μπορούσε να διαγραφεί λόγω προβλημάτων με τα δικαιώματα ή κάτι τρίτο, αυτό θα ήταν ένα κρίσιμο σφάλμα, επειδή μπορεί να κάνει το NGINX να συνεχίσει να εξυπηρετεί αποθηκευμένο περιεχόμενο πολύ μετά τη λήξη του, αλλά η διαδικασία εκκαθάρισης δεν φαίνεται να κάνει αυτή τη διάκριση.

Μοιραστείτε το στο BlueskyΚοινή χρήση στο FacebookΚοινοποίηση στο LinkedInΜοιραστείτε το στο TumblrΚοινοποίηση στο XΚοινοποίηση στο LinkedInΚαρφιτσώστε στο Pinterest

Μίκελ Μπανγκ Κρίστενσεν

Σχετικά με τον συγγραφέα

Μίκελ Μπανγκ Κρίστενσεν
Ο Μιχαήλ είναι ο δημιουργός και ιδιοκτήτης του miklix.com. Έχει πάνω από 20 χρόνια εμπειρίας ως επαγγελματίας προγραμματιστής υπολογιστών/προγραμματιστής λογισμικού και σήμερα εργάζεται με πλήρη απασχόληση σε μια μεγάλη ευρωπαϊκή εταιρεία πληροφορικής. Όταν δεν ασχολείται με το ιστολόγιο, αφιερώνει τον ελεύθερο χρόνο του σε ένα ευρύ φάσμα ενδιαφερόντων, χόμπι και δραστηριοτήτων, τα οποία μπορεί σε κάποιο βαθμό να αντικατοπτρίζονται στην ποικιλία των θεμάτων που καλύπτονται σε αυτόν τον ιστότοπο.