NGINX ਕੈਸ਼ ਨੂੰ ਮਿਟਾਉਣ ਨਾਲ ਗਲਤੀ ਲਾਗ ਵਿੱਚ ਗੰਭੀਰ ਅਨਲਿੰਕ ਗਲਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ।
ਪ੍ਰਕਾਸ਼ਿਤ: 19 ਮਾਰਚ 2025 9:28:04 ਬਾ.ਦੁ. UTC
ਇਹ ਲੇਖ ਦੱਸਦਾ ਹੈ ਕਿ NGINX ਦੇ ਕੈਸ਼ ਤੋਂ ਆਈਟਮਾਂ ਨੂੰ ਕਿਵੇਂ ਮਿਟਾਉਣਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੀਆਂ ਲੌਗ ਫਾਈਲਾਂ ਨੂੰ ਗਲਤੀ ਸੁਨੇਹਿਆਂ ਨਾਲ ਭਰੇ ਹੋਏ। ਹਾਲਾਂਕਿ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਇੱਕ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਇਹ ਕੁਝ ਐਜ ਮਾਮਲਿਆਂ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
ਇਸ ਪੋਸਟ ਵਿੱਚ ਦਿੱਤੀ ਜਾਣਕਾਰੀ FastCGI ਕੈਸ਼ਿੰਗ 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਜੋ NGINX 1.4.6 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ ਜੋ Ubuntu Server 14.04 x64 'ਤੇ ਹੈ। ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੋਰ ਵਰਜਨਾਂ ਲਈ ਮਾਨਯਤਾ ਰੱਖਦੀ ਹੋਵੇ।
(ਅਪਡੇਟ 2025: ਜਦੋਂ ਮੈਂ ਅਸਲ ਪੋਸਟ ਲਿਖੀ ਸੀ ਅਤੇ ਹੁਣ ਦੇ ਵਿਚਕਾਰ ਕਾਫੀ ਕੁਝ ਬਦਲ ਗਿਆ ਹੈ। ਸਰਵਰ ਤੇਜ਼ ਅਤੇ ਸਸਤੇ ਹੋ ਗਏ ਹਨ, ਇਸ ਲਈ ਮੈਂ ਦਰਅਸਲ ਉਸ ਤਰੀਕੇ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰਾਂਗਾ ਜੋ ਮੈਂ ਇਸ ਪੋਸਟ ਵਿੱਚ ਵਰਣਿਤ ਕੀਤਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮੈਂ ਕੈਸ਼ ਸਮਾਪਤੀ ਨੂੰ ਮਾਈਕ੍ਰੋ-ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ ਸਿਰਫ ਕੁਝ ਅਤਿਰਿਕਤ ਡਾਇਨਾਮਿਕ ਸਮੱਗਰੀ ਜਨਰੇਸ਼ਨਾਂ ਨੂੰ ਬਚਾਉਣ ਲਈ। ਮੈਂ ਸਮੱਗਰੀ ਇੱਥੇ ਭਵਿੱਖ ਵਿੱਚ ਸੰਦ ਦੇ ਤੌਰ 'ਤੇ ਛੱਡ ਦਿਆਂਗਾ ਅਤੇ ਜੇਕਰ ਕਿਸੇ ਨੂੰ ਇਹ ਕਿਸੇ ਵੀ ਕਾਰਣ ਲਈ ਲੋੜ ਹੋਵੇ। ਮੈਂ ਇਹ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਕਿ ਇਹ ਅਜੇ ਵੀ NGINX ਦੇ ਮੌਜੂਦਾ ਵਰਜਨਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਕਰਦਾ ਹੈ)।
ਕਈ ਸਾਈਟਾਂ ਨੂੰ Apache ਤੋਂ NGINX ਤੇ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੇ ਬਾਅਦ, ਮੈਂ ਇਸਦੀ ਬਿਲਟ-ਇਨ ਕੈਸ਼ਿੰਗ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਬਹੁਤ ਪਸੰਦ ਕੀਤਾ ਹੈ, ਜੋ ਬਿਨਾਂ ਮੇਰੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਜ਼ਿਆਦਾਤਰ ਹਾਲਤਾਂ ਵਿੱਚ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ।
ਹਾਲਾਂਕਿ, ਇੱਕ ਸਾਈਟ ਲਈ, ਮੈਨੂੰ ਕੈਸ਼ ਸਾਫ ਕਰਨ ਦੀ ਯੋਗਤਾ (ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਤੇ ਵਿਅਕਤੀਗਤ ਏਂਟਰੀਆਂ ਨੂੰ ਹਟਾਉਣਾ) ਖੁਦ ਕਰਨੀ ਪਈ। NGINX ਦਾ ਮੁਫਤ ਕਮਿਊਨਿਟੀ ਸੰਸਕਰਨ ਸਿਰਫ ਸਮੇਂ-ਆਧਾਰਿਤ ਕੈਸ਼ ਸਮਾਪਤੀ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਇਹ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਕੁਝ ਘੰਟੇ, ਦਿਨ ਆਦਿ ਬਾਅਦ ਬਦਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ)। ਪਰ ਜੇਕਰ ਕੋਈ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕਾ ਨਾ ਹੋਵੇ ਜਿਸ ਨਾਲ ਅੱਗੇ ਤੋਂ ਜਾਣ ਸਕੀਏ ਕਿ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਸੰਸਾਧਨ ਕਦੋਂ ਬਦਲਣਗੇ? ਉਦਾਹਰਣ ਵਜੋਂ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਇੱਕ ਘੰਟਾ, ਦਿਨ ਜਾਂ ਸਾਲ ਲੱਗੇਗਾ ਜਦੋਂ ਮੈਂ ਆ ਕੇ ਇਸ ਪੋਸਟ ਵਿੱਚ ਕੁਝ ਸੋਧਾਂਗਾ – ਅਤੇ ਜੇਕਰ ਇੱਕ ਦਿਨ ਦੇ ਲਈ ਕੈਸ਼ਿੰਗ ਠੀਕ ਹੋ ਸਕਦੀ ਹੈ ਤਾਂ ਫਿਰ ਸਿਰਫ ਇੱਕ ਘੰਟਾ ਕੈਸ਼ ਕਿਉਂ ਕਰਨਾ?
ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਕੈਸ਼ ਨੂੰ ਦਸਤਵੈਜ਼ੀ ਤੌਰ 'ਤੇ ਸਾਫ ਕਰਨ ਦੀ ਯੋਗਤਾ (ਜਾਂ ਆਪਣੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ NGINX ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ ਕਿ ਕੁਝ ਸਾਫ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ) ਦੀ ਲੋੜ ਹੈ। NGINX ਦੇ ਪਿਛੇ ਲੋਕ ਇਸ ਜ਼ਰੂਰਤ ਨਾਲ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਾਣੂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਫੀਚਰ ਉਨ੍ਹਾਂ ਦੇ ਉਤਪਾਦ ਦੇ ਪੈਡ ਸੰਸਕਰਨ ਵਿੱਚ ਸਮਰਥਿਤ ਹੈ – ਪਰ ਜਦੋਂ ਕਿ ਉਹ ਬਿਲਕੁਲ ਇਸਨੂੰ ਆਪਣੀ ਲਾਇਸੈਂਸਿੰਗ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸੈਟ ਕਰਨ ਦੇ ਹੱਕਦਾਰ ਹਨ, ਕੀਮਤ ਮੈਨੂੰ ਥੋੜੀ ਜ਼ਿਆਦਾ ਮਹਿੰਗੀ ਲੱਗਦੀ ਹੈ ਜਦੋਂ ਇਹ ਫੰਕਸ਼ਨ ਇੱਕੋ ਇਕ ਪੇਡ ਫੀਚਰ ਹੈ ਜੋ ਮੈਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ।
ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਰਫ ਕੈਸ਼ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਫਾਈਲਾਂ ਮਿਟਾ ਸਕਦੇ ਹੋ ਅਤੇ NGINX ਇਸ ਨੂੰ ਚੁੱਕ ਲਵੇਗਾ ਅਤੇ ਤੁਹਾਡੇ ਬੈਕ-ਐਂਡ ਤੋਂ ਇੱਕ ਨਵਾਂ ਨਕਲ ਲਏਗਾ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ। ਹਾਲਾਂਕਿ, ਜੇ ਤੁਸੀਂ ਇਹ ਆਪਣੇ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਬਿਨਾਂ ਸੋਧੇ ਕਰੋ ਤਾਂ ਤੁਸੀਂ ਆਪਣੇ ਐਰਰ ਲਾਗ ਵਿੱਚ ਇੱਕ ਸਮੇਂ ਬਾਅਦ ਕੁਝ ਐਸੀ ਸੁਨੇਹੇ ਵੇਖ ਸਕਦੇ ਹੋ:
ਇਹ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਗਲਤੀਆਂ ਉਨ੍ਹਾਂ ਵਕਤਾਂ ਉਤਪੰਨ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ NGINX ਆਪਣੇ ਆਪ ਕੈਸ਼ ਐਂਟਰੀਆਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ inactive ਪੈਰਾਮੀਟਰ ਦੇ ਦੁਆਰਾ ਦਿਉਂਦੀ ਗਈ ਸਮਾਪਤੀ ਸਮੇਂ ਦੇ ਬਾਅਦ fastcgi_cache_path ਨਿਰਦੇਸ਼। ਇਸਦਾ ਡਿਫੌਲਟ ਸਿਰਫ 10 ਮਿੰਟ ਹੈ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਕੀਮਤ 'ਤੇ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ, ਕਹੋ, 10 ਸਾਲ ਸੈਟ ਕਰ ਦਿਓ, ਤਾਂ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਦਰਮਿਆਨ ਸਰਵਰ ਨੂੰ ਦੁਬਾਰਾ ਰੀਸਟਾਰਟ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਕਿ ਕੀ ਵੈਲੀਡ ਇੰਡੈਕਸ ਮੈਮਰੀ ਵਿੱਚ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਸਾਫ ਹੋ ਗਿਆ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਇਹ ਕਰੋ ਤਾਂ, ਕੀ ਤੁਸੀਂ ਯਕੀਨੀ ਕਰਨਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੈਸ਼ ਖੁਦ ਸਾਫ ਕਰੋ, NGINX ਹੁਣ ਤੁਹਾਡੇ ਲਈ ਇਹ ਨਹੀਂ ਕਰੇਗਾ।
ਮੈਨੂੰ ਇਹ ਸੱਚਮੁੱਚ ਅਜੀਬ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਕੈਸ਼ ਐਂਟਰੀ ਨੂੰ ਹਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਕਿਉਂਕਿ ਇਹ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮਹੱਤਵਪੂਰਣ ਗਲਤੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਸਦੀ ਗੰਭੀਰਤਾ ਦਾ ਵਰਗੀਕਰਨ ਇਸ ਹੱਦ ਤੱਕ ਉੱਚਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਸੇ ਨਿਸ਼ਚਿਤ ਥਰੈਸ਼ਹੋਲਡ ਤੋਂ ਹੇਠਾਂ ਲਾਗ ਇੰਟਰੀਆਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਕੇ ਖਤਮ ਕਰਨਾ ਅਸੰਭਵ ਹੈ। ਜਿਵੇਂ ਹੀ ਇੱਕ ਨਵਾਂ ਨਕਲ ਬੈਕ-ਐਂਡ ਤੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਐਂਟਰੀ ਦੁਬਾਰਾ ਮੌਜੂਦ ਹੋਵੇਗੀ, ਇਸ ਲਈ ਇਹ ਮੇਰੇ ਖਿਆਲ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਇੱਕ ਚਿਤਾਵਨੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਹੁਣ, ਜੇਕਰ ਕੈਸ਼ ਐਂਟਰੀ ਨੂੰ ਦਿਉਂਦੀਆਂ ਅਧਿਕਾਰਾਂ ਜਾਂ ਕੁਝ ਤੀਜੇ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਕਾਰਨ ਹਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਿਆ, ਉਹ ਇੱਕ ਮਹੱਤਵਪੂਰਣ ਗਲਤੀ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ NGINX ਕੈਸ਼ ਕੀਤੀ ਸਮੱਗਰੀ ਨੂੰ ਉਸਦੀ ਸਮਾਪਤੀ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਵੀ ਸੇਵਾ ਦਿੰਦਾ ਰਹੇਗਾ, ਪਰ ਸਾਫ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਭੇਦ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦੀ।