ಕುಬರ್ನೆಟ್ಸ್ ಸಲಹೆಗಳು ಮತ್ತು ತಂತ್ರಗಳು: NGINX ಮತ್ತು PHP-FPM ನಲ್ಲಿ ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳು

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ CI/CD ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಒಂದು ವಿಶಿಷ್ಟವಾದ ಸ್ಥಿತಿ: ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸುವ ಮೊದಲು ಹೊಸ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸದಿರಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಬೇಕು.

ಈ ಸ್ಥಿತಿಯ ಅನುಸರಣೆ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಶೂನ್ಯ ಅಲಭ್ಯತೆಯನ್ನು ಸಾಧಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಬಂಡಲ್‌ಗಳನ್ನು (NGINX ಮತ್ತು PHP-FPM ನಂತಹ) ಬಳಸುವಾಗಲೂ ಸಹ, ಪ್ರತಿ ನಿಯೋಜನೆಯೊಂದಿಗೆ ದೋಷಗಳ ಉಲ್ಬಣಕ್ಕೆ ಕಾರಣವಾಗುವ ತೊಂದರೆಗಳನ್ನು ನೀವು ಎದುರಿಸಬಹುದು...

ಸಿದ್ಧಾಂತ. ಪಾಡ್ ಹೇಗೆ ಜೀವಿಸುತ್ತದೆ

ಪಾಡ್‌ನ ಜೀವನ ಚಕ್ರದ ಬಗ್ಗೆ ನಾವು ಈಗಾಗಲೇ ವಿವರವಾಗಿ ಪ್ರಕಟಿಸಿದ್ದೇವೆ ಈ ಲೇಖನ. ಪರಿಗಣನೆಯಲ್ಲಿರುವ ವಿಷಯದ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಈ ಕೆಳಗಿನವುಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ: ಪಾಡ್ ರಾಜ್ಯಕ್ಕೆ ಪ್ರವೇಶಿಸುವ ಕ್ಷಣದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತಿದೆ, ಹೊಸ ವಿನಂತಿಗಳು ಇದಕ್ಕೆ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ (pod ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಸೇವೆಯ ಅಂತಿಮ ಬಿಂದುಗಳ ಪಟ್ಟಿಯಿಂದ). ಹೀಗಾಗಿ, ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅಲಭ್ಯತೆಯನ್ನು ತಪ್ಪಿಸಲು, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿಲ್ಲಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಮಗೆ ಸಾಕು.

ಡೀಫಾಲ್ಟ್ ಗ್ರೇಸ್ ಅವಧಿ ಎಂದು ನೀವು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು 30 ಸೆಕೆಂಡುಗಳು: ಇದರ ನಂತರ, ಪಾಡ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಅವಧಿಯ ಮೊದಲು ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಸಮಯವನ್ನು ಹೊಂದಿರಬೇಕು. ಹೇಳಿಕೆಯನ್ನು: 5-10 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಯಾವುದೇ ವಿನಂತಿಯು ಈಗಾಗಲೇ ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ ಮತ್ತು ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯು ಇನ್ನು ಮುಂದೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ...

ಪಾಡ್ ಕೊನೆಗೊಂಡಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಈ ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ನೋಡಿ:

A1, B1 - ಒಲೆ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು
A2 - ನಿರ್ಗಮನ SIGTERM
B2 - ಅಂತಿಮ ಬಿಂದುಗಳಿಂದ ಪಾಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು
B3 - ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತಿದೆ (ಅಂತ್ಯ ಬಿಂದುಗಳ ಪಟ್ಟಿ ಬದಲಾಗಿದೆ)
B4 - iptables ನಿಯಮಗಳನ್ನು ನವೀಕರಿಸಿ

ದಯವಿಟ್ಟು ಗಮನಿಸಿ: ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪಾಡ್ ಅನ್ನು ಅಳಿಸುವುದು ಮತ್ತು SIGTERM ಅನ್ನು ಕಳುಹಿಸುವುದು ಅನುಕ್ರಮವಾಗಿ ನಡೆಯುವುದಿಲ್ಲ, ಆದರೆ ಸಮಾನಾಂತರವಾಗಿ. ಮತ್ತು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ನವೀಕರಿಸಿದ ಪಟ್ಟಿಯನ್ನು ಇನ್‌ಗ್ರೆಸ್ ತಕ್ಷಣವೇ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ, ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಹೊಸ ವಿನಂತಿಗಳನ್ನು ಪಾಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇದು ಪಾಡ್ ಮುಕ್ತಾಯದ ಸಮಯದಲ್ಲಿ 500 ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ (ಈ ವಿಷಯದ ಬಗ್ಗೆ ಹೆಚ್ಚು ವಿವರವಾದ ವಿಷಯಕ್ಕಾಗಿ, ನಾವು ಅನುವಾದಿಸಲಾಗಿದೆ). ಈ ಸಮಸ್ಯೆಯನ್ನು ಈ ಕೆಳಗಿನ ವಿಧಾನಗಳಲ್ಲಿ ಪರಿಹರಿಸಬೇಕಾಗಿದೆ:

• ಸಂಪರ್ಕವನ್ನು ಕಳುಹಿಸಿ: ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್‌ಗಳಲ್ಲಿ ಮುಚ್ಚಿ (ಇದು HTTP ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಂಬಂಧಿಸಿದೆ).
• ಕೋಡ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಮುಂದಿನ ಲೇಖನವು ಪರಿಹಾರವನ್ನು ವಿವರಿಸುತ್ತದೆ ಅದು ಆಕರ್ಷಕ ಅವಧಿಯ ಅಂತ್ಯದವರೆಗೆ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಸಿದ್ಧಾಂತ. NGINX ಮತ್ತು PHP-FPM ತಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೇಗೆ ಕೊನೆಗೊಳಿಸುತ್ತವೆ

NGINX

NGINX ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ, ಏಕೆಂದರೆ ಅದರೊಂದಿಗೆ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಸಿದ್ಧಾಂತಕ್ಕೆ ಧುಮುಕುವುದು, NGINX ಒಂದು ಮಾಸ್ಟರ್ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಹಲವಾರು "ಕೆಲಸಗಾರರು" ಎಂದು ನಾವು ಕಲಿಯುತ್ತೇವೆ - ಇವು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿವೆ. ಅನುಕೂಲಕರ ಆಯ್ಕೆಯನ್ನು ಒದಗಿಸಲಾಗಿದೆ: ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ nginx -s <SIGNAL> ವೇಗದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ ಅಥವಾ ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವ ಕ್ರಮದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕೊನೆಗೊಳಿಸಿ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಇದು ನಮಗೆ ಆಸಕ್ತಿಯಿರುವ ಕೊನೆಯ ಆಯ್ಕೆಯಾಗಿದೆ.

ನಂತರ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ: ನೀವು ಸೇರಿಸಬೇಕಾಗಿದೆ ಪ್ರಿಸ್ಟಾಪ್-ಹುಕ್ ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವ ಸಂಕೇತವನ್ನು ಕಳುಹಿಸುವ ಆಜ್ಞೆ. ಇದನ್ನು ನಿಯೋಜನೆಯಲ್ಲಿ, ಕಂಟೇನರ್ ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಮಾಡಬಹುದು:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

ಈಗ, ಪಾಡ್ ಸ್ಥಗಿತಗೊಂಡಾಗ, ನಾವು NGINX ಕಂಟೇನರ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ನೋಡುತ್ತೇವೆ:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

ಮತ್ತು ಇದು ನಮಗೆ ಬೇಕಾದುದನ್ನು ಅರ್ಥೈಸುತ್ತದೆ: NGINX ವಿನಂತಿಗಳು ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುತ್ತದೆ ಮತ್ತು ನಂತರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕೆಳಗೆ ನಾವು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯನ್ನು ಸಹ ಪರಿಗಣಿಸುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸಹ nginx -s quit ಪ್ರಕ್ರಿಯೆಯು ತಪ್ಪಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಮತ್ತು ಈ ಹಂತದಲ್ಲಿ ನಾವು NGINX ನೊಂದಿಗೆ ಮುಗಿಸಿದ್ದೇವೆ: ಕನಿಷ್ಠ ಲಾಗ್‌ಗಳಿಂದ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

PHP-FPM ಜೊತೆಗಿನ ಒಪ್ಪಂದವೇನು? ಇದು ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತವನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ? ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.

ಪಿಎಚ್ಪಿ-ಎಫ್‌ಪಿಎಂ

PHP-FPM ನ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ವಲ್ಪ ಕಡಿಮೆ ಮಾಹಿತಿ ಇದೆ. ನೀವು ಗಮನಹರಿಸಿದರೆ ಅಧಿಕೃತ ಕೈಪಿಡಿ PHP-FPM ಪ್ರಕಾರ, ಈ ಕೆಳಗಿನ POSIX ಸಂಕೇತಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಅದು ಹೇಳುತ್ತದೆ:

1. SIGINT, SIGTERM - ವೇಗದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ;
2. SIGQUIT - ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ (ನಮಗೆ ಬೇಕಾದುದನ್ನು).

ಈ ಕಾರ್ಯದಲ್ಲಿ ಉಳಿದ ಸಂಕೇತಗಳು ಅಗತ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಅವರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೇವೆ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಿಯಾಗಿ ಕೊನೆಗೊಳಿಸಲು, ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಿಸ್ಟಾಪ್ ಹುಕ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗುತ್ತದೆ:

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

ಮೊದಲ ನೋಟದಲ್ಲಿ, ಎರಡೂ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತವನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕಾರ್ಯವು ತೋರುತ್ತಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸದ ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಯೋಜನೆಯ ಅಲ್ಪಾವಧಿಯ ಅಲಭ್ಯತೆಯನ್ನು ಉಂಟುಮಾಡಿದ ಎರಡು ಪ್ರಕರಣಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.

ಅಭ್ಯಾಸ ಮಾಡಿ. ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯೊಂದಿಗೆ ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳು

NGINX

ಮೊದಲನೆಯದಾಗಿ, ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಉಪಯುಕ್ತವಾಗಿದೆ: ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದರ ಜೊತೆಗೆ nginx -s quit ಗಮನ ಕೊಡಬೇಕಾದ ಇನ್ನೂ ಒಂದು ಹಂತವಿದೆ. NGINX ಇನ್ನೂ SIGQUIT ಸಂಕೇತದ ಬದಲಿಗೆ SIGTERM ಅನ್ನು ಕಳುಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ, ಇದರಿಂದಾಗಿ ವಿನಂತಿಗಳು ಸರಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ. ಇದೇ ರೀತಿಯ ಪ್ರಕರಣಗಳನ್ನು ಕಾಣಬಹುದು, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ. ದುರದೃಷ್ಟವಶಾತ್, ಈ ನಡವಳಿಕೆಯ ನಿರ್ದಿಷ್ಟ ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ: NGINX ಆವೃತ್ತಿಯ ಬಗ್ಗೆ ಅನುಮಾನವಿತ್ತು, ಆದರೆ ಅದನ್ನು ದೃಢೀಕರಿಸಲಾಗಿಲ್ಲ. NGINX ಕಂಟೈನರ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ಗಮನಿಸಲಾಗಿದೆ ಎಂಬುದು ರೋಗಲಕ್ಷಣವಾಗಿದೆ: "ಸಂಪರ್ಕ 10 ರಲ್ಲಿ ತೆರೆದ ಸಾಕೆಟ್ #5 ಉಳಿದಿದೆ", ಅದರ ನಂತರ ಪಾಡ್ ನಿಲ್ಲಿಸಿತು.

ಅಂತಹ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಗಮನಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ಪ್ರವೇಶದ ಮೇಲಿನ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಂದ:

ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಥಿತಿ ಕೋಡ್‌ಗಳ ಸೂಚಕಗಳು

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಪ್ರವೇಶದಿಂದ ಕೇವಲ 503 ದೋಷ ಕೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ: ಇದು NGINX ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಇನ್ನು ಮುಂದೆ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ. ನೀವು NGINX ನೊಂದಿಗೆ ಕಂಟೇನರ್ ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ಅವುಗಳು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

ಸ್ಟಾಪ್ ಸಿಗ್ನಲ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ, ಕಂಟೇನರ್ ಸರಿಯಾಗಿ ನಿಲ್ಲಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: 503 ದೋಷವನ್ನು ಇನ್ನು ಮುಂದೆ ಗಮನಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದ ಇದು ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆ.

ನೀವು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದರೆ, ಕಂಟೇನರ್ನಲ್ಲಿ ಯಾವ ಸ್ಟಾಪ್ ಸಿಗ್ನಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಿಸ್ಟಾಪ್ ಹುಕ್ ನಿಖರವಾಗಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಕಾರಣವು ಇದರಲ್ಲಿ ನಿಖರವಾಗಿ ಇರುತ್ತದೆ ಎಂದು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಿದೆ.

PHP-FPM... ಮತ್ತು ಇನ್ನಷ್ಟು

PHP-FPM ಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಯನ್ನು ಕ್ಷುಲ್ಲಕ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ: ಇದು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಗಳ ಪೂರ್ಣಗೊಳ್ಳುವಿಕೆಗಾಗಿ ಕಾಯುವುದಿಲ್ಲ, ಅದು ಅವುಗಳನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ, ಅದಕ್ಕಾಗಿಯೇ ನಿಯೋಜನೆ ಮತ್ತು ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯದಲ್ಲಿ 502 ದೋಷಗಳು ಸಂಭವಿಸುತ್ತವೆ. 2005 ರಿಂದ bugs.php.net ನಲ್ಲಿ ಹಲವಾರು ದೋಷ ವರದಿಗಳಿವೆ (ಉದಾ ಇಲ್ಲಿ и ಇಲ್ಲಿ), ಇದು ಈ ಸಮಸ್ಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆದರೆ ನೀವು ಹೆಚ್ಚಾಗಿ ಲಾಗ್‌ಗಳಲ್ಲಿ ಏನನ್ನೂ ನೋಡುವುದಿಲ್ಲ: PHP-FPM ಯಾವುದೇ ದೋಷಗಳು ಅಥವಾ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅಧಿಸೂಚನೆಗಳಿಲ್ಲದೆ ಅದರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ.

ಸಮಸ್ಯೆಯು ಸ್ವತಃ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೇಲೆ ಕಡಿಮೆ ಅಥವಾ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸ್ವತಃ ಪ್ರಕಟವಾಗದಿರಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ನೀವು ಅದನ್ನು ಎದುರಿಸಿದರೆ, ಸರಳವಾದ ಪರಿಹಾರವು ಮೊದಲು ಮನಸ್ಸಿಗೆ ಬರುತ್ತದೆ: ಪ್ರಿಸ್ಟಾಪ್ ಹುಕ್ ಅನ್ನು ಸೇರಿಸಿ sleep(30). ಇದು ಮೊದಲು ಇದ್ದ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಮತ್ತು ನಾವು ಹೊಸದನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪಾಡ್ ಈಗಾಗಲೇ ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಕೊನೆಗೊಳ್ಳುತ್ತಿದೆ), ಮತ್ತು 30 ಸೆಕೆಂಡುಗಳ ನಂತರ ಪಾಡ್ ಸ್ವತಃ ಸಂಕೇತದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ SIGTERM.

ಇದು ತಿರುಗುತ್ತದೆ lifecycle ಏಕೆಂದರೆ ಕಂಟೇನರ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

ಆದಾಗ್ಯೂ, 30-ಸೆಕೆಂಡ್ ಕಾರಣ sleep ನಾವು ಬಲವಾಗಿ ಪ್ರತಿ ಪಾಡ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುವುದರಿಂದ ನಾವು ನಿಯೋಜನೆ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ ಕನಿಷ್ಠ 30 ಸೆಕೆಂಡುಗಳು, ಇದು ಕೆಟ್ಟದು. ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬಹುದು?

ಅಪ್ಲಿಕೇಶನ್ನ ನೇರ ಮರಣದಂಡನೆಗೆ ಜವಾಬ್ದಾರಿಯುತ ಪಕ್ಷಕ್ಕೆ ತಿರುಗೋಣ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಪಿಎಚ್ಪಿ-ಎಫ್‌ಪಿಎಂಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅದರ ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಗಳ ಮರಣದಂಡನೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದಿಲ್ಲ: ಮಾಸ್ಟರ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತಕ್ಷಣವೇ ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ನಿರ್ದೇಶನವನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಈ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು process_control_timeout, ಇದು ಮಾಸ್ಟರ್‌ನಿಂದ ಸಿಗ್ನಲ್‌ಗಳಿಗಾಗಿ ಕಾಯಲು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಸಮಯ ಮಿತಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ನೀವು ಮೌಲ್ಯವನ್ನು 20 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೊಂದಿಸಿದರೆ, ಇದು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಅವು ಪೂರ್ಣಗೊಂಡ ನಂತರ ಮಾಸ್ಟರ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

ಈ ಜ್ಞಾನದೊಂದಿಗೆ, ನಮ್ಮ ಕೊನೆಯ ಸಮಸ್ಯೆಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಹೇಳಿದಂತೆ, ಕುಬರ್ನೆಟ್ಸ್ ಏಕಶಿಲೆಯ ವೇದಿಕೆಯಲ್ಲ: ಅದರ ವಿಭಿನ್ನ ಘಟಕಗಳ ನಡುವಿನ ಸಂವಹನವು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಳಹರಿವು ಮತ್ತು ಇತರ ಸಂಬಂಧಿತ ಘಟಕಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಾವು ಪರಿಗಣಿಸಿದಾಗ ಇದು ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅಂತಹ ವಿಳಂಬದಿಂದಾಗಿ 500 ದೋಷಗಳ ಉಲ್ಬಣವನ್ನು ಪಡೆಯುವುದು ಸುಲಭ. ಉದಾಹರಣೆಗೆ, ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಹಂತದಲ್ಲಿ ದೋಷ ಸಂಭವಿಸಬಹುದು, ಆದರೆ ಘಟಕಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ "ಸಮಯದ ವಿಳಂಬ" ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ - ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ.

ಆದ್ದರಿಂದ, ಒಟ್ಟಾಗಿ ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾದ ನಿರ್ದೇಶನದೊಂದಿಗೆ process_control_timeout ನೀವು ಈ ಕೆಳಗಿನ ನಿರ್ಮಾಣವನ್ನು ಬಳಸಬಹುದು lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಆಜ್ಞೆಯೊಂದಿಗೆ ನಾವು ವಿಳಂಬವನ್ನು ಸರಿದೂಗಿಸುತ್ತೇವೆ sleep ಮತ್ತು ನಿಯೋಜನೆ ಸಮಯವನ್ನು ಹೆಚ್ಚು ಹೆಚ್ಚಿಸಬೇಡಿ: 30 ಸೆಕೆಂಡುಗಳು ಮತ್ತು ಒಂದರ ನಡುವೆ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವಿದೆಯೇ?.. ವಾಸ್ತವವಾಗಿ, ಇದು process_control_timeoutಮತ್ತು lifecycle ವಿಳಂಬದ ಸಂದರ್ಭದಲ್ಲಿ "ಸುರಕ್ಷತಾ ನಿವ್ವಳ" ವಾಗಿ ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ವಿವರಿಸಿದ ನಡವಳಿಕೆ ಮತ್ತು ಅನುಗುಣವಾದ ಪರಿಹಾರವು PHP-FPM ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಇತರ ಭಾಷೆಗಳು/ಚೌಕಟ್ಟುಗಳನ್ನು ಬಳಸುವಾಗ ಇದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಯು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಉದ್ಭವಿಸಬಹುದು. ನೀವು ಇತರ ರೀತಿಯಲ್ಲಿ ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ - ಉದಾಹರಣೆಗೆ, ಕೋಡ್ ಅನ್ನು ಪುನಃ ಬರೆಯುವ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ಮುಕ್ತಾಯದ ಸಂಕೇತಗಳನ್ನು ಸರಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ - ನೀವು ವಿವರಿಸಿದ ವಿಧಾನವನ್ನು ಬಳಸಬಹುದು. ಇದು ಅತ್ಯಂತ ಸುಂದರವಾಗಿಲ್ಲದಿರಬಹುದು, ಆದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಅಭ್ಯಾಸ ಮಾಡಿ. ಪಾಡ್‌ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಲೋಡ್ ಪರೀಕ್ಷೆ

ಕಂಟೇನರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಲೋಡ್ ಪರೀಕ್ಷೆಯು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡಿದಾಗ ಈ ವಿಧಾನವು ನೈಜ ಯುದ್ಧ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ಹತ್ತಿರ ತರುತ್ತದೆ. ಮೇಲಿನ ಶಿಫಾರಸುಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು, ನೀವು ಬಳಸಬಹುದು Yandex.Tankom: ಇದು ನಮ್ಮ ಎಲ್ಲಾ ಅಗತ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಂಡಿದೆ. ಗ್ರಾಫನಾ ಮತ್ತು Yandex.Tank ನ ಗ್ರಾಫ್‌ಗಳಿಗೆ ನಮ್ಮ ಅನುಭವದ ಧನ್ಯವಾದಗಳು ಸ್ಪಷ್ಟ ಉದಾಹರಣೆಯೊಂದಿಗೆ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಲು ಕೆಳಗಿನ ಸಲಹೆಗಳು ಮತ್ತು ಶಿಫಾರಸುಗಳು.

ಇಲ್ಲಿ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಬದಲಾವಣೆಗಳನ್ನು ಹಂತ ಹಂತವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಹೊಸ ಫಿಕ್ಸ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ, ಪರೀಕ್ಷೆಯನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಕೊನೆಯ ರನ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಫಲಿತಾಂಶಗಳು ಬದಲಾಗಿವೆಯೇ ಎಂದು ನೋಡಿ. ಇಲ್ಲದಿದ್ದರೆ, ನಿಷ್ಪರಿಣಾಮಕಾರಿ ಪರಿಹಾರಗಳನ್ನು ಗುರುತಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ, ಮತ್ತು ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಅದು ಹಾನಿಯನ್ನು ಮಾತ್ರ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ನಿಯೋಜನೆ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಿ).

ಅದರ ಮುಕ್ತಾಯದ ಸಮಯದಲ್ಲಿ ಕಂಟೇನರ್ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುವುದು ಮತ್ತೊಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯ ಮಾಹಿತಿಯನ್ನು ಅಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆಯೇ? ಇತರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸುವಾಗ ಲಾಗ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ದೋಷಗಳಿವೆಯೇ (ಉದಾಹರಣೆಗೆ, ನೆರೆಯ PHP-FPM ಕಂಟೇನರ್‌ಗೆ)? ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿಯೇ ದೋಷಗಳು (ಮೇಲೆ ವಿವರಿಸಿದ NGINX ನಲ್ಲಿರುವಂತೆ)? ಈ ಲೇಖನದ ಪರಿಚಯಾತ್ಮಕ ಮಾಹಿತಿಯು ಅದರ ಮುಕ್ತಾಯದ ಸಮಯದಲ್ಲಿ ಕಂಟೇನರ್‌ಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಹಾಗಾಗಿ, ಮೊದಲ ಟೆಸ್ಟ್ ರನ್ ಇಲ್ಲದೆ ನಡೆಯಿತು lifecycle ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗೆ ಹೆಚ್ಚುವರಿ ನಿರ್ದೇಶನಗಳಿಲ್ಲದೆ (process_control_timeout PHP-FPM ನಲ್ಲಿ). ಈ ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶವು ಅಂದಾಜು ಸಂಖ್ಯೆಯ ದೋಷಗಳನ್ನು ಗುರುತಿಸುವುದು (ಮತ್ತು ಯಾವುದಾದರೂ ಇವೆಯೇ). ಅಲ್ಲದೆ, ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯಿಂದ, ಪ್ರತಿ ಪಾಡ್‌ನ ಸರಾಸರಿ ನಿಯೋಜನೆ ಸಮಯವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾಗುವವರೆಗೆ ಸುಮಾರು 5-10 ಸೆಕೆಂಡುಗಳು ಎಂದು ನೀವು ತಿಳಿದಿರಬೇಕು. ಫಲಿತಾಂಶಗಳು ಹೀಗಿವೆ:

Yandex.Tank ಮಾಹಿತಿ ಫಲಕವು 502 ದೋಷಗಳ ಸ್ಪೈಕ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿದೆ ಮತ್ತು ಸರಾಸರಿ 5 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಇರುತ್ತದೆ. ಪ್ರಾಯಶಃ ಇದು ಹಳೆಯ ಪಾಡ್‌ಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿನಂತಿಗಳನ್ನು ಕೊನೆಗೊಳಿಸಿದಾಗ ಅದನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ಇದರ ನಂತರ, 503 ದೋಷಗಳು ಕಾಣಿಸಿಕೊಂಡವು, ಇದು ನಿಲ್ಲಿಸಿದ NGINX ಕಂಟೇನರ್‌ನ ಫಲಿತಾಂಶವಾಗಿದೆ, ಇದು ಬ್ಯಾಕೆಂಡ್‌ನಿಂದಾಗಿ ಸಂಪರ್ಕಗಳನ್ನು ಸಹ ಕೈಬಿಟ್ಟಿತು (ಇದು ಪ್ರವೇಶವನ್ನು ಸಂಪರ್ಕಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ).

ಹೇಗೆ ಎಂದು ನೋಡೋಣ process_control_timeout PHP-FPM ನಲ್ಲಿ ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಗಳು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅಂದರೆ. ಅಂತಹ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿ. ಈ ನಿರ್ದೇಶನವನ್ನು ಬಳಸಿಕೊಂಡು ಮರು ನಿಯೋಜಿಸಿ:

500 ನೇ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ! ನಿಯೋಜನೆ ಯಶಸ್ವಿಯಾಗಿದೆ, ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವ ಕೆಲಸಗಳು.

ಆದಾಗ್ಯೂ, ಇನ್‌ಗ್ರೆಸ್ ಕಂಟೇನರ್‌ಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಸಮಯದ ವಿಳಂಬದಿಂದಾಗಿ ನಾವು ಸ್ವೀಕರಿಸಬಹುದಾದ ಸಣ್ಣ ಶೇಕಡಾವಾರು ದೋಷಗಳು. ಅವುಗಳನ್ನು ತಪ್ಪಿಸಲು, ರಚನೆಯನ್ನು ಸೇರಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ sleep ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಆದಾಗ್ಯೂ, ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಗೋಚರಿಸುವುದಿಲ್ಲ (ಮತ್ತೆ, ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ).

ತೀರ್ಮಾನಕ್ಕೆ

ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆಕರ್ಷಕವಾಗಿ ಕೊನೆಗೊಳಿಸಲು, ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಈ ಕೆಳಗಿನ ನಡವಳಿಕೆಯನ್ನು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ:

1. ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ನಂತರ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.
2. ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸದ ಎಲ್ಲಾ ಕೀಪಲೈವ್ ಸಂಪರ್ಕಗಳನ್ನು ಮುಚ್ಚಲು ನಿರೀಕ್ಷಿಸಿ.
3. ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸಿ.

ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಈ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಕುಬರ್ನೆಟ್ಸ್ ವಾಸ್ತವಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗೆ ಒಂದು ಪರಿಹಾರವೆಂದರೆ:

• ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯುವ ಪೂರ್ವ-ಸ್ಟಾಪ್ ಹುಕ್ ಅನ್ನು ಸೇರಿಸುವುದು;
• ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡುವುದು.

NGINX ನ ಉದಾಹರಣೆಯು ಆರಂಭದಲ್ಲಿ ಮುಕ್ತಾಯ ಸಂಕೇತಗಳನ್ನು ಸರಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್ ಕೂಡ ಹಾಗೆ ಮಾಡದಿರಬಹುದು ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ 500 ದೋಷಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಇದು ನಿಮಗೆ ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚು ವಿಶಾಲವಾಗಿ ನೋಡಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಪಾಡ್ ಅಥವಾ ಕಂಟೇನರ್ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಒಟ್ಟಾರೆಯಾಗಿ ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ನೋಡಿ.

ಪರೀಕ್ಷಾ ಸಾಧನವಾಗಿ, ನೀವು ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ Yandex.Tank ಅನ್ನು ಬಳಸಬಹುದು (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಪರೀಕ್ಷೆಗಾಗಿ ಪ್ರಮೀತಿಯಸ್ ಬ್ಯಾಕೆಂಡ್ನೊಂದಿಗೆ ಗ್ರಾಫನಾದಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ). ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯೊಂದಿಗಿನ ತೊಂದರೆಗಳು ಬೆಂಚ್ಮಾರ್ಕ್ ರಚಿಸಬಹುದಾದ ಭಾರೀ ಹೊರೆಗಳ ಅಡಿಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಅಥವಾ ನಂತರ ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸಲು ಮೇಲ್ವಿಚಾರಣೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಲೇಖನದ ಮೇಲಿನ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ: NGINX ಪ್ರವೇಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಪರಿಹಾರಗಳನ್ನು ಇಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ ಎಂದು ನಮೂದಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇತರ ಪರಿಹಾರಗಳಿವೆ, ಇದನ್ನು ನಾವು ಸರಣಿಯ ಕೆಳಗಿನ ವಸ್ತುಗಳಲ್ಲಿ ಪರಿಗಣಿಸಬಹುದು.

ಪಿಎಸ್

K8s ಸಲಹೆಗಳು ಮತ್ತು ತಂತ್ರಗಳ ಸರಣಿಯಿಂದ ಇತರೆ:

• «NGINX ಪ್ರವೇಶದಲ್ಲಿ ಕಸ್ಟಮ್ ದೋಷ ಪುಟಗಳು";
• «ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನೋಡ್ ಹಂಚಿಕೆ ಮತ್ತು ಲೋಡ್‌ಗಳ ಬಗ್ಗೆ";
• «ದೇವ್ ಸೈಟ್‌ಗಳಿಗೆ ಪ್ರವೇಶ";
• «ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಅನ್ನು ವೇಗಗೊಳಿಸುವುದು».

ಮೂಲ: www.habr.com