8-કોર 24GB VPS મેમરી ખતમ થઈ રહી છે? HestiaCP સાથે એક્સ્ટ્રીમ PHP-FPM પ્રોસેસ પૂલ ટ્યુનિંગ માટે વ્યવહારુ માર્ગદર્શિકા

સર્વર કેટલા સહવર્તી વપરાશકર્તાઓને હેન્ડલ કરી શકે છે તે તેની પાસે કેટલા કોરો છે તેના પર આધાર રાખતું નથી, પરંતુ દરેક પ્રક્રિયા કેટલી મેમરી વાપરે છે તેના પર આધાર રાખે છે.

આ નિવેદન ઉશ્કેરણીજનક લાગે છે, પરંતુ તે કામગીરી અને જાળવણી ઉદ્યોગમાં સૌથી વાસ્તવિક અને પીડાદાયક અનુભવ છે.

યાદશક્તિ મુખ્ય અવરોધ કેમ છે?

ઘણા લોકો 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

પરિમાણ ગણતરી તર્ક અને સેટિંગ આધાર

આવશ્યક સહાયક સેટિંગ્સ અને ઑપ્ટિમાઇઝેશન સૂચનો

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 ને તેની સંપૂર્ણ ક્ષમતા મુજબ ઑપ્ટિમાઇઝ કરો, મેમરીના દરેક ટીપાનો મહત્તમ ઉપયોગ કરો.