PHP-FPM დაყენება: გამოიყენეთ pm static მაქსიმალური შესრულებისთვის

ამ სტატიის დაურედაქტირებელი ვერსია თავდაპირველად გამოქვეყნდა haydenjames.io და გამოქვეყნდა აქ მისი ნებართვით ავტორი.

მოკლედ გეტყვით, თუ როგორ უნდა დააკონფიგურიროთ PHP-FPM გამტარუნარიანობის გაზრდის, შეყოვნების შესამცირებლად და CPU და მეხსიერების უფრო თანმიმდევრულად გამოყენებისთვის. ნაგულისხმევად, PM (პროცესის მენეჯერი) ხაზი PHP-FPM არის დინამიურიდა თუ საკმარისი მეხსიერება არ გაქვთ, მაშინ ჯობია დააინსტალიროთ მოთხოვნა, საჭიროება. მოდით შევადაროთ php.net დოკუმენტაციაზე დაფუძნებული კონტროლის 2 ვარიანტი და ვნახოთ, როგორ განსხვავდება ჩემი რჩეული მათგან სტატიკური pm მაღალი მოცულობის ტრაფიკისთვის:

pm = დინამიური — ბავშვის პროცესების რაოდენობა დინამიურად არის კონფიგურირებული შემდეგი დირექტივების საფუძველზე: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = მოთხოვნით - პროცესები იქმნება მოთხოვნით (დინამიური შექმნისგან განსხვავებით, როდესაც pm.start_servers იხსნება სერვისის დაწყებისას).
pm = სტატიკური — ბავშვის პროცესების რაოდენობა ფიქსირდება და მითითებულია პარამეტრით pm.max_children.

დეტალებისთვის იხ გლობალური დირექტივების სრული სია php-fpm.conf.

მსგავსება PHP-FPM პროცესის მენეჯერსა და CPU სიხშირის კონტროლერს შორის

ეს შეიძლება ოფტოპური ჩანდეს, მაგრამ მე ვაპირებ ამის დაკავშირებას PHP-FPM კონფიგურაციის თემასთან. ვისაც ერთხელ მაინც არ განუცდია პროცესორის შენელება - ლეპტოპზე, ვირტუალურ აპარატზე ან სპეციალურ სერვერზე. გახსოვთ CPU სიხშირის სკალირება? ეს პარამეტრები ხელმისაწვდომია nix-ს და Windows-ს შეუძლიათ გააუმჯობესონ სისტემის მუშაობა და რეაგირება პროცესორის დროსელის პარამეტრის შეცვლით მოთხოვნა, საჭიროება on შესრულება*. ამჯერად შევადაროთ აღწერილობები და შევხედოთ მსგავსებებს:

გუბერნატორი=მოთხოვნილი — პროცესორის სიხშირის დინამიური მასშტაბირება მიმდინარე დატვირთვის მიხედვით. სწრაფად ხტება მაქსიმალურ სიხშირეზე და შემდეგ ამცირებს მას უმოქმედობის პერიოდების მატებასთან ერთად.
გუბერნატორი=კონსერვატიული= დინამიური სიხშირის სკალირება მიმდინარე დატვირთვის მიხედვით. ზრდის და ამცირებს სიხშირეს უფრო შეუფერხებლად, ვიდრე მოთხოვნით.
გუბერნატორი = შესრულება — სიხშირე ყოველთვის მაქსიმალურია.

დეტალებისთვის იხ პროცესორის სიხშირის რეგულატორის პარამეტრების სრული სია.

ხედავ მსგავსებებს? მე მინდოდა მეჩვენებინა ეს შედარება, რათა დაგარწმუნოთ, რომ მისი გამოყენება ჯობია pm სტატიკური PHP-FPM-სთვის.

პროცესორის რეგულატორის პარამეტრისთვის შესრულების ეხმარება უსაფრთხოდ გაზარდოს შესრულება, რადგან ის თითქმის მთლიანად არის დამოკიდებული სერვერის CPU ლიმიტზე. ამას გარდა, რა თქმა უნდა, არის ისეთი ფაქტორებიც, როგორიცაა ტემპერატურა, ბატარეის დატენვა (ლეპტოპში) და პროცესორის 100%-ზე მუდმივად მუშაობის სხვა გვერდითი მოვლენები. შესრულების პარამეტრი უზრუნველყოფს პროცესორის უსწრაფეს მუშაობას. წაიკითხეთ, მაგალითად, შესახებ force_turbo პარამეტრი Raspberry Pi-ში, რომლითაც RPi პანელი გამოიყენებს რეგულატორს შესრულების, სადაც მუშაობის გაუმჯობესება უფრო შესამჩნევი იქნება პროცესორის დაბალი საათის სიჩქარის გამო.

pm static-ის გამოყენება სერვერის მაქსიმალური მუშაობის მისაღწევად

PHP-FPM ვარიანტი pm სტატიკური დიდწილად დამოკიდებულია სერვერის თავისუფალ მეხსიერებაზე. თუ მეხსიერება დაბალია, უმჯობესია აირჩიოთ მოთხოვნა, საჭიროება ან დინამიური. მეორეს მხრივ, თუ მეხსიერება გაქვთ, შეგიძლიათ თავიდან აიცილოთ PHP პროცესების მენეჯერი pm-ის დაყენებით სტატიკური სერვერის მაქსიმალურ სიმძლავრემდე. სხვა სიტყვებით რომ ვთქვათ, თუ ყველაფერი კარგად არის გათვლილი, თქვენ უნდა დაადგინოთ pm.სტატიკური PHP-FPM პროცესების მაქსიმალურ მოცულობამდე, რომელიც შეიძლება შესრულდეს, დაბალი მეხსიერების ან ქეშის პრობლემების შექმნის გარეშე. მაგრამ არც ისე მაღალი, რომ გადატვირთოს პროცესორები და დააგროვოს PHP-FPM ოპერაციების მთელი რიგი, რომლებიც ელოდება შესრულებას..

ზემოთ მოცემულ ეკრანის სურათში სერვერს აქვს pm = სტატიკური და pm.max_children = 100, და ეს იკავებს დაახლოებით 10 გბ-ს ხელმისაწვდომი 32-დან. ყურადღება მიაქციეთ მონიშნულ სვეტებს, აქ ყველაფერი ნათელია. ამ ეკრანის სურათზე იყო დაახლოებით 200 აქტიური მომხმარებელი (60 წამზე მეტი) Google Analytics-ში. ამ დონეზე, PHP-FPM ბავშვური პროცესების დაახლოებით 70% ჯერ კიდევ უმოქმედოა. ეს ნიშნავს, რომ PHP-FPM ყოველთვის დაყენებულია სერვერის რესურსების მაქსიმალურ რაოდენობაზე, მიმდინარე ტრაფიკის მიუხედავად. უმოქმედო პროცესი ელოდება მოძრაობის პიკს და მყისიერად რეაგირებს. თქვენ არ გჭირდებათ ლოდინი pm შექმნის ბავშვის პროცესებს და შემდეგ შეწყვეტს მათ ვადის ამოწურვისას pm.process_idle_timeout. მე დავაყენე მნიშვნელობა ძალიან მაღალზე pm.max_requestsრადგან ეს არის სამუშაო სერვერი PHP-ში მეხსიერების გაჟონვის გარეშე. შეგიძლიათ დააინსტალიროთ pm.max_requests = 0 static-ით, თუ სრულიად დარწმუნებული ხართ არსებულ და მომავალ PHP სკრიპტებში. მაგრამ სჯობს სკრიპტების ხელახლა გაშვება დროთა განმავლობაში. დააყენეთ მოთხოვნების დიდი რაოდენობა, რადგან გვსურს თავიდან ავიცილოთ არასაჭირო pm ხარჯები. მაგალითად, სულ მცირე pm.max_requests = 1000 - რაოდენობის მიხედვით pm.max_children და მოთხოვნის რაოდენობა წამში.

სკრინშოტი აჩვენებს ბრძანებას Linux top, გაფილტრული u (მომხმარებლის) და PHP-FPM მომხმარებლის სახელით. ნაჩვენებია მხოლოდ პირველი 50 ან მეტი პროცესი (ზუსტად არ დავთვალე), მაგრამ არსებითად ზედა აჩვენებს საუკეთესო სტატისტიკას, რომელიც ჯდება ტერმინალის ფანჯარაში. ამ შემთხვევაში დალაგებულია % CPU (%CPU) მიხედვით. ყველა 100 PHP-FPM პროცესის სანახავად, გაუშვით ბრძანება:

top -bn1 | grep php-fpm

როდის გამოვიყენოთ pm ondemand და დინამიური

თუ იყენებ pm-ს დინამიური, ჩნდება ასეთი შეცდომები:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

სცადეთ შეცვალოთ პარამეტრი, შეცდომა არ გაქრება, მაგალითად აღწერილია ამ პოსტში Serverfault-ზე. ამ შემთხვევაში, pm.min მნიშვნელობა ძალიან მცირე იყო და რადგან ვებ ტრაფიკი ძალიან განსხვავდება და აქვს მაღალი მწვერვალები და ღრმა ხეობები, ძნელია pm-ის ადეკვატურად რეგულირება. დინამიური. ჩვეულებრივ pm გამოიყენება მოთხოვნა, საჭიროება, როგორც გვირჩევენ იმავე პოსტში. მაგრამ ეს კიდევ უფრო უარესია, რადგან მოთხოვნა, საჭიროება წყვეტს უმოქმედო პროცესებს ნულამდე, როდესაც არის მცირე ან საერთოდ არ არის ტრაფიკი და თქვენ მაინც დაგიჯდებათ ტრაფიკის შეცვლა. თუ, რა თქმა უნდა, არ დაუწესებთ ლოდინის დიდ დროს. და მაშინ უმჯობესია გამოიყენოთ pm.სტატიკური + მაღალი რიცხვი pm.max_requests.

PM დინამიური და განსაკუთრებით მოთხოვნა, საჭიროება შეიძლება სასარგებლო იყოს, თუ თქვენ გაქვთ მრავალი PHP-FPM აუზი. მაგალითად, თქვენ მასპინძლობს მრავალ cPanel ანგარიშს ან მრავალ ვებსაიტს სხვადასხვა აუზში. მე მაქვს სერვერი, ვთქვათ, 100+ cpanel ანგარიშებით და დაახლოებით 200 დომენით, და pm.static ან თუნდაც დინამიური არ მიშველის. ყველაფერი რაც თქვენ გჭირდებათ აქ არის მოთხოვნა, საჭიროებაბოლოს და ბოლოს, ვებსაიტების ორ მესამედზე მეტი იღებს მცირე ტრაფიკს ან საერთოდ არ იღებს ტრაფიკს და თან მოთხოვნა, საჭიროება ყველა ბავშვის პროცესი იშლება, რაც დიდ მეხსიერებას დაგვიზოგავს! საბედნიეროდ, cPanel-ის დეველოპერებმა შენიშნეს ეს და დააყენეს მნიშვნელობა ნაგულისხმევად მოთხოვნა, საჭიროება. ადრე, როცა ნაგულისხმევი იყო დინამიური, PHP-FPM საერთოდ არ იყო შესაფერისი დაკავებული საერთო სერვერებისთვის. ბევრმა გამოიყენა suPHP, რადგან pm დინამიური მოიხმარს მეხსიერებას თუნდაც უმოქმედო აუზებით და cPanel PHP-FPM ანგარიშებით. დიდი ალბათობით, თუ ტრაფიკი კარგია, თქვენ არ იქნებით სერვერზე ჰოსტინგი დიდი რაოდენობით PHP-FPM აუზებით (გაზიარებული ჰოსტინგი).

დასკვნა

თუ იყენებთ PHP-FPM-ს და თქვენი ტრაფიკი მძიმეა, პროცესის მენეჯერები მოთხოვნა, საჭიროება и დინამიური PHP-FPM-ისთვის იქნება შეზღუდული გამტარუნარიანობა მათი თანდაყოლილი ზედნადების გამო. გაიგეთ თქვენი სისტემა და დააკონფიგურირეთ PHP-FPM პროცესები სერვერის მაქსიმალური სიმძლავრის მიხედვით. პირველი ნაკრები pm.max_children დამოკიდებულია pm-ის მაქსიმალურ გამოყენებაზე დინამიური ან მოთხოვნა, საჭიროებადა შემდეგ გაზარდეთ ეს მნიშვნელობა იმ დონემდე, რომ მეხსიერება და პროცესორი იმუშავებს გადატვირთვის გარეშე. ამას შეამჩნევთ pm სტატიკური, ვინაიდან ყველაფერი გაქვთ მეხსიერებაში, ტრაფიკის აწევა გამოიწვევს CPU-ს ნაკლებ მატებას დროთა განმავლობაში და სერვერისა და CPU დატვირთვის საშუალო მაჩვენებლები დაიწევს. PHP-FPM პროცესის საშუალო ზომა დამოკიდებულია ვებ სერვერზე და მოითხოვს ხელით კონფიგურაციას, ამიტომ პროცესების უფრო ავტომატიზირებული მენეჯერები არიან დინამიური и მოთხოვნა, საჭიროება - უფრო პოპულარული. იმედი მაქვს, რომ სტატია სასარგებლო იყო.

DUP დამატებულია საორიენტაციო სქემა ab. თუ PHP-FPM პროცესები მეხსიერებაშია, შესრულება იზრდება მეხსიერების მოხმარების ხარჯზე, სადაც ისინი სხედან და ელოდებიან. იპოვეთ საუკეთესო ვარიანტი თქვენთვის.

წყარო: www.habr.com