ලිපි නාමාවලිය
සේවාදායකයකට හැසිරවිය හැකි සමගාමී පරිශීලකයින් සංඛ්යාව රඳා පවතින්නේ එහි ඇති මධ්ය ගණන මත නොව, එක් එක් ක්රියාවලිය පරිභෝජනය කරන මතක ප්රමාණය මතය.
මෙම ප්රකාශය ප්රකෝප කිරීමක් ලෙස පෙනුනද, මෙහෙයුම් සහ නඩත්තු කර්මාන්තයේ වඩාත්ම සැබෑ සහ වේදනාකාරී අත්දැකීම එයයි.
මතකය ප්රධාන බාධකය වන්නේ ඇයි?
බොහෝ අය 8-core 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_ළමයින් | 80 | පද්ධති කර්නලය අඩු කිරීමෙන් මුළු මතකය 24GB සහ MySQL/RedisNginx වලින් පසුව, PHP සඳහා ආසන්න වශයෙන් 16GB ඉතිරි වේ.16,384 MB / 200 MB ≈ 81.9එය 80 ලෙස සැකසීමෙන් ඉහළ සමගාමීත්වයක් ඇති විට OOM (මතකයෙන් බැහැර වීම) සම්පූර්ණයෙන්ම ඉවත් කළ හැක. |
| pm.start_servers වෙත පිවිසෙන්න | 16 | සේවාව නැවත ආරම්භ කිරීමෙන් පසු මූලික සමගාමී මුදල් ක්ෂණිකව හැසිරවිය හැකි බව සහතික කිරීම සඳහා ආරම්භයේදී පෙර රත් කිරීම CPU මධ්ය ගණන මෙන් දෙගුණයකට (cores 8 × 2 = 16) සකසා ඇත. |
| pm.min_spare_servers වෙත පිවිසෙන්න | 8 | අඩු තදබදයක් ඇති කාලවලදී ඕනෑම වේලාවක නව ඉල්ලීම්වලට ප්රතිචාර දැක්විය හැකි බව සහතික කිරීම සඳහා CPU මධ්ය ගණන මධ්ය 8කට සකසන්න. |
| pm.max_spare_servers | 24 | මෘදු උච්චාවචනයන් හැසිරවීම සඳහා, තදබදය අඩු වූ පසු මධ්යස්ථ ක්රියාවලි සංඛ්යාවක් රඳවා ගැනීමට එය CPU මධ්ය ගණන මෙන් 3 ගුණයකට (cores 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ක් යනු අතිශය සමගාමී තත්වයන් යටතේ, පද්ධතියට එකවර උපරිම ගතික HTTP ඉල්ලීම් 80ක් දක්වා හැසිරවිය හැකි බවයි.
ඔබට ධාරිතාව තවදුරටත් වැඩිදියුණු කිරීමට අවශ්ය නම්, ක්රියාවලියකට මතක භාවිතය අඩු කිරීම කෙරෙහි අවධානය යොමු කළ යුතුය.
- OPcache සක්රීය කරන්න:තුල
php.iniමධ්යම වින්යාසයopcache.enable=1හාopcache.memory_consumption=256බයිට්කේත හැඹිලිගත කිරීම මඟින් තනි ක්රියාවලියක මතක භාවිතය 200MB සිට 60~100MB දක්වා අඩු කළ හැකිය. - මතක සීමාව සාධාරණ ලෙස පාලනය කිරීම：将
php.iniමැදmemory_limitසීමා කර ඇත128Mනැත්නම්256Mතනි අසාමාන්ය ස්ක්රිප්ට් වැළැක්වීම සඳහාඅසීමිතඑය මතකය ගොඩක් පරිභෝජනය කරයි.
එක් ක්රියාවලියක මතක භාවිතය 100MB දක්වා පහත වැටුණු පසු...pm.max_children එය ආරක්ෂිතව උත්ශ්රේණි කළ හැක 150 ඊට අමතරව, සමගාමී හැකියාව දෙගුණයකට ආසන්න වී ඇත.
උපුටා දක්වන ලද අධිකාරී දෘෂ්ටිකෝණයන්
නිල Nginx ලියකියවිලි වල නිර්දේශයන්ට අනුව :
"සම්පත් ක්ෂය වීම වැළැක්වීම සඳහා කල් ඉකුත් වීමේ නියෝග සමඟ FastCGI යෙදුම් සැමවිටම නිරීක්ෂණය කළ යුතුය."
(මූලාශ්රය: Nginx Docs)
නිල PHP අත්පොතෙහි පැහැදිලිව සඳහන් වන්නේ:
"pm.max_children නිර්මාණය කළ යුතු උපරිම ළමා ක්රියාවලි ගණන නිර්වචනය කරයි. මෙය වඩාත්ම වැදගත් නියෝගයයි."
(මූලාශ්රය: PHP-FPM ලේඛනගත කිරීම)
මෙම අධිකාරී අදහස් අපගේ භාවිතයන් සමඟ පරිපූර්ණ ලෙස සමපාත වන අතර, ප්රශස්තිකරණ තර්කනය අත්දැකීම් මත පමණක් නොව, ප්රමිතිගත හොඳම භාවිතයන් මත ද පදනම් වී ඇති බව සනාථ කරයි.
නිගමනය: මගේ අදහස් සහ ප්රධාන උපුටා දැක්වීම්
ඉහළ සමගාමී අවස්ථා වලදී, CPU යනු එන්ජිම වන අතර, මතකය ඉන්ධන ටැංකිය වන අතර, PHP-FPM යනු බලඇණි යැවීමයි.
එන්ජිම කොතරම් බලවත් වුවත්, ඉන්ධන ටැංකිය ප්රමාණවත් නොවේ නම්, රථ පෙළ එතරම් දුරක් යන්නේ නැත.
සැබෑ විශේෂඥයින් පරාමිති අන්ධ ලෙස උපරිම නොකරයි, නමුත් නාස්තිය සහ පිටාර ගැලීම යන දෙකම වළක්වා ගැනීම සඳහා එක් එක් ක්රියාවලියේ මතක භාවිතය නිවැරදිව ගණනය කරයි.
ප්රශස්තිකරණයේ සාරය වන්නේ සීමිත සම්පත් සමඟ ප්රශස්ත සමතුලිතතාවය සොයා ගැනීමයි.
මෙය තාක්ෂණයක් පමණක් නොව දර්ශනයක් ද වේ.
එමනිසා, "cores ගණන සියල්ල තීරණය කරයි" යැයි විශ්වාස කිරීම නවත්වන්න. සමගාමී සීමාව සැබවින්ම තීරණය කරන්නේ මතකය පිළිබඳ ඔබේ පාලනයයි.
මතකයේ සෑම බිංදුවකින්ම උපරිම ප්රයෝජන ගනිමින්, ඔබේ VPS උපරිම විභවයට ප්රශස්ත කිරීමට පියවර ගන්න.
චෙන් වෙයිලියැන්ග්ගේ බ්ලොග් අඩවියේ ( https://www.chenweiliang.com/ ) බෙදාගත් "8-core 24GB VPS මතකය අවසන් වෙමින් පවතීද? HestiaCP යටතේ PHP-FPM ක්රියාවලි සංචිතයේ අතිශය සුසර කිරීම" යන ලිපිය ඔබට ප්රයෝජනවත් වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.
මෙම ලිපියේ සබැඳිය බෙදා ගැනීමට නිදහස් වන්න: https://www.chenweiliang.com/cwl-34509.html