ਲੇਖ ਡਾਇਰੈਕਟਰੀ
ਇੱਕ ਸਰਵਰ ਕਿੰਨੇ ਸਮਕਾਲੀ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਸ ਵਿੱਚ ਕਿੰਨੇ ਕੋਰ ਹਨ, ਸਗੋਂ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਕਿੰਨੀ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ।
ਇਹ ਬਿਆਨ ਭੜਕਾਹਟ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸੰਚਾਲਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਉਦਯੋਗ ਵਿੱਚ ਸਭ ਤੋਂ ਅਸਲੀ ਅਤੇ ਦਰਦਨਾਕ ਅਨੁਭਵ ਹੈ।
ਯਾਦਦਾਸ਼ਤ ਮੁੱਖ ਰੁਕਾਵਟ ਕਿਉਂ ਹੈ?
ਬਹੁਤ ਸਾਰੇ ਲੋਕ 8-ਕੋਰ CPU ਅਤੇ 24GB ਮੈਮੋਰੀ ਵਾਲਾ VPS ਦੇਖਦੇ ਹਨ ਅਤੇ ਅਚੇਤ ਤੌਰ 'ਤੇ ਸੋਚਦੇ ਹਨ ਕਿ ਉਹ ਸੈਂਕੜੇ PHP-FPM ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਨ।
ਹਾਲਾਂਕਿ, ਅਸਲੀਅਤ ਵਿੱਚ, ਇੱਕ ਸਿੰਗਲ PHP ਪ੍ਰਕਿਰਿਆ ਦੀ RSS ਮੈਮੋਰੀ ਵਰਤੋਂ ਅਕਸਰ 200MB ਤੱਕ ਹੁੰਦੀ ਹੈ ।
ਇਹ ਕਮਾਂਡ ਲਾਈਨ ਰਾਹੀਂ ਅਸਲ ਟੈਸਟਿੰਗ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਨਤੀਜਾ ਹੈ:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP ਦੇ ਗੁੰਝਲਦਾਰ ਢਾਂਚੇ ਅਤੇ ਮਲਟੀ-ਪਲੱਗਇਨ ਵਾਤਾਵਰਣ ਵਿੱਚ , ਖਾਸ ਕਰਕੇ OPcache ਅਨੁਕੂਲਨ ਤੋਂ ਬਿਨਾਂ, 200MB ਆਦਰਸ਼ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੈਮੋਰੀ, CPU ਨਹੀਂ, ਉਹ ਸਖ਼ਤ ਸੀਮਾ ਹੈ ਜੋ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਰੂਪਤਾ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਸਿਫਾਰਸ਼ੀ ਸੰਰਚਨਾ ਫਾਈਲ (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
ਪੈਰਾਮੀਟਰ ਗਣਨਾ ਤਰਕ ਅਤੇ ਸੈਟਿੰਗ ਆਧਾਰ
| ਸੰਰਚਨਾ ਪੈਰਾਮੀਟਰ | ਮੁੱਲ ਸੈੱਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ | ਮੁੱਖ ਗਣਨਾ ਅਤੇ ਸੈੱਟਅੱਪ ਆਧਾਰ |
|---|---|---|
| pm | dynamic | ਡਾਇਨਾਮਿਕ ਮੋਡ ਸਮਕਾਲੀ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਚਕੀਲਾ ਜੋੜਨ ਜਾਂ ਮਿਟਾਉਣ, ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਗਤੀ ਅਤੇ ਮੈਮੋਰੀ ਉਪਯੋਗਤਾ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। |
| pm.max_children | 80 | 24GB ਕੁੱਲ ਮੈਮੋਰੀ ਘਟਾ ਕੇ ਸਿਸਟਮ ਕਰਨਲ ਅਤੇ MySQL/ਰੇਡਿਸNginx ਤੋਂ ਬਾਅਦ, PHP ਲਈ ਲਗਭਗ 16GB ਬਚਦਾ ਹੈ।16,384 MB / 200 MB ≈ 81.9ਇਸਨੂੰ 80 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ ਉੱਚ ਸਹਿਮਤੀ ਦੌਰਾਨ OOM (ਮੈਮੋਰੀ ਤੋਂ ਬਾਹਰ) ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ। |
| pm.start_servers | 16 | ਸ਼ੁਰੂਆਤ 'ਤੇ ਪ੍ਰੀਹੀਟਿੰਗ ਨੂੰ CPU ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ (8 ਕੋਰ × 2 = 16) ਦੇ ਦੁੱਗਣੇ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਸੇਵਾ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ ਮੁੱਢਲੀ ਸਹਿਮਤੀ ਨੂੰ ਸੰਭਾਲ ਸਕੇ। |
| ਦੁਪਹਿਰ.ਘੱਟ_ਸਪੇਅਰ_ਸਰਵਰ | 8 | ਘੱਟ ਟ੍ਰੈਫਿਕ ਪੀਰੀਅਡਾਂ ਦੌਰਾਨ ਕਿਸੇ ਵੀ ਸਮੇਂ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕੇ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ CPU ਕੋਰ ਗਿਣਤੀ ਨੂੰ 8 ਕੋਰ 'ਤੇ ਸੈੱਟ ਕਰੋ। |
| pm.max_spare_servers | 24 | ਟ੍ਰੈਫਿਕ ਘੱਟਣ ਤੋਂ ਬਾਅਦ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਇੱਕ ਮੱਧਮ ਸੰਖਿਆ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ, ਹਲਕੇ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਇਸਨੂੰ CPU ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ ਦੇ 3 ਗੁਣਾ (8 ਕੋਰ × 3 = 24) 'ਤੇ ਸੈੱਟ ਕਰੋ। |
| pm.max_requests | 500 | ਜੇਕਰ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਕਿਰਿਆ 200MB ਦੇ ਵੱਡੇ ਅਧਾਰ 'ਤੇ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ 500 ਤੱਕ ਘਟਾਉਣ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨਸ਼ਟ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਦੁਬਾਰਾ ਬਣ ਜਾਵੇਗੀ, ਜੋ ਕਿ ਅਪ੍ਰਤੱਖ ਮੈਮੋਰੀ ਲੀਕ ਨੂੰ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਸਾਫ਼ ਕਰ ਸਕਦੀ ਹੈ। |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers ਨਿਸ਼ਕਿਰਿਆ ਪ੍ਰਕਿਰਿਆਵਾਂ ਆਪਣੇ ਆਪ ਜਾਰੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ 10 ਸਕਿੰਟਾਂ ਤੱਕ ਬਿਨਾਂ ਕਿਸੇ ਬੇਨਤੀ ਦੇ ਸਿਸਟਮ ਮੈਮੋਰੀ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦੀਆਂ ਹਨ। |
ਜ਼ਰੂਰੀ ਸਹਾਇਕ ਸੈਟਿੰਗਾਂ ਅਤੇ ਅਨੁਕੂਲਤਾ ਸੁਝਾਅ
1. ਟਾਈਮਆਉਟ ਐਂਟੀ-ਹੈਂਗਓਵਰ ਵਿਧੀ
request_terminate_timeout = 60s ਇਹੀ ਚਾਬੀ ਹੈ।
ਇਹ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਡੈੱਡਲਾਕ ਜਾਂ ਤੀਜੀ-ਧਿਰ API ਬਲਾਕਿੰਗ ਕਾਰਨ ਫਸੀਆਂ ਹੋਈਆਂ ਹਨ।
ਇਸ ਦੌਰਾਨ, Nginx ਦੇ fastcgi_read_timeout ਇਸਨੂੰ ਘੱਟੋ-ਘੱਟ 60 ਸਕਿੰਟ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਕਲਾਇੰਟ ਇਸਨੂੰ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤ ਕਰ ਲਵੇਗਾ। 504 Gateway Timeout.
2. ਯਾਦਦਾਸ਼ਤ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਰਣਨੀਤੀਆਂ
ਵੱਧ ਤੋਂ ਵੱਧ 80 ਸਮਕਾਲੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਕਾਲੀ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਸਿਸਟਮ ਇੱਕੋ ਸਮੇਂ ਵੱਧ ਤੋਂ ਵੱਧ 80 ਗਤੀਸ਼ੀਲ HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਸਮਰੱਥਾ ਨੂੰ ਹੋਰ ਬਿਹਤਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਤੀ ਪ੍ਰਕਿਰਿਆ ਮੈਮੋਰੀ ਵਰਤੋਂ ਨੂੰ ਘਟਾਉਣ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
- OPcache ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ: ਮੌਜੂਦ ਹੈ
php.iniਦਰਮਿਆਨੀ ਸੰਰਚਨਾopcache.enable=1ਅਤੇopcache.memory_consumption=256ਬਾਈਟਕੋਡ ਕੈਸ਼ਿੰਗ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਮੈਮੋਰੀ ਵਰਤੋਂ ਨੂੰ 200MB ਤੋਂ ਘਟਾ ਕੇ 60~100MB ਕਰ ਸਕਦੀ ਹੈ। - memory_limit ਦਾ ਵਾਜਬ ਨਿਯੰਤਰਣ: ਇੱਛਾ
php.iniਮੱਧmemory_limitਸੀਮਤ128Mਜਾਂ256Mਵਿਅਕਤੀਗਤ ਅਸਧਾਰਨ ਲਿਪੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈਅਸੀਮਤਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਯਾਦਦਾਸ਼ਤ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਮੈਮੋਰੀ ਵਰਤੋਂ 100MB ਤੱਕ ਘੱਟ ਜਾਂਦੀ ਹੈ...pm.max_children ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅੱਪਗ੍ਰੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ 150 ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਮਕਾਲੀ ਸਮਰੱਥਾ ਲਗਭਗ ਦੁੱਗਣੀ ਹੋ ਗਈ ਹੈ।
ਅਧਿਕਾਰਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣਾਂ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ
ਅਧਿਕਾਰਤ Nginx ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦੇ ਅਨੁਸਾਰ :
"ਸਰੋਤਾਂ ਦੀ ਥਕਾਵਟ ਨੂੰ ਰੋਕਣ ਲਈ ਫਾਸਟਸੀਜੀਆਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਹਮੇਸ਼ਾ ਟਾਈਮਆਉਟ ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।"
(ਸਰੋਤ: Nginx ਡੌਕਸ)
ਅਧਿਕਾਰਤ PHP ਮੈਨੂਅਲ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹਿੰਦਾ ਹੈ:
"pm.max_children ਬਣਾਏ ਜਾਣ ਵਾਲੇ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਿਰਦੇਸ਼ ਹੈ।"
(ਸਰੋਤ: PHP-FPM ਦਸਤਾਵੇਜ਼)
ਇਹ ਅਧਿਕਾਰਤ ਵਿਚਾਰ ਸਾਡੇ ਅਭਿਆਸਾਂ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਅਨੁਕੂਲਨ ਤਰਕ ਸਿਰਫ਼ ਅਨੁਭਵ 'ਤੇ ਅਧਾਰਤ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਮਿਆਰੀ ਵਧੀਆ ਅਭਿਆਸਾਂ 'ਤੇ ਵੀ ਅਧਾਰਤ ਹੈ।
ਸਿੱਟਾ: ਮੇਰੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਅਤੇ ਮੁੱਖ ਹਵਾਲੇ
ਉੱਚ-ਸਮਕਾਲੀਨ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ, CPU ਇੰਜਣ ਹੈ, ਮੈਮੋਰੀ ਬਾਲਣ ਟੈਂਕ ਹੈ, ਅਤੇ PHP-FPM ਫਲੀਟ ਡਿਸਪੈਚਰ ਹੈ।
ਇੰਜਣ ਕਿੰਨਾ ਵੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਜੇਕਰ ਬਾਲਣ ਟੈਂਕ ਕਾਫ਼ੀ ਵੱਡਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਾਫਲਾ ਬਹੁਤ ਦੂਰ ਨਹੀਂ ਜਾਵੇਗਾ।
ਸੱਚੇ ਮਾਹਰ ਅੰਨ੍ਹੇਵਾਹ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਨਹੀਂ ਕਰਦੇ, ਸਗੋਂ ਬਰਬਾਦੀ ਅਤੇ ਓਵਰਫਲੋ ਦੋਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਮੈਮੋਰੀ ਵਰਤੋਂ ਦੀ ਸਹੀ ਗਣਨਾ ਕਰਦੇ ਹਨ।
ਅਨੁਕੂਲਤਾ ਦਾ ਸਾਰ ਸੀਮਤ ਸਰੋਤਾਂ ਦੇ ਨਾਲ ਅਨੁਕੂਲ ਸੰਤੁਲਨ ਲੱਭਣਾ ਹੈ।
ਇਹ ਸਿਰਫ਼ ਇੱਕ ਤਕਨਾਲੋਜੀ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਇੱਕ ਦਰਸ਼ਨ ਵੀ ਹੈ ।
ਇਸ ਲਈ, ਇਹ ਮੰਨਣਾ ਬੰਦ ਕਰੋ ਕਿ "ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ ਸਭ ਕੁਝ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।" ਜੋ ਅਸਲ ਵਿੱਚ ਸਮਕਾਲੀ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਉਹ ਹੈ ਯਾਦਦਾਸ਼ਤ ਉੱਤੇ ਤੁਹਾਡਾ ਨਿਯੰਤਰਣ।
ਕਾਰਵਾਈ ਕਰੋ ਅਤੇ ਆਪਣੇ VPS ਨੂੰ ਇਸਦੀ ਪੂਰੀ ਸਮਰੱਥਾ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਬਣਾਓ, ਮੈਮੋਰੀ ਦੇ ਹਰ ਬੂੰਦ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਲਾਭ ਉਠਾਉਂਦੇ ਹੋਏ।
ਉਮੀਦ ਹੈ, ਚੇਨ ਵੇਇਲਿਯਾਂਗ ਦੇ ਬਲੌਗ ( https://www.chenweiliang.com/ ) 'ਤੇ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਲੇਖ "8-ਕੋਰ 24G VPS ਮੈਮੋਰੀ ਖਤਮ ਹੋ ਰਹੀ ਹੈ? HestiaCP ਅਧੀਨ PHP-FPM ਪ੍ਰਕਿਰਿਆ ਪੂਲ ਦੀ ਅਤਿਅੰਤ ਟਿਊਨਿੰਗ" ਤੁਹਾਡੇ ਲਈ ਮਦਦਗਾਰ ਹੋਵੇਗਾ।
ਇਸ ਲੇਖ ਦਾ ਲਿੰਕ ਸਾਂਝਾ ਕਰਨ ਲਈ ਬੇਝਿਜਕ ਮਹਿਸੂਸ ਕਰੋ: https://www.chenweiliang.com/cwl-34509.html