Cara menggunakan optimize php-fpm nginx

Saya telah mengalami masalah yang sangat aneh yang saya tidak yakin bagaimana men-debug lebih lanjut. Saya memiliki instance Ubuntu Ubuntu NGINX + PHP5-FPM + APC dan ada situs web yang diinstal di atasnya yang merupakan kerangka kerja PHP yang kompleks. Saat mencoba men-debug masalah, saya mengurangi alurnya: banyak kelas besar disertakan, objek utama dibuat, sesi dimulai, array konfigurasi diambil dari memcached, file XML diambil dari memcached, HTML template disertakan, output dikirim ke klien.

Lalu saya menggunakan alat http_load untuk menempatkan situs web di bawah beban 20 permintaan per detik: http_load -timeout 10 -rate 20 -fetches 10000 ./urls.txt

Apa yang terjadi selanjutnya agak aneh. top menunjukkan banyak proses php5-fpm yang menghasilkan masing-masing mengambil beberapa% dari CPU dan semuanya berjalan dengan lancar, seperti ini:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28440 www-data 20 0 67352 10m 5372 S 4.3 1.8 0:20.33 php5-fpm
28431 www-data 20 0 67608 10m 5304 S 3.3 1.8 0:16.77 php5-fpm
28444 www-data 20 0 67352 10m 5372 S 3.3 1.8 0:17.17 php5-fpm
28445 www-data 20 0 67352 10m 5372 S 3.0 1.8 0:16.83 php5-fpm
28422 www-data 20 0 67608 10m 5292 S 2.3 1.8 0:18.99 php5-fpm
28424 www-data 20 0 67352 10m 5368 S 2.0 1.8 0:16.59 php5-fpm
28438 www-data 20 0 67608 10m 5304 S 2.0 1.8 0:17.91 php5-fpm
28439 www-data 20 0 67608 10m 5304 S 2.0 1.8 0:23.34 php5-fpm
28423 www-data 20 0 67608 10m 5292 S 1.7 1.8 0:20.02 php5-fpm
28430 www-data 20 0 67608 10m 5300 S 1.7 1.8 0:15.77 php5-fpm
28433 www-data 20 0 67352 10m 5372 S 1.7 1.8 0:17.08 php5-fpm
28434 www-data 20 0 67608 10m 5292 S 1.7 1.8 0:18.56 php5-fpm
20648 memcache 20 0 51568 8192 708 S 1.3 1.3 2:51.06 memcached
28420 www-data 20 0 69876 13m 6300 S 1.3 2.3 0:20.89 php5-fpm
28421 www-data 20 0 67608 10m 5300 S 1.3 1.8 0:21.19 php5-fpm
28429 www-data 20 0 9524 2260 992 S 1.3 0.4 0:11.68 nginx
28435 www-data 20 0 67608 10m 5304 S 1.3 1.8 0:18.58 php5-fpm
28437 www-data 20 0 67352 10m 5372 S 1.3 1.8 0:17.87 php5-fpm
28441 www-data 20 0 67608 10m 5292 S 1.3 1.8 0:20.75 php5-fpm

Kemudian setelah beberapa waktu yang dapat berada di mana saja antara satu detik dan menit, beberapa (biasanya dua) proses php5-fpm tiba-tiba mengkonsumsi semua CPU:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28436 www-data 20 0 67608 10m 5304 R 48.5 1.8 0:23.68 php5-fpm
28548 www-data 20 0 67608 10m 5276 R 45.2 1.7 0:07.62 php5-fpm
28434 www-data 20 0 67608 10m 5292 R 2.0 1.8 0:23.28 php5-fpm
28439 www-data 20 0 67608 10m 5304 R 2.0 1.8 0:26.63 php5-fpm

Pada titik ini semuanya macet dan semua permintaan HTTP baru habis. Jika saya menghentikan alat http_load, php5-fpm akan bertahan selama beberapa menit. Cukup menarik jika saya melakukan php5-fpm stop, proses php5-fpm akan hilang tetapi setiap perintah yang menggunakan sistem file akan mengalami masalah dalam mengeksekusi. Misalnya. jika saya mencoba mengunduh file melalui ssh, top akan menunjukkan yang berikut ini, membutuhkan beberapa menit untuk memulai unduhan aktual:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3298 sshd 20 0 7032 876 416 R 75.2 0.1 0:04.52 sshd
3297 sshd 20 0 7032 876 416 R 24.9 0.1 0:04.49 sshd

Log kesalahan PHP biasanya memiliki ini:

[05-Dec-2012 20:31:39] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 58 total children
[05-Dec-2012 20:32:08] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 0 idle, and 66 total children

Log kesalahan Nginx dibanjiri dengan entri ini:

2012/12/05 20:31:36 [error] 4800#0: *5559 connect() to unix:/dev/shm/php-fpm-www.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: ..., server: ec2-....compute-1.amazonaws.com, request: "GET /usa/index.php?page=contact_us HTTP/1.0", upstream: "fastcgi://unix:/dev/shm/php-fpm-www.sock:", Host: "ec2-....compute-1.amazonaws.com"

Log lambat PHP-FPM tidak menunjukkan sesuatu yang menarik, bertukar tidak pernah terjadi dan saya tidak berhasil mengumpulkan fakta menarik lainnya tentang masalah tersebut. Saya telah melalui banyak iterasi perubahan file konfigurasi, yang terbaru adalah

nginx.conf: http://Pastebin.com/uaD56hJF

pool.d/www.conf: http://Pastebin.com/mFeeUULC

=== UPDATE 1 ===

konfigurasi situs: http://Pastebin.com/qvinVNhB

=== UPDATE 2 ===

Juga baru menemukan bahwa dmesg melaporkan kesalahan seperti ini

[6483131.164331] php5-fpm[28687]: segfault at b6ec8ff4 ip b78c3c32 sp bff551f0 error 4 in ld-2.13.so[b78b5000+1c000]

=== UPDATE 3 ===

Kami punya contoh mikro Amazon EC2 baru untuk berjaga-jaga, untuk mengecualikan kemungkinan masalah perangkat keras. Saya juga menggunakan php-fastcgi sekarang untuk mengecualikan kemungkinan bug fpm. Perbedaan lainnya kecil, saya pikir satu-satunya yang berubah adalah Ubuntu-> Debian. Masalah yang sama masih terjadi kecuali bahwa sekarang server berhasil sedikit pulih setelah detik max_execution_time (dan kemudian berduri lagi). 

Saya mencoba bermain dengan test.php terpisah dan saya tidak yakin apakah itu masalah yang sama tetapi setidaknya dalam top terlihat sama. Saya membuat test.php dan menyertakan banyak lib yang termasuk dalam kerangka kerja kami. Lib tidak melakukan apa pun kecuali untuk mendefinisikan kelas atau termasuk Lib yang lain yang mendefinisikan kelas. Saya memeriksa dengan APC dan semua ini berhasil dilayani olehnya. Saya mulai menekan test.php dengan 200 permintaan per detik dan setelah beberapa waktu hal yang sama terjadi. Kecuali itu sekarang saya berhasil mendapatkan beberapa kesalahan yang mengatakan "terlalu banyak membuka file". Itu tidak selalu terjadi, kadang-kadang hanya mulai waktu tanpa menghasilkan kesalahan dan beberapa proses php macet mengkonsumsi semua CPU. Saya hanya bermain sedikit dengan itu tapi saya pikir ada korelasi di sini - dengan mengendalikan jumlah lib yang disertakan atau permintaan yang sedikit berbeda/tingkat kedua, saya dapat mengontrol kapan CPU lonjakan akan terjadi. Saya meningkatkan variabel OS yang relevan tetapi masalahnya masih ada meskipun dibutuhkan lebih lama untuk itu terjadi (juga perhatikan bahwa saya telah menetapkan batas nilai N kali lebih besar dari jumlah total permintaan yang saya lakukan selama pengujian).

fs.file-max = 70000
...
*       soft    nofile   10000
*       hard    nofile  30000
...
worker_rlimit_nofile 10000;
...
(reloaded all the configs and made sure the new system vars actually took affect)

Jadi penjelasan terbaik dan satu-satunya berikutnya yang dapat saya buat sejauh ini adalah bahwa meskipun APC seharusnya menarik file dari memori, secara internal itu diterapkan dengan cara yang masih menggunakan deskriptor file kapan saja PHP termasuk- s disebut. Dan baik karena itu melepaskan mereka dengan penundaan atau ketika pada saat yang tidak menguntungkan terlalu banyak permintaan tiba pada saat yang sama, sistem menjalankan deskriptor kami dan permintaan HTTP yang baru tiba dengan cepat ditumpuk menjadi antrian yang besar. Saya akan mencoba untuk menguji ini entah bagaimana.