apache webserver tidak responsif dengan status server menunjukkan semua proses anak menunggu koneksi [ditutup]


10

Pengaturan saya: Saya memiliki 3 mesin server web yang hampir sama yang melayani situs web dinamis dengan muatan tinggi yang sama dengan penyeimbangan muatan sederhana di atas dns. Layanan ini telah bekerja selama lebih dari dua tahun dengan konfigurasi apache yang sama: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Masalah saya: Sejak sekitar dua minggu lalu saya mengalami masalah dengan konfigurasi ini. Hampir setiap hari saya memiliki satu momen kecil selama sekitar 5 menit, di mana situs web tidak dapat dijangkau. Saya masih bisa masuk ke server melalui ssh. Jika saya menjalankan htop, saya melihat mesin tidak melakukan apa-apa. Saya memiliki sekitar 1000 proses apache yang berjalan, tetapi tidak ada aktivitas cpu.

Saya telah menggunakan apache mod_status untuk men-debug situasi ini. Papan skor proses terlihat seperti ini:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Jadi sebagian besar proses hanya menunggu koneksi. setelah sekitar 5 menit situasinya akan kembali normal: saya memiliki banyak proses pada setiap mesin, sebagian besar pekerja memiliki "." - status (meaing mereka terbuka untuk memproses permintaan) dan tentu saja situs web dapat dijangkau!

jadi saya mencoba untuk menemukan sesuatu di log, tetapi tidak ada apa-apa ... log akses apache diam selama sekitar 4 menit, hal yang sama adalah untuk log kesalahan. saya juga tidak dapat menemukan sesuatu yang salah di log sistem lain.

situasinya sama pada ketiga webservers (semuanya memiliki puncak beban dan kondisi tidak responsif pada saat yang sama), jadi saya tidak merasa ini terkait perangkat keras. tetapi saya pikir, ini mungkin terkait dengan beberapa masalah jaringan (tcp).

ada ide?

EDIT: beberapa informasi lebih lanjut, yang baru saja saya temukan:

Itu baru saja terjadi lagi dan saya dapat memverifikasi bahwa saya juga tidak dapat terhubung secara lokal ketika masalah ini terjadi.

Saya telah membuat beberapa statistik koneksi dengan perintah berikut setelah itu terjadi: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 DIDIRIKAN
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 DENGARKAN
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

Jika saya menjalankan perintah yang sama beberapa waktu kemudian, saya memiliki sesuatu seperti ini:

  • 4 PENUTUP
  • 108 DIDIRIKAN
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 DENGARKAN
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Jadi dalam situasi normal saya hanya memiliki 100-200 koneksi terbuka oleh klien yang ditangani oleh apache pada saat ini. Ketika saya mengalami "crash" ini, saya memiliki lebih banyak koneksi. Apa cara terbaik untuk menganalisis ini?

EDIT2: baris penting di apache2.conf adalah:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

Ini adalah prefork apache2 dengan php_mod.

Server memiliki ram 8GB dan partisi swap 4gb.


Apakah situs web menunjukkan gejala yang sama ketika Anda menjalankan wget atau curl dari host lokal atau antara server (jika mereka berada di jaringan yang sama)?
Alex Forbes

Mungkin dump lalu lintas ( tcpdump) akan membantu Anda sampai ke akar masalahnya ... btw apa penggunaan memori Anda dan kebijakan firewall?
drcelus

@ al4 terakhir kali happend ini saya bisa terhubung ke halaman status server dari host lokal, sementara saya tidak dapat terhubung ke halaman web dari luar. Saya tidak yakin, karena bisa juga hal yang acak, sementara beberapa pekerja menjadi tersedia. saya akan menguji ini lagi saat masalah terjadi berikutnya. apa saran Anda, jika saya dapat mengkonfirmasi perbedaan antara koneksi luar dan lokal?
Jeff

Jika Anda dapat mengonfirmasi bahwa itu berfungsi secara lokal tetapi tidak dari luar, hal ini memperkuat kasus untuk jaringan yang menjadi masalah - artinya Anda harus menguji dengan tcpdumps dan wireshark di kedua ujungnya untuk melihat apa yang sedang terjadi, daripada memulai proses apache. Saya juga akan menguji dari host pada LAN yang sama jika memungkinkan. Dan periksa dmesg untuk melihat apakah ada pesan yang bisa dikaitkan tetapi sepertinya Anda sudah melakukannya.
Alex Forbes

itu baru saja terjadi lagi. dan saya dapat memverifikasi bahwa saya juga tidak dapat terhubung secara lokal ketika masalah ini terjadi. saya juga telah membuat beberapa statistik koneksi dengan netstat: lihat teks pertanyaan
Jeff

Jawaban:



1

Pertama: Periksa Max open filesbatas Anda pada proses. Koneksi soket aktif dianggap sebagai file terbuka. cat /proc/###/limitsadalah cara yang baik untuk memeriksa nilai efektif untuk proses lain. Anda bisa mendapatkan daftar file terbuka dengan lsof -p ###tempat ### adalah id proses server web Anda. Anda dapat membandingkan lsof -p ### | wc -luntuk melihat seberapa dekat Anda dengan batas. Anda juga harus melihat pesan di error_log apache jika Anda mencapai batasnya.

Anda memerlukan pegangan file untuk setiap koneksi soket, dan juga untuk setiap skrip cgi atau referensi file data. Untuk 920 MaxClients, Anda harus mengkonfigurasi setidaknya 4.000 file untuk proses httpd. Anda dapat menambah jumlah file dengan menambahkan file di /etc/security/limits.d/ dengan konten berikut. Pastikan nama pengguna cocok dengan apa yang Anda gunakan untuk server web Anda.

apache soft nofile 10000
apache hard nofile 10000

Kedua: Jika kelelahan port adalah masalah Anda, Anda dapat menyesuaikan beberapa pengaturan ip di /etc/sysctl.conf. (Dimulai dengan net.ipv4.tcp_fin_timeout). Ini biasanya masalah hanya dengan banyak koneksi yang sangat kecil. Banyak soket TIME_WAIT adalah salah satu indikatornya, tetapi ini menunjukkan kelelahan port hanya jika disertai dengan kesalahan dalam syslog tentang possible SYN floodingdan Sending cookies. Anda juga harus memastikan server Anda berada di belakang firewall yang dapat menggagalkan serangan SYN berbahaya.


0

Juga, ingatlah bahwa dalam prefork MPM, setiap proses akan memiliki PHP dalam ruang memorinya (apa pengaturan batas memorinya?). Anda mungkin ingin mencoba mengubah ke MPM pekerja, yang mungkin memerlukan modul PHP yang sedikit berbeda.

Juga anting-anting jarak jauh yang berharga untuk memangkas konfigurasi Apache Anda dari modul-modul asing

Dalam pengalaman saya, hal-hal seperti itu dipicu oleh hal-hal seperti crawler mesin pencari, atau hal-hal seperti konflik ARP. Atau tingkat lalu lintas di beberapa bagian terkait jaringan.

Anda mungkin menemukan 'sar' berguna ... bukan yang paling ramah, tetapi tentu berguna.

Mungkin juga terkait. Sar dapat memberi tahu Anda (jika Anda mengonfigurasinya untuk merekam aktivitas disk), berapa rata-rata io waktu tunggu. Anda juga dapat melihat waktu Tunggu IO di atas (yang merupakan persentase, baca apa artinya sebenarnya). Ini bisa signifikan jika Anda menggunakan SAN atau lingkungan virtual.

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.