Miklix

Menghapus Cache NGINX Menempatkan Kesalahan Putus Tautan Kritis di Log Kesalahan

Diterbitkan: 15 Februari 2025 pukul 10.56.42 UTC

Artikel ini menjelaskan cara menghapus item dari cache NGINX tanpa membuat file log Anda dipenuhi dengan pesan kesalahan. Meskipun secara umum bukan pendekatan yang direkomendasikan, ini mungkin berguna dalam beberapa kasus tertentu.


Halaman ini diterjemahkan oleh mesin dari bahasa Inggris agar dapat diakses oleh sebanyak mungkin orang. Sayangnya, terjemahan mesin belum merupakan teknologi yang sempurna, sehingga kesalahan dapat terjadi. Jika Anda mau, Anda dapat melihat versi bahasa Inggris aslinya di sini:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Informasi dalam tulisan ini didasarkan pada cache FastCGI pada NGINX 1.4.6 yang berjalan pada Ubuntu Server 14.04 x64. Ini mungkin atau mungkin tidak berlaku untuk versi lain.

(Pembaruan 2025: Dalam kurun waktu antara saya menulis artikel pertama dan sekarang, banyak yang telah berubah. Server lebih cepat dan lebih murah, jadi saya sebenarnya tidak akan merekomendasikan pendekatan yang dijelaskan dalam posting ini di mana saya mencoba mengelola cache secara mikro hanya untuk menyimpan beberapa generasi ekstra dari konten dinamis. Saya akan meninggalkan konten di sini untuk referensi di masa depan dan jika seseorang benar-benar membutuhkannya untuk alasan apa pun. Saya belum memastikan bahwa ini masih berfungsi untuk versi NGINX saat ini, tetapi saya rasa masih berfungsi).

Setelah memigrasikan beberapa situs dari Apache ke NGINX, saya menjadi sangat menyukai kemampuan caching bawaannya, yang bekerja dengan sangat baik di sebagian besar situasi tanpa banyak campur tangan saya.

Namun, untuk salah satu situs, saya benar-benar membutuhkan kemampuan untuk menghapus cache (baik sepenuhnya maupun menghapus entri individual) sendiri. Edisi komunitas gratis dari NGINX hanya mendukung kedaluwarsa cache berdasarkan waktu (yaitu Anda dapat mengaturnya untuk memeriksa apakah ada sesuatu yang berubah setelah satu jam, satu hari, dll.). Namun, bagaimana jika tidak ada cara yang dapat diandalkan untuk menentukan sebelumnya kapan sumber daya tertentu akan berubah? Sebagai contoh, saya tidak tahu apakah akan ada satu jam, satu hari, atau satu tahun sebelum saya kembali dan mengedit sesuatu dalam posting ini - dan mengapa hanya menyimpan cache selama satu jam jika menyimpan cache selama satu hari saja sudah cukup?

Di sinilah kemampuan untuk menghapus cache secara manual (atau dengan meminta aplikasi web Anda memberi tahu NGINX bahwa ada sesuatu yang harus dibersihkan) diperlukan. Orang-orang di belakang NGINX jelas menyadari kebutuhan akan hal ini karena fitur ini didukung dalam versi berbayar dari produk mereka - tetapi meskipun mereka tentu saja berhak untuk mengatur lisensi mereka dengan cara apa pun yang mereka inginkan, harganya agak mahal bagi saya ketika fungsi ini adalah satu-satunya fitur berbayar yang benar-benar saya perlukan.

Untungnya, ternyata Anda bisa menghapus sendiri berkas-berkas dari direktori cache dan NGINX akan mengetahui hal ini dan mengambil salinan baru dari back-end Anda tanpa hambatan. Namun, jika Anda melakukan ini tanpa mengubah konfigurasi Anda, Anda mungkin akan melihat sejumlah besar pesan yang mirip dengan pesan ini di log kesalahan Anda setelah beberapa saat:

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

Tampaknya kesalahan ini terjadi ketika NGINX sendiri mencoba menghapus entri cache setelah waktu yang ditentukan oleh parameter inactive pada direktif fastcgi_cache_path. Standarnya hanya 10 menit, tetapi Anda dapat mengaturnya ke nilai berapa pun yang Anda inginkan. Jika Anda mengaturnya ke, katakanlah, 10 tahun, kemungkinan besar Anda belum me-restart server sehingga indeks kunci dalam memori akan terhapus sementara itu. Jika Anda melakukan ini, apakah Anda perlu memastikan bahwa Anda menghapus cache sendiri, NGINX tidak akan lagi melakukannya untuk Anda.

Saya merasa sangat aneh bahwa entri cache tidak dapat dihapus karena dianggap sebagai kesalahan kritis, padahal entri cache tidak ada. Fakta bahwa klasifikasi tingkat keparahannya sangat tinggi berarti tidak mungkin untuk menyingkirkannya hanya dengan mengabaikan entri log di bawah ambang batas tertentu. Segera setelah salinan baru diambil dari back-end, entri tersebut akan ada lagi, jadi ini seharusnya menjadi peringatan, menurut pendapat saya.

Sekarang, jika entri cache tidak dapat dihapus karena masalah dengan izin atau hal lain, itu akan menjadi kesalahan kritis, karena itu mungkin membuat NGINX terus menyajikan konten yang ditembolok lama setelah waktu kedaluwarsanya, tetapi proses pembersihan tampaknya tidak membuat perbedaan ini.

Bagikan di BlueskyBagikan di FacebookBagikan di LinkedInBagikan di TumblrBagikan di XBagikan di LinkedInPin di Pinterest

Mikkel Bang Christensen

Tentang Penulis

Mikkel Bang Christensen
Mikkel adalah pencipta dan pemilik miklix.com. Dia memiliki lebih dari 20 tahun pengalaman sebagai pemrogram komputer profesional/pengembang perangkat lunak dan saat ini bekerja penuh waktu di sebuah perusahaan IT besar di Eropa. Ketika tidak menulis blog, ia menghabiskan waktu luangnya untuk beragam minat, hobi, dan kegiatan, yang mungkin sampai batas tertentu tercermin dalam berbagai topik yang dibahas di situs web ini.