Perbedaan antara global maxconn dan server maxconn haproxy


91

Saya memiliki pertanyaan tentang konfigurasi haproxy saya:

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log         127.0.0.1 syslog emerg
    maxconn     4000
    quiet
    user        haproxy
    group       haproxy
    daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will 
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode        http
    log         global
    option      abortonclose
    option      dontlognull
    option      httpclose
    option      httplog
    option      forwardfor
    option      redispatch
    timeout connect 10000 # default 10 second time out if a backend is not found
    timeout client 300000 # 5 min timeout for client
    timeout server 300000 # 5 min timeout for server
    stats       enable

listen  http_proxy  localhost:81

    balance     roundrobin
    option      httpchk GET /empty.html
    server      server1 myip:80 maxconn 15 check inter 10000
    server      server2 myip:80 maxconn 15 check inter 10000

Seperti yang Anda lihat, ini sangat mudah, tetapi saya agak bingung tentang cara kerja properti maxconn.

Ada yang global dan maxconn di server, di blok mendengarkan. Pemikiran saya adalah: global satu mengelola jumlah total koneksi yang haproxy, sebagai layanan, akan mengantri atau memproses pada satu waktu. Jika angkanya melebihi itu, itu akan mematikan koneksi, atau mengumpulkan di beberapa soket linux? Saya tidak tahu apa yang terjadi jika angkanya lebih tinggi dari 4000.

Kemudian Anda memiliki properti server maxconn yang disetel pada 15. Pertama, saya menetapkannya pada 15 karena php-fpm saya, ini diteruskan ke server terpisah, hanya memiliki begitu banyak proses anak yang dapat digunakan, jadi saya pastikan saya melakukannya mengumpulkan permintaan di sini, bukan di php-fpm. Yang menurut saya lebih cepat.

Tapi kembali ke pokok bahasan, teori saya tentang nomor ini adalah setiap server di blok ini hanya akan mengirimkan 15 koneksi dalam satu waktu. Dan kemudian koneksi akan menunggu server terbuka. Jika saya mengaktifkan cookie, koneksi akan menunggu server terbuka yang BENAR. Tapi saya tidak.

Jadi pertanyaannya adalah:

  1. Apa yang terjadi jika koneksi global melebihi 4000? Apakah mereka mati? Atau pool di Linux entah bagaimana?
  2. Apakah koneksi global terkait dengan koneksi server, selain fakta Anda tidak dapat memiliki jumlah koneksi server yang lebih besar dari global?
  3. Saat mencari tahu koneksi global, bukankah seharusnya jumlah koneksi ditambahkan di bagian server, ditambah persentase tertentu untuk penggabungan? Dan jelas Anda memiliki batasan lain pada koneksi, tetapi sebenarnya berapa banyak yang ingin Anda kirim ke proxy?

Terima kasih sebelumnya.

Jawaban:


167

Willy memberi saya jawaban melalui email. Saya pikir saya akan membagikannya. Jawabannya dicetak tebal.

Saya memiliki pertanyaan tentang konfigurasi haproxy saya:

   #---------------------------------------------------------------------
   # Global settings
   #---------------------------------------------------------------------
   global
       log         127.0.0.1 syslog emerg
       maxconn     4000
       quiet
       user        haproxy
       group       haproxy
       daemon
   #---------------------------------------------------------------------
   # common defaults that all the 'listen' and 'backend' sections will 
   # use if not designated in their block
   #---------------------------------------------------------------------
   defaults
       mode        http
       log         global
       option      abortonclose
       option      dontlognull
       option      httpclose
       option      httplog
       option      forwardfor
       option      redispatch
       timeout connect 10000 # default 10 second time out if a backend is not found
       timeout client 300000 # 5 min timeout for client
       timeout server 300000 # 5 min timeout for server
       stats       enable

   listen  http_proxy  localhost:81

       balance     roundrobin
       option      httpchk GET /empty.html
       server      server1 myip:80 maxconn 15 check inter 10000
       server      server2 myip:80 maxconn 15 check inter 10000

Seperti yang Anda lihat, ini sangat mudah, tetapi saya agak bingung tentang cara kerja properti maxconn.

Ada yang global dan maxconn di server, di blok mendengarkan.

Dan ada juga satu lagi di blok mendengarkan yang defaultnya seperti 2000.

Pemikiran saya adalah ini: global satu mengelola jumlah total koneksi yang haproxy, sebagai layanan, akan mengantri atau memproses pada satu waktu.

Benar. Ini adalah jumlah maksimum koneksi bersamaan per proses.

Jika angkanya melebihi itu, itu akan mematikan koneksi, atau mengumpulkan di beberapa soket linux?

Nanti, itu hanya berhenti menerima koneksi baru dan mereka tetap dalam antrian soket di kernel. Jumlah soket antrian ditentukan oleh min (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, dan maxconn blok mendengarkan).

Saya tidak tahu apa yang terjadi jika angkanya lebih tinggi dari 4000.

Kelebihan koneksi menunggu koneksi lain selesai sebelum diterima. Namun, selama antrian kernel tidak jenuh, klien bahkan tidak memperhatikan ini, karena koneksi diterima di tingkat TCP tetapi tidak diproses. Jadi klien hanya memperhatikan beberapa penundaan untuk memproses permintaan. Namun dalam praktiknya, maxconn blok pendengar jauh lebih penting, karena secara default lebih kecil dari yang global. Maxconn pendengar membatasi jumlah koneksi per pendengar. Secara umum, bijaksana untuk mengkonfigurasinya untuk jumlah koneksi yang Anda inginkan untuk layanan, dan untuk mengkonfigurasi maxconn global ke jumlah koneksi maksimum yang Anda biarkan proses haproxy menanganinya. Jika Anda hanya memiliki satu layanan, keduanya dapat disetel ke nilai yang sama. Tapi bila Anda memiliki banyak layanan,

Kemudian Anda memiliki properti server maxconn yang disetel pada 15. Pertama, saya menetapkannya pada 15 karena php-fpm saya, ini diteruskan ke server terpisah, hanya memiliki begitu banyak proses anak yang dapat digunakan, jadi saya pastikan saya melakukannya mengumpulkan permintaan di sini, bukan di php-fpm. Yang menurut saya lebih cepat.

Ya, tidak hanya harus lebih cepat, tetapi juga memungkinkan haproxy untuk menemukan server lain yang tersedia kapan pun memungkinkan, dan juga memungkinkannya untuk menghentikan permintaan dalam antrian jika klien menekan "berhenti" sebelum koneksi diteruskan ke server.

Tapi kembali ke pokok bahasan, teori saya tentang nomor ini adalah setiap server di blok ini hanya akan mengirimkan 15 koneksi dalam satu waktu. Dan kemudian koneksi akan menunggu server terbuka. Jika saya mengaktifkan cookie, koneksi akan menunggu server terbuka yang BENAR. Tapi saya tidak.

Itulah prinsipnya. Ada antrian per-proxy dan antrian per-server. Koneksi dengan cookie persistensi pergi ke antrian server dan koneksi lainnya pergi ke antrian proxy. Namun karena dalam kasus Anda tidak ada cookie yang dikonfigurasi, semua koneksi masuk ke antrian proxy. Anda dapat melihat diagram doc / antrian.fig di sumber haproxy jika Anda mau, ini menjelaskan bagaimana / di mana keputusan diambil.

Jadi pertanyaannya adalah:

  1. Apa yang terjadi jika koneksi global melebihi 4000? Apakah mereka mati? Atau pool di Linux entah bagaimana?

    Mereka mengantri di linux. Setelah Anda membanjiri antrean kernel, antrean tersebut akan ditempatkan di kernel.

  2. Apakah koneksi global terkait dengan koneksi server, selain fakta bahwa Anda tidak dapat memiliki jumlah koneksi server yang lebih besar dari global?

    Tidak, pengaturan koneksi global dan server independen.

  3. Saat mencari tahu koneksi global, bukankah seharusnya jumlah koneksi ditambahkan di bagian server, ditambah persentase tertentu untuk penggabungan? Dan jelas Anda memiliki batasan lain pada koneksi, tetapi sebenarnya berapa banyak yang ingin Anda kirim ke proxy?

    Anda benar. Jika waktu respons server Anda pendek, tidak ada salahnya mengantri ribuan koneksi untuk melayani hanya beberapa dalam satu waktu, karena hal itu secara substansial mengurangi waktu pemrosesan permintaan. Praktis, membuat koneksi saat ini membutuhkan waktu sekitar 5 mikrodetik pada LAN gigabit. Jadi sangat masuk akal untuk membiarkan haproxy mendistribusikan koneksi secepat mungkin dari antriannya ke server dengan maxconn yang sangat kecil. Saya ingat satu situs game mengantri lebih dari 30000 koneksi bersamaan dan berjalan dengan antrian 30 per server! Itu adalah server apache, dan apache jauh lebih cepat dengan jumlah koneksi yang kecil dibandingkan dengan jumlah yang besar. Tetapi untuk ini Anda benar-benar membutuhkan server yang cepat, karena Anda tidak t ingin semua klien Anda mengantri menunggu slot koneksi karena server sedang menunggu database misalnya. Juga sesuatu yang bekerja sangat baik adalah mendedikasikan server. Jika situs Anda memiliki banyak statika, Anda dapat mengarahkan permintaan statis ke kumpulan server (atau cache) sehingga Anda tidak memasukkan permintaan statis ke antrean dan permintaan statis tersebut tidak memakan slot koneksi yang mahal. Berharap ini bisa membantu, Willy


10
Terima kasih telah memposting ini.
Tarantula

9
Saya memiliki satu haproxy yang mewakili sekitar 200 backend lainnya. Setelah backend di-DDOS dengan sekitar ~ 300k conneitons / detik, semua backend lainnya mati. Dengan nilai maxconn 2048 di server backend (di bawah ddos), haproxy kami berjalan dengan baik. Terima kasih banyak, Anda menyelamatkan saya suatu malam :)
hungnv
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.