Apache mencapai MaxClients dan mengunci server


9

Saat ini saya memiliki server Apache2 yang berjalan dengan mpm-preforkdan mod_phppada VPS OpenVZ dengan 512M real / 1024M burstable RAM (tanpa swap). Setelah menjalankan beberapa tes, saya menemukan bahwa ukuran proses maksimum yang didapat Apache adalah 23M, jadi saya telah menetapkan MaxClientske 25 (23M x 25 = 575 MB, ok untuk saya). Saya memutuskan untuk menjalankan beberapa tes beban di server saya, dan hasilnya membuat saya bingung.

Saya menggunakan abdi mesin desktop saya meminta halaman utama dari blog wordpress.

Ketika saya menjalankan abdengan 24 koneksi bersamaan, semuanya tampak baik-baik saja. Tentu, CPU naik, RAM bebas turun, dan hasilnya sekitar 2-3s waktu respons per permintaan.

Tetapi jika saya menjalankan abdengan 25 koneksi bersamaan (batas server saya), Apache hanya hang setelah beberapa detik. Itu mulai memproses permintaan, kemudian berhenti merespons, CPU kembali ke idle 100% dan abwaktu habis. Log Apache mengatakan sudah tercapai MaxClients.

Ketika ini terjadi, Apache tetap terkunci dengan 25 proses yang berjalan (mereka semua dalam "W" jika saya memeriksa status server) dan hanya setelah TimeOutpengaturan proses mulai mati dan server mulai merespons lagi (dalam kasus saya sudah diatur ke 45).

Pertanyaan saya: apakah itu perilaku yang diharapkan? Mengapa Apache mati begitu saja MaxClients? Jika bekerja dengan 24 koneksi, bukankah seharusnya bekerja dengan 25, hanya mungkin mengambil lebih banyak waktu untuk menanggapi setiap permintaan dan mengantri sisanya?

Kedengarannya agak aneh bagi saya bahwa setiap anak yang berjalan absendiri dapat membunuh server web hanya dengan mengatur koneksi bersamaan ke server MaxClients.

Jawaban:


17

HA! Saya akhirnya menemukan masalah sendiri. Ini lebih terkait dengan pemrograman daripada admin server, tetapi saya memutuskan untuk meletakkan jawabannya di sini karena dengan mencari google saya menemukan saya bukan satu-satunya dengan masalah seperti itu (dan karena Apache hang, tebakan pertama adalah bahwa ada masalah dengan server).

Masalahnya bukan dengan Apache, tetapi dengan Wordpress saya. Lebih khusus dengan tema saya. Saya menggunakan tema yang disebut Lightworld dan mendukung menambahkan gambar ke header blog. Untuk memungkinkannya, ia memeriksa ukuran gambar dengan menggunakan fungsi PHP getimagesize(). Karena fungsi ini membuka koneksi http lain ke server untuk mendapatkan gambar, setiap permintaan dari abmembuat permintaan lain secara internal dari PHP. Karena saya menggunakan semua slot server saya yang tersedia, permintaan PHP ini dimasukkan ke dalam antrian, tetapi Apache tidak akan pernah bisa mendapatkannya karena semua prosesnya dikunci dengan permintaan asli menunggu slot untuk menyelesaikan permintaan internal PHP.

Pada dasarnya, PHP membuat server saya dalam kondisi deadlock, dan Apache hanya akan mulai bekerja secara normal setelah koneksi ini habis menunggu permintaan "anak" mereka.

Setelah saya menghapus fungsi ini dari tema saya, sekarang saya dapat abserver saya dengan koneksi bersamaan sebanyak yang saya inginkan, dan Apache mengantri mereka seperti yang diharapkan.


Terima kasih telah memposting ini di sini, saya telah mencoba mencari masalah dengan gejala yang persis sama selama beberapa hari ini - saya pikir kita juga memiliki kebuntuan!
James Yale

bagaimana Anda menentukan ini, saya terutama tertarik pada log dan alat yang Anda gunakan untuk menentukan permintaan keluar sekunder.
Anirudh Goel

2

Apa yang terjadi di sini adalah bahwa Anda memiliki 25 utas yang dapat menerima koneksi, dan Anda mengirim 26 permintaan bersamaan. Permintaan terakhir itu berada di antrian soket tergantung pada ukuran simpanan Anda.

Masalah kedua adalah apa pun yang Anda jalankan yang memakan waktu 2-3 detik, perlu waktu cukup lama untuk merespons bahwa 25 koneksi bersamaan memperlambatnya. sleep (1) mungkin bekerja, tetapi, sesuatu di mana Anda melakukan penguncian file atau penguncian tabel dari mysql, setiap permintaan paralel mungkin menunggu sebelum selesai sampai mereka mencapai batas waktu 45 detik.

23MB terdengar kecil untuk proses apache dengan mod_php dan modul apa pun dimuat, jadi, saya curiga Anda mungkin melihat proses apache mengambil ram sedikit lebih saat aplikasi Anda berjalan. Anda tidak dapat benar-benar melakukan matematika dengan MaxClients dan memori seperti itu ... itu akan menjadi agak dekat, tetapi, Anda tidak pernah tahu.

www-data  1495  0.1  0.9  56288 19996 ?        S    15:48   0:01 /usr/sbin/apache2 -k start
www-data  1500  0.0  0.5  49684 12436 ?        D    15:48   0:00 /usr/sbin/apache2 -k start

Ada satu mesin, proses 56M dan 49M.

mesin lain:

www-data  7767  0.1  0.1 213732 14840 ?        S    14:55   0:08 /usr/sbin/apache2 -k start
www-data  8020  0.2  0.1 212424 13660 ?        S    14:57   0:08 /usr/sbin/apache2 -k start

mesin lain:

www-data 28509  0.8  0.1 161720 10068 ?        S    14:39   0:43 /usr/sbin/apache2 -k start
www-data 28511  0.8  0.1 161932 10344 ?        S    14:39   0:43 /usr/sbin/apache2 -k start

Jadi, penggunaan memori sangat tergantung pada tugas, modul mana yang dimuat dll. Pada dua terakhir, saya yakin kami telah menonaktifkan pdo & pdo_mysql karena aplikasi itu tidak menggunakannya.

Pertanyaan sebenarnya adalah, apa yang Anda lakukan yang memakan waktu 3 detik? Di dunia saat ini, itu adalah keabadian dan dianggap sebagai aplikasi 'pemblokiran'. Apache biasanya tidak akan mati, tetapi, akan meninggalkan utas-utas itu dalam antrian backlog sampai dapat melayani mereka atau permintaan tunggu menunggu waktu habis. Saya percaya aplikasi Anda mungkin menyebabkan apache untuk time out. Cobalah di halaman yang berisi hanya phpinfo (); dan lihat apakah hasilnya sama.


Terima kasih untuk semua tipsnya! Saya sadar saya masih perlu mengoptimalkan banyak hal (saya baru mulai mengkonfigurasi server beberapa hari yang lalu dan ini pengalaman pertama saya dengan VPS), tetapi masalahnya lebih dalam dari itu ... Saya mengirim jawaban ke pertanyaan yang menjelaskan apa masalahnya dalam kasus spesifik saya.
Rodrigo Sieiro
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.