Mengapa server web saya menjatuhkan koneksi dengan reset TCP pada beban tinggi?


10

Saya memiliki pengaturan VPS kecil dengan nginx. Saya ingin memeras kinerja sebanyak mungkin dari itu, jadi saya telah bereksperimen dengan optimasi dan pengujian beban.

Saya menggunakan Blitz.io untuk melakukan pengujian beban dengan MENDAPAT file teks statis kecil, dan mengalami masalah aneh di mana server tampaknya mengirim ulang TCP setelah jumlah koneksi simultan mencapai sekitar 2000. Saya tahu ini sangat jumlah besar, tetapi dari menggunakan htop server masih memiliki banyak waktu dan memori CPU, jadi saya ingin mencari tahu sumber masalah ini untuk melihat apakah saya dapat mendorongnya lebih jauh.

Saya menjalankan Ubuntu 14.04 LTS (64-bit) pada Linode VPS 2GB.

Saya tidak memiliki reputasi yang cukup untuk memposting grafik ini secara langsung, jadi inilah tautan ke grafik Blitz.io:

masukkan deskripsi gambar di sini

Berikut adalah hal-hal yang telah saya lakukan untuk mencoba dan mencari tahu sumber masalahnya:

  • Nilai konfigurasi nginx worker_rlimit_nofilediatur ke 8192
  • telah nofileditetapkan ke 64000 untuk batas keras dan lunak untuk rootdan www-datapengguna (seperti apa nginx berjalan) di/etc/security/limits.conf
  • tidak ada indikasi ada masalah /var/log/nginx.d/error.log(biasanya, jika Anda menjalankan batas deskriptor file, nginx akan mencetak pesan kesalahan yang mengatakannya)

  • Saya memiliki pengaturan ufw, tetapi tidak ada aturan pembatasan tingkat. Log ufw menunjukkan tidak ada yang diblokir dan saya telah mencoba menonaktifkan ufw dengan hasil yang sama.

  • Tidak ada kesalahan indikatif di /var/log/kern.log
  • Tidak ada kesalahan indikatif di /var/log/syslog
  • Saya telah menambahkan nilai-nilai berikut ke /etc/sysctl.confdan memuatnya sysctl -ptanpa efek:

    net.ipv4.tcp_max_syn_backlog = 1024
    net.core.somaxconn = 1024
    net.core.netdev_max_backlog = 2000
    

Ada ide?

EDIT: Saya melakukan tes baru, ramping hingga 3000 koneksi pada file yang sangat kecil (hanya 3 byte). Inilah grafik Blitz.io:

Grafik Blitz.io

Sekali lagi, menurut Blitz semua kesalahan ini adalah kesalahan "Koneksi ulang TCP".

Berikut grafik bandwidth Linode. Perlu diingat ini adalah rata-rata 5 menit sehingga low pass sedikit difilter (bandwidth sesaat mungkin jauh lebih tinggi), tapi tetap saja, ini bukan apa-apa:

masukkan deskripsi gambar di sini

CPU:

masukkan deskripsi gambar di sini

I / O:

masukkan deskripsi gambar di sini

Inilah htopakhir dari tes: htop

Saya juga menangkap beberapa lalu lintas menggunakan tcpdump pada tes yang berbeda (tetapi serupa), memulai penangkapan ketika kesalahan mulai muncul: sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

Inilah file jika ada yang ingin melihatnya (~ 20MB): https://drive.google.com/file/d/0B1NXWZBKQN6ETmg2SEFOZUsxV28/view?usp=sharing

Berikut grafik bandwidth dari Wireshark:

masukkan deskripsi gambar di sini (Baris adalah semua paket, bilah biru adalah kesalahan TCP)

Dari interpretasi saya tentang penangkapan (dan saya bukan ahli), sepertinya bendera TCP RST berasal dari sumber pengujian beban, bukan dari server. Jadi, dengan asumsi bahwa ada sesuatu yang tidak salah pada sisi layanan pengujian beban, apakah aman untuk menganggap bahwa ini adalah hasil dari semacam manajemen jaringan atau mitigasi DDOS antara layanan pengujian beban dan server saya?

Terima kasih!


Apakah penyedia Anda melakukan semacam mitigasi DDoS? Ini dapat mengganggu tes Anda.
Michael Hampton

@MichaelHampton Saya cukup yakin bahwa Linode tidak melakukan itu.
EEAA

Bisakah Anda memposting grafik jaringan dari panel kontrol Linode? Berapa banyak bandwidth yang benar-benar diambil oleh tes ini?
EEAA

Saya melakukan sedikit penyelidikan lebih lanjut dan memperbarui posting asli dengan lebih banyak info. Saya juga mengkonfirmasi dengan Linode bahwa mereka tidak melakukan mitigasi DDOS, meskipun ini tidak berarti bahwa penyedia jaringan antara layanan pengujian beban dan Linode tidak melakukan apa pun. Terima kasih!
Erik Swan

1
Apakah ada alasan bahwa Anda hanya mengatur net.core.netdev_max_backloghingga 2000? Beberapa contoh yang saya lihat memiliki urutan besarnya lebih tinggi untuk koneksi gigabit (dan 10Gig).
Moshe Katz

Jawaban:


1

Mungkin ada sejumlah sumber pengaturan ulang koneksi. Penguji beban bisa keluar dari porta fana yang tersedia untuk memulai koneksi, perangkat di sepanjang jalan (seperti firewall yang melakukan NAT) mungkin memiliki kolam NAT-nya yang habis dan tidak dapat menyediakan port sumber untuk koneksi, apakah ada penyeimbang beban atau firewall di ujung Anda yang mungkin telah mencapai batas koneksi? Dan jika melakukan sumber NAT pada traffic masuk, itu juga bisa mengalami kelelahan pelabuhan.

Satu akan sangat membutuhkan file pcap dari kedua ujungnya. Yang ingin Anda cari adalah jika upaya koneksi dikirim tetapi tidak pernah mencapai server tetapi masih muncul seolah-olah itu direset oleh server. Jika itu yang terjadi maka sesuatu di sepanjang garis harus mengatur ulang koneksi. Kelelahan kolam NAT adalah sumber umum dari masalah semacam ini.

Juga, netstat -st mungkin memberi Anda beberapa informasi tambahan.


1

Beberapa ide untuk dicoba, berdasarkan pengalaman penyetelan saya yang serupa baru-baru ini. Dengan referensi:

Anda mengatakan itu adalah file teks statis. Untuk berjaga-jaga jika ada proses upstream yang sedang berlangsung, rupanya soket domain meningkatkan throughput TCP melalui koneksi berbasis port TC:

https://rtcamp.com/tutorials/php/fpm-sysctl-tweaking/ https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads

Terlepas dari terminasi hulu:

Aktifkan multi_accept dan tcp_nodelay: http://tweaked.io/guide/nginx/

Nonaktifkan TCP Slow Start: /programming/17015611/disable-tcp-slow-start http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/

Optimalkan TCP Congestion Window (initcwnd): http://www.nateware.com/linux-network-tuning-for-2013.html


1

Untuk mengatur jumlah maksimum file yang terbuka (jika itu menyebabkan masalah Anda), Anda perlu menambahkan "fs.file-max = 64000" ke /etc/sysctl.conf


0

Tolong, lihat berapa banyak port dalam TIME_WAITkeadaan menggunakan perintah netstat -patunl| grep TIME | wc -ldan ubah net.ipv4.tcp_tw_reuseke 1.


Bagaimana saya melihat berapa banyak port di TIME_WAITnegara bagian?
Erik Swan

Menggunakan netstatatau ss. Saya memperbarui jawaban saya dengan perintah lengkap!
fgbreel

Saya telah menjalankan kembali tes dan watch -n 1 'sudo netstat -patunl | grep TIME | wc -l'mengembalikan 0 sepanjang seluruh tes. Saya yakin peri ulang datang sebagai hasil dari mitigasi DDOS oleh seseorang antara load tester dan server saya, berdasarkan analisis saya terhadap file PCAP yang saya posting di atas, tetapi jika seseorang dapat mengonfirmasi bahwa itu akan hebat!
Erik Swan
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.