HestiaCP PHP-FPM ağır yük altında mı? Dinamik web sayfası 500 hatası mı? Bu optimizasyon hemen etkili olacaktır!

Bu durumla hiç karşılaştınız mı? Web siteniz aniden yavaşlıyor, hatta 500 hatası veriyor. PHP-FPM'yi yeniden başlatmak sorunu çözüyor , ancak bir süre sonra sorun tekrar ortaya çıkıyor? Bu inanılmaz derecede sinir bozucu!

Bu neden oluyor? Aslında, bu genellikle yanlış PHP-FPM işlem havuzu yapılandırmasından veya yetersiz sunucu kaynaklarından kaynaklanır. Bugün, web sitenizin kaya gibi sağlam istikrarını sağlamak için HestiaCP altında PHP-FPM'yi kapsamlı bir şekilde optimize edeceğiz !

PHP-FPM'nin aşırı yüklenmesinin temel nedeni

PHP-FPM , dinamik istekleri yönetmekten sorumlu olan PHP'nin süreç yöneticisidir . Uygunsuz yapılandırma şunlara yol açabilir:

• Sunucu kaynakları tükendi, PHP-FPM'nin yeni isteklere zamanında yanıt verememesine neden oluyor;
• Çok az işlem, trafik aniden arttığında, zamanında işlenememektedir;
• İşlem kullanımı çok yüksekCPU yükünün patlamasına neden olur.

PHP-FPM'nin aşırı yüklendiğini nasıl anlarım?

kullanabilirsiniz top 或 htop CPU ve bellek kullanımını görüntüleme komutu:

top -c

Aşağıdakine benzer işlem bilgileri görüyorsanız, PHP-FPM'nin yüksek yük altında çalıştığı anlamına gelir:

1669293 abc     20   0  790284 227880 185568 R  73.1   0.9   1:30.09 php-fpm: pool chenweiliang.com                                                    
1669522 abc     20   0  801924 224224 170236 R  69.9   0.9   0:59.01 php-fpm: pool chenweiliang.com

Bu işlemlerin CPU'nun %70'inden fazlasını kullandığını görüyor musunuz? Eğer bu sık sık oluyorsa, PHP-FPM'nizde kesinlikle bir sorun var demektir!

Peki sunucunun aşırı yüklenmesini önlemek için PHP-FPM yapılandırmasını nasıl optimize edebiliriz?

PHP-FPM işlem havuzu optimizasyonu (çekirdek parametre ayarlaması)

İlk olarak aç php-fpm Yapılandırma Dosyaları:

sudo nano /etc/php/*/fpm/pool.d/www.conf

• *PHP sürümünüzü (örneğin PHP8.5) değiştirin ve şununla değiştirin:/etc/php/8.3/fpm/pool.d/www.conf

HestiaCP tarafından ayarlanan PHP sürümünü sorgulayın

v-list-web-domain user domain.com

Örneğin:

v-list-web-domain abc chenweiliang.com

Çıktıda aşağıdakine benzer bir şey göreceksiniz:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Bu, web sitesinin PHP 8.5 kullandığını gösterir.

PHP-FPM yapılandırmanıza bir göz atalım:

[chenweiliang.com]
listen = /run/php/php8.5-fpm-chenweiliang.com.sock
listen.owner = abc
listen.group = www-data
listen.mode = 0660

user = abc
group = abc

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s

Görebilirsin ki senin pm Kullanılan ondemand,Boş zamanlarda kaynak kullanımını azaltabilmesine rağmen, trafiğin aniden artması durumunda, işlem zamanında cevap veremeyebilir., 500 hatasıyla sonuçlanır.

www.conf: Sistemin yerleşik "evrensel kaynak havuzu"

PHP-FPM'yi kurduktan sonra, sistem size otomatik olarak şunları sağlayacaktır... www.conf dosya.
onunKonumlandırmaÇok basit; genellikle şuraya bağlı, kullanıma hazır varsayılan bir işlem havuzudur... www veri Kullanıcı indirmesi.

Bu tip havuz, özellikle tek lokasyonlu ortamlar için uygundur: yapılandırması hafiftir ve parametrelerin tümü aşağıdaki gibi genel şablonlardır:

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm.max_children = 5

Sadece tek bir siteye ev sahipliği yapıyorsanız, onu herhangi bir ek zahmete girmeden doğrudan ve güvenilir bir şekilde kullanabilirsiniz.

etufo.org.conf: Özel havuz

Birden fazla siteyi yönetmeye başladığınızda, herkesi aynı havuzda tutamazsınız.
Bu aşamada, HestiaCP otomatik olarak her site için ayrı bir havuz oluşturacaktır, örneğin... etufo.org.confAlan adları konusunda uzmanlaşmıştır. etufo.org 服务.

Genellikle oynanan yöntem şöyledir:

• Kullanıcıları ve grupları değiştirin:user = etufo,group = etufo
• Bağımsız izleme:listen = /run/php/etufo.sock
• İşlem sayısının ayarlanması, yüksek eşzamanlılık koşullarında bile son derece istikrarlı bir çalışma sağlar.
• Ayrı günlük dosyaları, sorun gidermeyi daha kolay hale getirir.

Faydaları apaçık ortada: güvenli izolasyon . Bir site tehlikeye girse bile, diğerleri etkilenmeden kalır.

dummy.conf: sahte dosya

kukla.conf Bunlar genellikle sistem tarafından sağlanan örnekler veya şablonlardır.
Manuel olarak değiştirip etkinleştirmediğiniz sürece çalışmaz.
Bunun önemi, yeni bir havuz yapılandırmasının nasıl yazılacağını anlatan bir "kullanım kılavuzu" gibidir.

Havuzu neden bölüyoruz?

• 安全 性Çakışan izinleri önlemek için farklı siteler için farklı kullanıcılar kullanın.
• Genç adamHer bir havuz için işlem sayısı ayrı ayrı ayarlanabiliyor, bu da trafik talebine bağlı olarak esnek ayarlamalara olanak tanıyor.
• İzolasyonGünlük kayıtları, hatalar ve dinleme adresleri birbirinden ayrı tutulduğu için sorun giderme kolaylaşıyor.

Örneğin, www.conf çökse bile, etufo.org.conf normal şekilde çalışmaya devam edecek ve tüm sunucuyu çökertmeyecektir.

实际场景

• Tek lokasyonlu sunucuwww.conf yeterlidir.
• Çoklu site sunucusuHer sitenin kendine ait bağımsız bir .conf dosyası vardır, örneğin etufo.org.conf.
• kukla.confSadece bilgilendirme amaçlıdır, tavsiye edilmez.

Yapılandırma Karşılaştırması

www.conf (varsayılan havuz)

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 5

etufo.org.conf (Özel Havuz)

[etufo.org]
user = etufo
group = etufo
listen = /run/php/etufo.sock
pm = dynamic
pm.max_children = 20
access.log = /var/log/php-fpm/etufo.access.log

Başlıca farklılıklar şunlardır: kullanıcı kimliği, dinleme adresi ve işlem sayısı.

1. PHP-FPM işlem havuzu parametrelerini ayarlayın

Yapılandırma şunu kullanıyorsa dynamicBu, bazı iş süreçlerini önceden başlatıp, talep hacmine göre dinamik olarak ayarlamayı sağlayan, böylece talep hacmi aniden arttığında daha hızlı yanıt verebilen bir yöntemdir.

Belirli miktarda trafiğe sahip web siteleri için kullanılması önerilir pm = dynamicÇünkü yüksek eşzamanlılık sırasında belirli miktarda boşta işlem tutabilir ve 500 hatadan kaçınabilir.

Sadece erişim hacmi çok düşük olduğunda ve bellek kaynakları kısıtlı olduğunda kullanılması önerilir. pm = ondemand Kaynakları korumak için.

Önerilen dynamicve optimize edin pm.max_children Ve diğer parametreler:

pm = dynamic
pm.max_children = 16  ; 根据服务器资源调整，建议值：CPU 核心数 × 2
pm.start_servers = 4   ; 初始进程数，建议设为 max_children × 25%
pm.min_spare_servers = 2  ; 最小空闲进程数
pm.max_spare_servers = 7  ; 最大空闲进程数
pm.max_requests = 3000    ; 每个子进程处理完 3000 个请求后自动重启
pm.process_idle_timeout = 10s  ; 空闲进程 10s 后自动退出

Neden bunu böyle değiştirmek istiyorsun?

• pm = dynamic:İsteğe bağlı olarak oluşabilecek beklemeleri önlemek için süreçleri daha esnek bir şekilde tahsis edin;
• pm.max_children = 16: Çok az sayıda işlemden kaynaklanan 500 hatayı önleyin;
• pm.start_servers = 5: Yavaş işlem başlatmayı önleyin;
• pm.max_requests = 3000:Bellek sızıntılarını önleme, süreci düzenli olarak geri dönüştürün.

2. Uzun süreli meşguliyeti önlemek için PHP betiklerinin yürütme süresini sınırlayın

request_terminate_timeout = 30s  ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M  ; 限制 PHP 进程最大内存占用

Bu, aşırı CPU tüketimi yapan bazı PHP komut dosyalarının sunucunun çökmesine neden olmasını önler.

Kaydettikten sonra PHP işlemini yeniden başlatın:

sudo systemctl restart php8.3-fpm

VPS yapılandırmasına göre PHP-FPM'yi optimize edin.

VPS yapılandırma örneği:

• Açıklama: VPS 3 NVMe
• Disk Alanı: 300 GB
• CPU çekirdeği: 8
• RAM: 24 GB

VPS yapılandırmanıza ( 8 CPU çekirdeği, 24 GB RAM ) göre, sunucu kaynaklarınız fazlasıyla yeterli. PHP-FPM için 24 GB RAM, çok yüksek sayıda eş zamanlı işlem yapılandırmanıza olanak tanır.

Üretim ortamında, genellikle sistemin kendisi, Apache veritabanları ( MySQL /MariaDB gibi) ve önbellekler ( Redis / Memcached gibi) için yeterli bellek (örneğin 8 GB-12 GB) ayırırız ve kalan 12 GB-16 GB belleği tamamen PHP-FPM'ye tahsis ederiz.

PHP işlemi başına ortalama 40-60 MB bellek kullanımı göz önüne alındığında , 1 GB bellek yaklaşık 16-25 işlemi çalıştırabilir.

Aşağıda, WordPress'ün kapasitesini önemli ölçüde artırabilecek ve ani trafik artışları nedeniyle çökmesini önleyebilecek, size özel olarak hazırlanmış yüksek eşzamanlılık ve yüksek performanslı bir FPM yapılandırması bulunmaktadır:

pm = dynamic

; 允许的最大 PHP 进程数（12GB 内存 / 40MB ≈ 300）
; 8核CPU搭配300个进程，可以轻松应对极高并发，且不至于让内存溢出
pm.max_children = 300

; 启动时创建的初始进程数（CPU核心数 * 4）
pm.start_servers = 32

; 维持的最小空闲进程数（服务器空闲时保留的进程，保证随时响应）
pm.min_spare_servers = 16

; 维持的最大空闲进程数（超过这个数量的空闲进程会被释放）
pm.max_spare_servers = 64

; 每个进程处理1000个请求后自动重启，高配置服务器可适当调大，有效防止WP插件内存泄露
pm.max_requests = 1000

; 单个请求最大执行时间，超时60秒强杀，防止死锁卡死
request_terminate_timeout = 60s

; 慢日志路径及触发阈值（请求超过5秒则记录，用于排查性能瓶颈）
slowlog = /var/log/php8.5-fpm.log.slow
request_slowlog_timeout = 5s

💡 Bu yapılandırmanın nedeni nedir?

1. pm.max_children = 300Bu temel bir optimizasyondur. Önceki 50 işlemci yapılandırmanız, 24 GB bellek için çok muhafazakardı. Trafikte ani artışlar (veya arka planda çalışan botlar) yaşandığında, 50 işlemci anında yetersiz kalacak ve bağlantı zaman aşımına neden olacaktı. Bunu 300'e çıkarmak, sunucunuzun eşzamanlı işlem kapasitesini birkaç kat artırabilir.
2. pm.start_servers / `min_spare_servers8 CPU çekirdeğine sahip olduğunuz için, başlangıçta ve normalde daha fazla boşta bekleyen işlemi tutabilirsiniz; bu da çok çekirdekli işlemci avantajından yararlanmanıza ve işlem oluşturulmasını beklemeden yeni istekleri anında açmanıza olanak tanır.
3. pm.max_requests = 1000500'den 1000'e yükseltin. Belleğiniz büyük ve işlemlerin sık sık yeniden başlatılmasına gerek yok. 1000'e yükseltmek, sık işlem sonlandırma ve oluşturma işlemlerinden kaynaklanan CPU tüketimini azaltabilir.

Yavaşlık günlüğünü inceleyin:

tail -f /var/log/php8.5-fpm.log.slow
tail -f /var/log/php8.4-fpm.log.slow

Değişiklikleri yaptıktan sonra, değişikliklerin geçerli olması için PHP-FPM hizmetini yeniden başlatmayı unutmayın.

systemctl restart php8.5-fpm

İlerlemeyi her an takip edebilmek için PHP-FPM durum izlemeyi etkinleştirin

PHP-FPM süreç izleme özelliğini etkinleştirmek, sunucu aşırı yüklenmesini önlemek için aktif süreç sayısını ve istek bekleme durumunu istediğiniz zaman görüntülemenizi sağlar .

在 php-fpm.conf Eklendi:

pm.status_path = /status

Daha sonra Nginx yapılandırması:

location /status {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

Bu şekilde yapabilirsiniz http://yourdomain.com/status PHP-FPM'i çalışırken görün!

Sorunları hızla gidermek için PHP-FPM günlüklerini optimize edin

在 php-fpm.conf Cevap:

php_admin_value[error_log] = /var/log/php-fpm/error.log
php_admin_value[log_errors] = On
php_admin_value[error_reporting] = E_ALL
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s  ; 执行超过 5s 的脚本记录到日志

Bu şekilde 500 hatası oluştuğunda doğrudan log'u görüntüleyebilirsiniz:

tail -f /var/log/php-fpm/error.log

PHP'nin aşağıdaki gibi bir hata bildirip bildirmediğine bakın: out of memory,script execution timeout 等.

Bellek sızıntılarını önlemek için PHP-FPM'yi düzenli olarak yeniden başlatın

geçebilir cron Uzun süre çalışan işlemlerin neden olabileceği hataları önlemek için PHP-FPM'yi düzenli olarak yeniden başlatın.Bellek Sızıntıları.

crontab -e

PHP-FPM'yi her gün sabah 3'te otomatik olarak yeniden başlatmak için aşağıdaki zamanlanmış görevi ekleyin:

0 3 * * * /usr/sbin/service php8.5-fpm restart

Peki ya sorun devam ederse? Daha fazla optimizasyon!

Yukarıdaki optimizasyonları uyguladıktan sonra hala ara sıra 500 hatasıyla karşılaşıyorsanız , aşağıdaki optimizasyonlarla devam edebilirsiniz:

1. PHP yürütme verimliliğini artırmak için OPcache'i etkinleştirin

OPcache henüz etkinleştirilmemişse, bunu şu şekilde kurabilirsiniz (örnek olarak Ubuntu'yu kullanarak):

sudo apt install php8.5-opcache -y

Daha sonra düzenle php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.validate_timestamps=0

• opcache.validate_timestamps=0
• Gerçek zamanlı algılamayı devre dışı bırakınDosya sistemi G/Ç işlemlerini azaltın ve performansı artırın.

• Ancak bu, PHP dosyalarında değişiklik yaptıktan sonra önbelleği manuel olarak temizlemeniz (PHP hizmetini yeniden başlatmanız) gerektiği anlamına gelir.

Yapılandırmayı değiştirdikten sonra, değişikliklerin geçerli olması için PHP hizmetini yeniden başlatmanız gerekir.

sudo systemctl restart php<版本>-fpm

Etki? PHP sayfa yürütme hızı büyük ölçüde iyileştirildi!

2. Nginx yapılandırma optimizasyonu

Nginx ile ilgili parametrelerin makul olduğundan emin olun, örneğin: fastcgi_read_timeout Uzun yürütme süresi nedeniyle PHP betiklerinin Nginx tarafından sonlandırılmasını önlemek için bunu uygun şekilde ayarlayın:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Özet: PHP-FPM'i optimize edin ve web siteniz artık çökmesin!

Bu optimizasyondan sonra hangi ayarlamaları yaptık?

✅ PHP-FPM işlem havuzunun optimize edilmesi, kullan ondemandVe optimize et pm.max_children parametre;
✅ PHP betiklerinin yürütme süresini sınırlama, uzun vadede CPU işgalini önlemek için;
✅ PHP-FPM izlemeyi etkinleştir, süreç yükünü gerçek zamanlı olarak görüntüleyin;
✅ PHP-FPM günlüklerini optimize etme, 500 hatayı hızla giderin;
✅ PHP-FPM'yi düzenli olarak yeniden başlatın, bellek sızıntılarını önleyin;
✅ OPcache'i etkinleştir, PHP yürütme verimliliğini artırın;
✅ Nginx Yapılandırmasını Optimize Etme, zaman aşımı sorunlarını önlemek için.

Bu optimizasyondan sonra PHP-FPM yükü büyük ölçüde azalacak ve web sitesinin işleyişi daha kararlı hale gelecektir! 🔥

Hemen deneyin! 💪🚀

HestiaCP ile PHP-FPM şablonlarını özelleştirme hakkında daha fazla bilgi edinmek istiyorsanız, bu makale size daha derin bir anlayış kazandıracaktır:

👉 HestiaCP Özel PHP-FPM Şablonu: PHP 8.5 Performans Optimizasyonunun Sırları ▼

🔗HestiaCP Özel PHP-FPM Şablonu: PHP 8.5 Performans Optimizasyonunun Sırları

Bu içerikte şunları göreceksiniz:

• Yüksek eşzamanlılık optimizasyon teknikleri: Makul süreç yapılandırmasıyla yanıt hızını nasıl artırabilirsiniz?
• Güvenlik izolasyon çözümü: Siteler arası erişim risklerini önleyin ve hesap istikrarını sağlayın.
• Günlükler ve izleme: Yavaşlık günlüklerini kullanarak darboğazları tespit edin ve web sitesi performansını sürekli olarak optimize edin.