PHP-FPM tuning მცირე VPS-ზე უნდა დაიწყოს memory budget-ით და არა `pm.max_children`-ის შემთხვევითი ზრდით. მთავარი კითხვაა: რამდენ concurrent PHP request-ს იტანს VPS ისე, რომ database, OS და cache არ გაიწუროს?
ჯერ ერთი worker გაზომეთ
რეალურ traffic-ზე დააკვირდით PHP-FPM process-ების RSS memory-ს. თუ ერთი worker საშუალოდ 90 MB-ს მოიხმარს, 20 worker დაახლოებით 1.8 GB-ს მოითხოვს მხოლოდ PHP-სთვის. ეს მაგალითია და არა უნივერსალური ნორმა - თქვენი აპლიკაცია უნდა გაზომოთ.
4 GB VPS-ის სამუშაო memory budget
| კომპონენტი | რატომ სჭირდება RAM |
|---|---|
| OS + system services | საბაზო ოპერაცია და headroom |
| Database | buffers, cache, connections |
| PHP-FPM | worker count × რეალური RSS |
| Cache / monitoring / panel | დამატებითი მუდმივი მოხმარება |
WordPress-ის ოპტიმიზაციის გზამკვლევი განსაკუთრებით გამოსადეგია, რადგან worker tuning ვერ გამოასწორებს მძიმე plugin-ს ან ცუდ query-ს. database server-ის არჩევის სტატია დაგეხმარებათ RAM-ის სხვა მსხვილი მომხმარებლების დანახვაში.
dynamic თუ ondemand?
dynamic
კარგი საწყისი რეჟიმია ცვალებადი web traffic-ისთვის, როცა spare workers და limits გაზომვაზეა მორგებული.
ondemand
შეიძლება გამოგადგეთ დაბალი ან არარეგულარული traffic-ისას, როცა idle workers-ის RAM-ის შემცირება გინდათ.
როგორ იპოვოთ რეალური ზღვარი
- გაზომეთ peak concurrency;
- ნახეთ request duration;
- დააკვირდით queue-სა და `max_children reached` მოვლენებს;
- ერთდროულად შეამოწმეთ swap, DB latency და CPU;
- შეცვალეთ ერთი პარამეტრი და ისევ გაზომეთ.
Unmanaged VPS-ზე ეს tuning მთლიანად თქვენი stack-ის ნაწილია. თუ OS/web stack-ის ოპერირება არ გინდათ, შეადარეთ Managed VPS და ზუსტად დააზუსტეთ performance tuning-ის საზღვარი.
მარტივი formula, რომელიც მხოლოდ საწყისი შეფასებაა
საწყისი ზედა ზღვარი შეგიძლიათ ასე იფიქროთ:
ხელმისაწვდომი RAM PHP-სთვის ÷ ერთი რეალური worker-ის საშუალო RSS = თეორიული worker count.
მაგრამ მიღებულ რიცხვს პირდაპირ `pm.max_children`-ში ნუ ჩაწერთ. დაგჭირდებათ headroom traffic spike-ისთვის, DB memory-ის ზრდისთვის, OS page cache-ისთვის და არასტაბილური request-ებისთვის. სწორედ ამიტომ production limit ჩვეულებრივ თეორიულ maximum-ზე დაბალი უნდა იყოს.
რომელი metric გვეტყვის რეალურ პრობლემას?
| სიგნალი | რას შეიძლება ნიშნავდეს |
|---|---|
| `max_children reached` | concurrency limit ზედმეტად დაბალია ან requests ზედმეტად დიდხანს მუშაობს |
| Queue იზრდება, CPU თავისუფალია | worker limit ან blocking operation |
| Swap იზრდება | workers/DB/cache ერთად RAM-ს აჭარბებს |
| CPU 100%, queue იზრდება | მეტი workers შესაძლოა უარესიც გახდეს |
| რამდენიმე ძალიან ნელი request | slowlog/application profiling უფრო მნიშვნელოვანია |
PHP-FPM status და slowlog tuning-ის ნაწილია
სწორი tuning მხოლოდ `top`-ის ყურება არ არის. FPM status metrics გაჩვენებთ active/idle workers, queue და process-manager saturation-ს. Slowlog დაგეხმარებათ კონკრეტული PHP request-ის stack-ის დანახვაში, როცა ის ზედმეტად დიდხანს მუშაობს.
24-საათიანი tuning cycle
- ჩაიწერეთ baseline peak საათში;
- შეცვალეთ მხოლოდ ერთი ძირითადი parameter;
- გაუშვით იგივე traffic pattern;
- შეადარეთ p95 response time, queue, CPU, RAM და errors;
- თუ შედეგი უარესია, დაბრუნდით წინა config-ზე.
მთავარი შეცდომა არის capacity problem-ისა და application problem-ის ერთმანეთში არევა. თუ ერთი PHP request თვითონ 3 წამს მუშაობს ცუდი query-ის გამო, მეტი workers მხოლოდ უფრო მეტ ასეთ ნელ request-ს გაუშვებს ერთდროულად.
