NGINX ಕ್ಯಾಶ್ ಅನ್ನು ಅಳಿಸುವುದರಿಂದ ದೋಷ ಲಾಗ್ ನಲ್ಲಿ ನಿರ್ಣಾಯಕ ಅನ್ ಲಿಂಕ್ ದೋಷಗಳು ಉಂಟಾಗುತ್ತವೆ
ಪ್ರಕಟಣೆ: ಫೆಬ್ರವರಿ 15, 2025 ರಂದು 11:25:37 ಪೂರ್ವಾಹ್ನ UTC ಸಮಯಕ್ಕೆ
ನಿಮ್ಮ ಲಾಗ್ ಫೈಲ್ ಗಳನ್ನು ದೋಷ ಸಂದೇಶಗಳಿಂದ ಗೊಂದಲಗೊಳಿಸದೆ NGINX ನ ಕ್ಯಾಶ್ ನಿಂದ ಐಟಂಗಳನ್ನು ಹೇಗೆ ಅಳಿಸುವುದು ಎಂಬುದನ್ನು ಈ ಲೇಖನವು ವಿವರಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಶಿಫಾರಸು ಮಾಡಲಾದ ವಿಧಾನವಲ್ಲದಿದ್ದರೂ, ಇದು ಕೆಲವು ಅಂಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉಪಯುಕ್ತವಾಗಬಹುದು.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
ಈ ಪೋಸ್ಟ್ ನಲ್ಲಿರುವ ಮಾಹಿತಿಯು ಉಬುಂಟು ಸರ್ವರ್ 14.04 x 64 ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ NGINX 1.4.6 ನಲ್ಲಿ ಫಾಸ್ಟ್ ಸಿಜಿಐ ಕ್ಯಾಚಿಂಗ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಇದು ಇತರ ಆವೃತ್ತಿಗಳಿಗೆ ಮಾನ್ಯವಾಗಿರಬಹುದು ಅಥವಾ ಇಲ್ಲದಿರಬಹುದು.
(ಅಪ್ಡೇಟ್ 2025: ನಾನು ಮೂಲ ಪೋಸ್ಟ್ ಬರೆದ ಮತ್ತು ಈಗ, ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ. ಸರ್ವರ್ ಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಅಗ್ಗವಾಗಿವೆ, ಆದ್ದರಿಂದ ಈ ಪೋಸ್ಟ್ ನಲ್ಲಿ ವಿವರಿಸಿದ ವಿಧಾನವನ್ನು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ, ಅಲ್ಲಿ ನಾನು ಕೆಲವು ಹೆಚ್ಚುವರಿ ಪೀಳಿಗೆಯ ಕ್ರಿಯಾತ್ಮಕ ವಿಷಯವನ್ನು ಉಳಿಸಲು ಕ್ಯಾಶ್ ಎಕ್ಸ್ ಪೈರಿಯನ್ನು ಮೈಕ್ರೋ-ಮ್ಯಾನೇಜ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಭವಿಷ್ಯದ ಉಲ್ಲೇಖಕ್ಕಾಗಿ ಮತ್ತು ಯಾರಿಗಾದರೂ ನಿಜವಾಗಿಯೂ ಯಾವುದೇ ಕಾರಣಕ್ಕಾಗಿ ಅಗತ್ಯವಿದ್ದರೆ ನಾನು ವಿಷಯವನ್ನು ಇಲ್ಲಿ ಬಿಡುತ್ತೇನೆ. ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳಿಗೆ ಇದು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ದೃಢಪಡಿಸಿಲ್ಲ, ಆದರೆ ಅದು ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ).
ಅಪಾಚೆಯಿಂದ ಎನ್ಜಿಎನ್ಎಕ್ಸ್ಗೆ ಹಲವಾರು ಸೈಟ್ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ ನಾನು ಅದರ ಅಂತರ್ನಿರ್ಮಿತ ಕ್ಯಾಚಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ತುಂಬಾ ಇಷ್ಟಪಡುತ್ತೇನೆ, ಇದು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ನನ್ನಿಂದ ಹೆಚ್ಚಿನ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಒಂದು ಸೈಟ್ಗಾಗಿ, ಕ್ಯಾಶ್ ಅನ್ನು ತೆರವುಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ (ಸಂಪೂರ್ಣವಾಗಿ ಮತ್ತು ವೈಯಕ್ತಿಕ ನಮೂದುಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು) ನನಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾಗಿತ್ತು. NGINX ನ ಉಚಿತ ಸಮುದಾಯ ಆವೃತ್ತಿಯು ಸಮಯ-ಆಧಾರಿತ ಕ್ಯಾಶ್ ಮುಕ್ತಾಯವನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ (ಅಂದರೆ ಒಂದು ಗಂಟೆ, ಒಂದು ದಿನ, ಇತ್ಯಾದಿಗಳ ನಂತರ ಏನಾದರೂ ಬದಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ನೀವು ಅದನ್ನು ಹೊಂದಿಸಬಹುದು). ಆದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲವು ಯಾವಾಗ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸಲು ಯಾವುದೇ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಏನು? ಉದಾಹರಣೆಗೆ, ನಾನು ಹಿಂತಿರುಗಿ ಬಂದು ಈ ಪೋಸ್ಟ್ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸಲು ಒಂದು ಗಂಟೆ, ಒಂದು ದಿನ ಅಥವಾ ಒಂದು ವರ್ಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ - ಮತ್ತು ಒಂದು ದಿನ ಕ್ಯಾಚಿಂಗ್ ಉತ್ತಮವಾಗಿದ್ದರೆ ಕೇವಲ ಒಂದು ಗಂಟೆ ಮಾತ್ರ ಏಕೆ ಕ್ಯಾಶ್ ಮಾಡಬೇಕು?
ಕ್ಯಾಶ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ತೆರವುಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ (ಅಥವಾ ನಿಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಏನನ್ನಾದರೂ ಶುದ್ಧೀಕರಿಸಬೇಕು ಎಂದು ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ಗೆ ಸೂಚನೆ ನೀಡುವ ಮೂಲಕ) ಅಗತ್ಯವಿರುತ್ತದೆ. ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ ಹಿಂದಿನ ಜನರು ಇದರ ಅಗತ್ಯವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿದಿದ್ದಾರೆ ಏಕೆಂದರೆ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅವರ ಉತ್ಪನ್ನದ ಪಾವತಿಸಿದ ಆವೃತ್ತಿಯಲ್ಲಿ ಬೆಂಬಲಿಸಲಾಗಿದೆ - ಆದರೆ ಅವರು ಖಂಡಿತವಾಗಿಯೂ ತಮ್ಮ ಪರವಾನಗಿಯನ್ನು ಅವರು ಬಯಸುವ ರೀತಿಯಲ್ಲಿ ಹೊಂದಿಸಲು ಅರ್ಹರಾಗಿದ್ದರೂ, ಈ ಕಾರ್ಯವು ನನಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವ ಏಕೈಕ ಪಾವತಿಸಿದ ವೈಶಿಷ್ಟ್ಯವಾಗಿರುವಾಗ ಬೆಲೆ ಸ್ವಲ್ಪ ಕಡಿದಾದದ್ದಾಗಿದೆ.
ಅದೃಷ್ಟವಶಾತ್, ನೀವು ಕ್ಯಾಶ್ ಡೈರೆಕ್ಟರಿಯಿಂದ ಫೈಲ್ಗಳನ್ನು ನೀವೇ ಅಳಿಸಬಹುದು ಮತ್ತು ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ ಇದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಬ್ಯಾಕ್-ಎಂಡ್ನಿಂದ ಹೊಸ ನಕಲನ್ನು ಯಾವುದೇ ಅಡೆತಡೆಯಿಲ್ಲದೆ ಪಡೆಯುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತಿರುಚದೆ ನೀವು ಇದನ್ನು ಮಾಡಿದರೆ, ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಿಮ್ಮ ದೋಷ ಲಾಗ್ ನಲ್ಲಿ ಇದೇ ರೀತಿಯ ಸಂದೇಶಗಳ ಸಂಪೂರ್ಣ ಗುಂಪನ್ನು ನೀವು ನೋಡುವ ಸಾಧ್ಯತೆಯಿದೆ:
fastcgi_cache_path ನಿರ್ದೇಶನದ ನಿಷ್ಕ್ರಿಯ ನಿಯತಾಂಕದಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಮಯದ ನಂತರ ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ ಸ್ವತಃ ಕ್ಯಾಶ್ ನಮೂದುಗಳನ್ನು ಅಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಈ ದೋಷಗಳು ಸಂಭವಿಸುತ್ತವೆ ಎಂದು ತೋರುತ್ತದೆ. ಇದಕ್ಕಾಗಿ ಡೀಫಾಲ್ಟ್ ಕೇವಲ 10 ನಿಮಿಷಗಳು, ಆದರೆ ನೀವು ಬಯಸುವ ಯಾವುದೇ ಮೌಲ್ಯಕ್ಕೆ ನೀವು ಅದನ್ನು ಹೊಂದಿಸಬಹುದು. ನೀವು ಅದನ್ನು 10 ವರ್ಷಗಳಿಗೆ ಹೊಂದಿಸಿದರೆ, ಈ ಮಧ್ಯೆ ನೀವು ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸದಿರುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೆಮೊರಿಯಲ್ಲಿನ ಪ್ರಮುಖ ಸೂಚ್ಯಂಕವನ್ನು ಈ ಮಧ್ಯೆ ತೆರವುಗೊಳಿಸಲಾಗುತ್ತಿತ್ತು. ನೀವು ಇದನ್ನು ಮಾಡಿದರೆ, ಕ್ಯಾಶ್ ಅನ್ನು ನೀವೇ ತೆರವುಗೊಳಿಸುತ್ತೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕೇ, NGINX ಇನ್ನು ಮುಂದೆ ನಿಮಗಾಗಿ ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.
ಕ್ಯಾಶ್ ನಮೂದನ್ನು ಅಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಗಂಭೀರ ದೋಷವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ ಎಂಬುದು ನನಗೆ ನಿಜವಾಗಿಯೂ ವಿಚಿತ್ರವಾಗಿದೆ. ಅದರ ತೀವ್ರತೆಯ ವರ್ಗೀಕರಣವು ತುಂಬಾ ಹೆಚ್ಚಾಗಿದೆ ಎಂಬ ಅಂಶವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಿಂತ ಕೆಳಗಿರುವ ಲಾಗ್ ನಮೂದುಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಮೂಲಕ ತೊಡೆದುಹಾಕಲು ಅಸಾಧ್ಯ. ಹಿಂಭಾಗದಿಂದ ಹೊಸ ಪ್ರತಿಯನ್ನು ಪಡೆದ ತಕ್ಷಣ ನಮೂದು ಮತ್ತೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಎಚ್ಚರಿಕೆಯಾಗಿರಬೇಕು.
ಈಗ, ಅನುಮತಿಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಅಥವಾ ಮೂರನೆಯದರೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಕ್ಯಾಶ್ ನಮೂದನ್ನು ಅಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅದು ನಿರ್ಣಾಯಕ ದೋಷವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಎನ್ಜಿಐಎನ್ಎಕ್ಸ್ ಅದರ ಮುಕ್ತಾಯ ಸಮಯದ ನಂತರವೂ ಕ್ಯಾಶ್ ಮಾಡಿದ ವಿಷಯವನ್ನು ಪೂರೈಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು, ಆದರೆ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಈ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರುವುದಿಲ್ಲ.