Pernis kehabisan port terbuka, banyak koneksi SYN_SENT

Baru-baru ini kami mengalami masalah dengan pengaturan Varnish (3x) -> Apache (3x) kami, yang mengakibatkan lonjakan besar dalam SYN_SENTkoneksi.

Lonjakan itu sendiri disebabkan oleh jumlah lalu lintas baru yang mengenai situs (bukan DDOS dalam bentuk apa pun), dan sepertinya mesin Varnish kami mengalami masalah meneruskan lalu lintas ke server backend (penurunan lalu lintas Apache berkorelasi dengan lonjakan pada pernis ), menumpuk kolam port yang tersedia dengan SYN_SENT.

Keep-alive diaktifkan di Apache (15s).

Sisi mana yang salah? Jumlah trafik sangat signifikan, tetapi dalam jumlah berapa pun ia tidak akan menyebabkan pengaturan seperti itu (mesin frontend 3x Varnish, server Apache 3x backend) terhenti.

Tolong bantu.

Tangkapan layar Munin untuk koneksi melalui firewall ada di sini .

Pernis ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf (Varnish)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

Apache netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (Apache)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

Masalah Anda mungkin dengan sysctl di server Apache.

Beberapa asumsi: Biasanya Varnish jauh lebih cepat dalam memproses setiap koneksi daripada server web (kecuali mungkin server Varnish Anda memiliki lebih sedikit CPU, dan server Apache Anda hanya menyajikan file statis yang di-cache dalam memori.) Saya akan menganggap proses koneksi Anda lebih cepat dalam Varnish dari Apache.

Oleh karena itu, sumber daya di server Apache Anda mungkin cukup, tetapi permintaan harus mengantri di suatu tempat, jika hanya sebentar. Saat ini mereka tidak mengantri dengan cara yang sehat di mana mereka akhirnya diproses.

Sepertinya permintaan Anda macet di Varnish dan tidak berhasil masuk ke server Apache.

Ada beberapa bukti untuk ini:

Perhatikan dalam grafik munin Anda, sebelum SYN_SENT didukung, permintaan dalam TIME_WAIT meningkat, kemudian setelah satu titik, mereka mulai menumpuk sebagai SYN_SENTS. Ini menunjukkan bahwa permintaan mulai dijawab lebih lambat, kemudian antrian kembali dan permintaan tidak dijawab sama sekali.

Ini menunjukkan kepada saya bahwa server Apache Anda tidak menerima koneksi yang cukup (di mana mereka kemudian dapat duduk dan mengantri untuk Apache untuk memprosesnya.)

Saya melihat beberapa batasan yang mungkin dalam file konfigurasi Anda:

Ketika Anda memiliki spike, Anda memiliki sekitar 30000 koneksi dalam status SYN_SENT di server Varnish Anda.

Namun, pada server Apache, max_syn_backlog Anda hanya 16384. Somaxconn Anda hanya 2048.

Perhatikan juga ukuran buffer memori jaringan Anda di server Apache sangat rendah. Anda telah menyesuaikannya di server Varnish hingga 16MB. Tetapi pada server Apache net.ipv4.tcp_rmem Anda hanya 524KB untuk mencocokkan net.core.rmem_max Anda.

Saya sarankan menaikkan semua parameter ini di server Apache.

Anda harus lebih fokus pada diagnostik di server Apache untuk mencari tahu apa yang sebenarnya terjadi, tetapi Anda mungkin tidak perlu melakukannya jika Anda meningkatkan nilai-nilai ini.

Anda mungkin tidak harus menyesuaikan net.ipv4.tcp_mem. Perhatikan bahwa unit untuk parameter ini ada di halaman, bukan byte, sehingga menyalin nilai yang sama dari net.ipv4.tcp_rmem atau net.ipv4.tcp_wmem (keduanya dalam byte) tidak masuk akal. Ini disetel otomatis oleh linux berdasarkan jumlah memori Anda sehingga jarang perlu penyesuaian. Sebenarnya ini mungkin masalah Anda, secara sewenang-wenang membatasi memori yang tersedia untuk antrian koneksi keseluruhan.

Lihat: http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

Perhatikan juga "vm.swappiness = 0" Anda diset dua kali, sekali sebagai 10, dan sekali lagi di bagian bawah sebagai 0, yang merupakan nilai efektif.

Di server Varnish, coba ubah 2 parameter ini:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuse akan memungkinkannya untuk menggunakan kembali koneksi di TIME_WAIT.

tw_recycle dapat menyebabkan masalah dengan load balancers dll.