אַרטיקל וועגווייַזער
די צאָל גלייכצייטיקע באַניצער וואָס אַ סערווער קען שעפּן דעפּענדס נישט אויף וויפֿל קערנס עס האט, נאָר אויף וויפֿל זכּרון יעדער פּראָצעס פֿאַרנוצט.
די אויסזאג קען קלינגען ווי אַ פּראָוואָקאַציע, אָבער דאָס איז די מערסט רעאַלע און ווייטיקדיקע דערפאַרונג אין די אָפּעראַציעס און וישאַלט אינדוסטריע.
פארוואס איז זכרון דער שליסל-פאטענטש?
אסאך מענטשן זעען א VPS מיט אן 8-קערן CPU און 24GB פון זכרון און טראכטן אונטערבאוואוסטזיניק אז זיי קענען לייכט לויפן הונדערטער PHP-FPM פראצעסן.
אבער, אין דער ווירקלעכקייט, איז די RSS זכּרון באַניץ פון איין PHP פּראָצעס אָפט אַזוי הויך ווי 200MB.
דאָס איז דער רעזולטאַט באַקומען דורך פאַקטישע טעסטינג דורך די קאָמאַנד ליניע:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
אין HestiaCP 'ס קאָמפּלעקסע פריימווערק און מולטי-פּלוגין סביבה, ספּעציעל אָן OPcache אָפּטימיזאַציע, איז 200MB די נאָרמע.
דאָס מיינט אַז זכּרון, נישט סי-פּי-יו, איז דער שווערער לימיט וואָס באַשטימט מאַקסימום קאָנקורענץ.
רעקאָמענדירטע קאָנפיגוראַציע טעקע (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 | 24 גיגאבייט גאַנץ זכּרון מינוס סיסטעם קערנעל און מיסקל/רעדיסנאך Nginx, בלייבט איבער בערך 16 גיגאבייט פאר PHP.16,384 MB / 200 MB ≈ 81.9עס שטעלן צו 80 קען אינגאנצן עלימינירן OOM (אויס פון זכּרון) בעת הויכע קאָנקורענץ. |
| pm.start_servers | 16 | פאָרהייצן ביים סטאַרטאַפּ איז געשטעלט צו צוויי מאָל די צאָל CPU קאָרעס (8 קאָרעס × 2 = 16) צו ענשור אַז דער סערוויס קען גלייך האַנדלען מיט גרונטלעכע קאָנקורענץ נאָך ריסטאַרטינג. |
| pm.min_spare_servers | 8 | שטעלט די CPU קערן צייל צו 8 קערנס צו זיכער מאכן אז נייע פארלאנגען קענען ווערן געענטפערט אין יעדער צייט בעת תקופות מיט נידריג טרעפיק. |
| pm.max_spare_servers | 24 | שטעלט עס צו 3 מאָל די צאָל CPU קערנס (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. - גלייַכבארע קאָנטראָל פון מעמאָרי_לימיט：将
php.iniמיטןmemory_limitבאגרענעצט צו128Mאָדער256Mצו פאַרהיטן יחידישע אַבנאָרמאַלע סקריפּטןאַנלימאַטאַדעס פארנוצט א סך זכרון.
אזוי שנעל ווי די זכּרון באַניץ פון איין פּראָצעס פאַלט צו 100MB...pm.max_children עס קען זיכער אַפּגרעידעד ווערן צו 150 דערצו, די גלייכצייטיגקייט מעגלעכקייט האט זיך כמעט פארדאפלט.
אויטאָריטעטיווע מיינונגען ציטירט
לויט די רעקאמענדאציעס אין דער אפיציעלער Nginx דאקומענטאציע :
"FastCGI אַפּליקאַציעס זאָלן שטענדיק זיין מאָניטאָרירט מיט טיימאַוט דירעקטיוון צו פאַרמייַדן רעסורסן אויסשעפּונג."
(מקור: נגינקס דאקומענטן)
דער אפיציעלער PHP מאנואל זאגט קלאר:
"pm.max_children דעפינירט די מאַקסימום צאָל קינד פּראָצעסן וואָס מען קען שאַפֿן. דאָס איז די וויכטיקסטע דירעקטיווע."
(מקור: PHP-FPM דאָקומענטאַציע)
די אויטאָריטעטיווע מיינונגען זענען פערפעקט אין איינקלאַנג מיט אונדזערע פּראַקטיקעס, וואָס באַווייַזט אַז אָפּטימיזאַציע לאָגיק איז נישט בלויז באַזירט אויף דערפאַרונג, נאָר אויך אויף סטאַנדאַרדיזירטע בעסטע פּראַקטיקעס.
מסקנא: מײַנע מיינונגען און שליסל ציטאטן
אין הויך-קאָנקורענסי סצענאַריאָס, איז די CPU דער מאָטאָר, די זכּרון איז דער ברענשטאָף טאַנק, און PHP-FPM איז דער פליט דיספּעטשער.
נישט קיין חילוק ווי שטאַרק דער מאָטאָר איז, אויב דער ברענשטאָף טאַנק איז נישט גרויס גענוג, וועט די קאָנוווי נישט גיין צו ווײַט.
אמתע עקספּערטן מאַקסימיזירן נישט בלינדערהייט די פּאַראַמעטערס, נאָר גאַנץ פּינקטלעך רעכענען אויס די זכּרון באַניץ פון יעדן פּראָצעס צו ויסמיידן ביידע וויסט און אָוווערפלאָו.
די עסענץ פון אָפּטימיזאַציע איז צו געפֿינען די אָפּטימאַלע באַלאַנס מיט לימיטירטע רעסורסן.
דאָס איז נישט נאָר אַ טעכנאָלאָגיע, נאָר אויך אַ פֿילאָסאָפֿיע.
דעריבער, הער אויף צו גלייבן אז "די צאל קערנס באשטימט אלעס." וואס באשטימט באמת די גלייכצייטיגקייט לימיט איז אייער קאנטראל איבער זכרון.
נעמט אקציע און אָפּטימיזירט אייער VPS צו זיין פולסטן פּאָטענציאַל, און נוצט אויס יעדן טראָפּן זכּרון אויף דעם בעסטן אופן.
האפענטלעך, דער ארטיקל "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" וואס איז געשערט געווארן אויף טשען ווייליאנג'ס בלאג ( https://www.chenweiliang.com/ ) וועט זיין נוצלעך פאר אייך.
פילט אייך פריי צו טיילן דעם לינק פון דעם ארטיקל: https://www.chenweiliang.com/cwl-34509.html