სტატიების დირექტორია
სერვერის მიერ ერთდროულად მომუშავე მომხმარებლების რაოდენობა დამოკიდებულია არა მის ბირთვების რაოდენობაზე, არამედ იმაზე, თუ რამდენ მეხსიერებას მოიხმარს თითოეული პროცესი.
ეს განცხადება შეიძლება პროვოკაციად ჟღერდეს, მაგრამ ეს ოპერაციებისა და ტექნიკური მომსახურების ინდუსტრიაში ყველაზე რეალური და მტკივნეული გამოცდილებაა.
რატომ არის მეხსიერება მთავარი შემაფერხებელი ფაქტორი?
ბევრი ადამიანი ხედავს VPS-ს 8-ბირთვიანი CPU-თი და 24 GB მეხსიერებით და ქვეცნობიერად ფიქრობს, რომ მათ შეუძლიათ მარტივად გაუშვან ასობით PHP-FPM პროცესი.
თუმცა, სინამდვილეში, ერთი PHP პროცესის RSS მეხსიერების გამოყენება ხშირად 200 მბ-ს აღწევს.
ეს არის შედეგი, რომელიც მიღებულია ბრძანების ხაზის მეშვეობით რეალური ტესტირების შედეგად:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP- ის რთულ ჩარჩოსა და მრავალპლაგინიან გარემოში, განსაკუთრებით OPcache ოპტიმიზაციის გარეშე, 200 მბ ნორმაა.
ეს ნიშნავს, რომ ოპერატიული მეხსიერება და არა პროცესორი არის მკაცრი ლიმიტი, რომელიც განსაზღვრავს მაქსიმალურ ერთდროულობას.
რეკომენდებული კონფიგურაციის ფაილი (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 GB ოპერატიული მეხსიერება სისტემის ბირთვის გარეშე MySQL/RedisNginx-ის შემდეგ, PHP-სთვის დაახლოებით 16 GB რჩება.16,384 MB / 200 MB ≈ 81.980-ზე დაყენებამ შეიძლება სრულად აღმოფხვრას OOM (მეხსიერების ამოწურვა) მაღალი პარალელური რეჟიმის დროს. |
| pm.start_servers | 16 | გაშვებისას წინასწარი გათბობა დაყენებულია CPU ბირთვების ორჯერ მეტ რაოდენობაზე (8 ბირთვი × 2 = 16), რათა უზრუნველყოფილი იყოს, რომ სერვისმა გადატვირთვის შემდეგ მყისიერად შეძლოს ძირითადი პარალელური მუშაობის დამუშავება. |
| pm.min_spare_servers | 8 | დააყენეთ CPU ბირთვების რაოდენობა 8 ბირთვზე, რათა უზრუნველყოთ ახალ მოთხოვნებზე რეაგირება ნებისმიერ დროს დაბალი ტრაფიკის პერიოდებში. |
| pm.max_spare_servers | 24 | დააყენეთ ის CPU ბირთვების სამჯერ მეტ რაოდენობაზე (8 ბირთვი × 3 = 24), რათა შეინარჩუნოთ პროცესების ზომიერი რაოდენობა ტრაფიკის შემცირების შემდეგ და გაუმკლავდეთ მცირე რყევებს. |
| pm.max_requests | 500 | თუ ერთი პროცესი 200 მბ-ს მიაღწევს, მოთხოვნების რაოდენობის 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ბაიტკოდის ქეშირებას შეუძლია შეამციროს ერთი პროცესის მეხსიერების გამოყენება 200 მბ-დან 60~100 მბ-მდე. - memory_limit-ის გონივრული კონტროლი:ვილ
php.iniშუაmemory_limitშეზღუდულია128M或256Mინდივიდუალური პათოლოგიური სცენარების თავიდან ასაცილებლადშეუზღუდავიის დიდ მეხსიერებას მოიხმარს.
როგორც კი ერთი პროცესის ოპერატიული მეხსიერების გამოყენება 100 მბ-მდე შემცირდება...pm.max_children მისი უსაფრთხოდ განახლება შესაძლებელია 150 გარდა ამისა, ერთდროული მუშაობის შესაძლებლობა თითქმის გაორმაგდა.
მოყვანილი ავტორიტეტული შეხედულებები
Nginx-ის ოფიციალურ დოკუმენტაციაში მოცემული რეკომენდაციების თანახმად :
„რესურსების ამოწურვის თავიდან ასაცილებლად, FastCGI აპლიკაციები ყოველთვის უნდა კონტროლდებოდეს ვადის ამოწურვის დირექტივებით.“
(წყარო: Nginx Docs)
PHP-ის ოფიციალურ სახელმძღვანელოში ნათლად წერია:
„pm.max_children განსაზღვრავს შვილობილი პროცესების მაქსიმალურ რაოდენობას, რომლებიც უნდა შეიქმნას. ეს ყველაზე მნიშვნელოვანი დირექტივაა.“
(წყარო: PHP-FPM დოკუმენტაცია)
ეს ავტორიტეტული შეხედულებები იდეალურად შეესაბამება ჩვენს პრაქტიკას, რაც ადასტურებს, რომ ოპტიმიზაციის ლოგიკა არა მხოლოდ გამოცდილებაზე, არამედ სტანდარტიზებულ საუკეთესო პრაქტიკაზეც არის დაფუძნებული.
დასკვნა: ჩემი შეხედულებები და ძირითადი ციტატები
მაღალი პარალელურობის სცენარებში, CPU არის ძრავა, მეხსიერება არის საწვავის ავზი, ხოლო PHP-FPM არის ფლოტის დისპეჩერი.
რაც არ უნდა ძლიერი იყოს ძრავა, თუ საწვავის ავზი საკმარისად დიდი არ არის, კოლონა დიდ მანძილზე ვერ წავა.
ნამდვილი ექსპერტები ბრმად არ ზრდიან პარამეტრებს მაქსიმუმამდე, არამედ ზუსტად ითვლიან თითოეული პროცესის მეხსიერების გამოყენებას, რათა თავიდან აიცილონ როგორც დანაკარგები, ასევე გადავსება.
ოპტიმიზაციის არსი შეზღუდული რესურსებით ოპტიმალური ბალანსის პოვნაა.
ეს არა მხოლოდ ტექნოლოგიაა, არამედ ფილოსოფია.
ამიტომ, შეწყვიტეთ იმის დაჯერება, რომ „ბირთვების რაოდენობა განსაზღვრავს ყველაფერს“. რაც სინამდვილეში განსაზღვრავს პარალელურობის ლიმიტს, არის თქვენი კონტროლი მეხსიერებაზე.
მიიღეთ ზომები და ოპტიმიზაცია გაუკეთეთ თქვენს VPS-ს მის მაქსიმალურ პოტენციალზე, მაქსიმალურად გამოიყენეთ მეხსიერების ყოველი წვეთი.
იმედია, ჩენ ვეილიანგის ბლოგზე ( https://www.chenweiliang.com/ ) გამოგადგებათ სტატია „8-ბირთვიანი 24GB VPS-ის მეხსიერება იწურება? PHP-FPM პროცესების პულის ექსტრემალური რეგულირება HestiaCP-ის ქვეშ“.
თავისუფლად გაგვიზიარეთ ამ სტატიის ბმული: https://www.chenweiliang.com/cwl-34509.html