حذف کش NGINX خطاهای مهم لغو پیوند را در گزارش خطا قرار می دهد
منتشر شده: ۱۵ فوریهٔ ۲۰۲۵ ساعت ۱۱:۲۵:۱۵ (UTC)
این مقاله توضیح می دهد که چگونه می توان موارد را از حافظه پنهان NGINX حذف کرد بدون اینکه فایل های گزارش خود را با پیام های خطا به هم ریخته باشد. اگرچه به طور کلی یک رویکرد توصیه شده نیست، اما ممکن است در برخی موارد لبه مفید باشد.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
اطلاعات این بر اساس حافظه پنهان FastCGI در NGINX 1.4.6 است که در اوبونتو سرور 14.04 x64 اجرا می شود. ممکن است برای نسخه های دیگر معتبر باشد یا نباشد.
(به روز رسانی 2025: در مدت زمان بین نوشتن اصلی و اکنون، چیزهای زیادی تغییر کرده است. سرورها سریعتر و ارزان تر هستند، بنابراین من در واقع رویکردی را که در این توضیح داده شده است توصیه نمی کنم که در آن سعی می کنم انقضای حافظه پنهان را خرد مدیریت کنم تا چند نسل اضافی از محتوای پویا را ذخیره کنم. من محتوا را برای مراجعات بعدی در اینجا می گذارم و در صورتی که کسی واقعا به هر دلیلی به آن نیاز داشته باشد. من تأیید نکرده ام که این هنوز برای نسخه های فعلی NGINX کار می کند، اما فکر می کنم که این کار را می کند).
پس از مهاجرت چندین سایت از آپاچی به NGINX ، من به قابلیت های ذخیره سازی داخلی آن بسیار علاقه مند شده ام ، که در اکثر شرایط بدون دخالت زیاد من بسیار خوب کار می کند.
با این حال، برای یکی از سایت ها، من واقعا به توانایی پاک کردن حافظه پنهان (هم به طور کامل و هم حذف ورودی های فردی) خودم نیاز داشتم. نسخه رایگان انجمن NGINX فقط از انقضای حافظه پنهان مبتنی بر زمان پشتیبانی می کند (یعنی می توانید آن را تنظیم کنید تا بررسی کنید که آیا چیزی بعد از یک ساعت، یک روز و غیره تغییر کرده است یا خیر). اما اگر هیچ راه قابل اعتمادی برای تعیین زمان تغییر یک منبع خاص از قبل وجود نداشته باشد، چه؟ به عنوان مثال، من نمی دانم که آیا یک ساعت، یک روز یا یک سال طول می کشد تا برگردم و چیزی را در این ویرایش کنم - و چرا اگر ذخیره سازی برای یک روز خوب بود، فقط یک ساعت حافظه پنهان کنید؟
اینجاست که توانایی پاک کردن حافظه پنهان به صورت دستی (یا با اطلاع دادن به برنامه وب شما به NGINX که چیزی باید پاک شود) مورد نیاز است. افرادی که پشت NGINX هستند به وضوح از نیاز به این امر آگاه هستند زیرا این ویژگی در نسخه پولی محصول آنها پشتیبانی می شود - اما در حالی که آنها مطمئنا حق دارند مجوز خود را به هر شکلی که می خواهند تنظیم کنند، قیمت برای من کمی گران است، زمانی که این عملکرد تنها ویژگی پولی است که واقعا به آن نیاز دارم.
خوشبختانه، به نظر می رسد که شما فقط می توانید فایل ها را از دایرکتوری کش خودتان حذف کنید و NGINX این را انتخاب می کند و یک نسخه جدید را بدون مشکل از بک اند شما دریافت می کند. با این حال، اگر این کار را بدون تغییر پیکربندی خود انجام دهید، احتمالا پس از مدتی مجموعه ای از پیام های مشابه این پیام را در گزارش خطای خود مشاهده خواهید کرد:
به نظر می رسد که این خطاها زمانی رخ می دهد که خود NGINX سعی می کند ورودی های کش را پس از زمان مشخص شده توسط پارامتر غیرفعال دستورالعمل fastcgi_cache_path حذف کند. پیش فرض برای این فقط 10 دقیقه است، اما می توانید آن را روی هر مقداری که می خواهید تنظیم کنید. اگر آن را مثلا 10 سال تنظیم کنید، احتمالا بعید است که سرور را در این مدت مجددا راه اندازی نکرده باشید، بنابراین شاخص کلیدی در حافظه در این مدت پاک می شود. اگر این کار را انجام دهید، آیا باید مطمئن شوید که حافظه پنهان را خودتان پاک کرده اید، NGINX دیگر این کار را برای شما انجام نمی دهد.
به نظر من واقعا عجیب است که این یک خطای مهم در نظر گرفته می شود که یک ورودی کش را نمی توان حذف کرد زیرا وجود ندارد. این واقعیت که طبقه بندی شدت آن بسیار زیاد است به این معنی است که خلاص شدن از شر آن فقط با نادیده گرفتن ورودی های گزارش زیر یک آستانه خاص غیرممکن است. به محض اینکه یک نسخه جدید از بک اند آورده شود، مدخل دوباره وجود خواهد داشت، بنابراین به نظر من این باید حداکثر یک هشدار باشد.
حالا، اگر ورودی کش به دلیل مشکلات مربوط به مجوزها یا موارد سوم قابل حذف نباشد، این یک خطای جدی خواهد بود، زیرا ممکن است باعث شود NGINX مدت ها پس از زمان انقضا به ارائه محتوای ذخیره شده در حافظه پنهان ادامه دهد، اما به نظر نمی رسد که فرآیند پاکسازی این تمایز را ایجاد کند.