Meningkatkan kinerja TCP melalui jaringan gigabit dengan banyak koneksi dan lalu lintas tinggi dari paket kecil

37

Saya mencoba untuk meningkatkan throughput TCP saya melalui "jaringan gigabit dengan banyak koneksi dan lalu lintas tinggi dari paket kecil". OS server saya adalah Ubuntu 11.10 Server 64bit.

Ada sekitar 50.000 (dan terus bertambah) klien yang terhubung ke server saya melalui Soket TCP (semua pada port yang sama).

95% dari paket saya memiliki ukuran 1-150 byte (header TCP dan payload). Sisanya 5% bervariasi dari 150 hingga 4096+ byte.

Dengan konfigurasi di bawah server saya dapat menangani lalu lintas hingga 30 Mbps (dupleks penuh).

Bisakah Anda memberi saran praktik terbaik untuk menyempurnakan OS untuk kebutuhan saya?

/etc/sysctl.congPenampilan saya seperti ini:

kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576   64768   98152
#
net.core.wmem_default = 65536
net.core.rmem_default = 65536
net.ipv4.tcp_window_scaling=1
#
net.ipv4.tcp_mem= 98304 131072 196608
#
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
#
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192

Inilah batasan saya:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 193045
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1000000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1000000

[TAMBAH]

NIC saya adalah sebagai berikut:

$ dmesg | grep Broad
[    2.473081] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.62.12-0 (2011/03/20)
[    2.477808] bnx2x 0000:02:00.0: eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 28, node addr d8:d3:85:bd:23:08
[    2.482556] bnx2x 0000:02:00.1: eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 40, node addr d8:d3:85:bd:23:0c

[TAMBAH 2]

ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

[TAMBAH 3]

 sudo ethtool -S eth0|grep -vw 0
 NIC statistics:
      [1]: rx_bytes: 17521104292
      [1]: rx_ucast_packets: 118326392
      [1]: tx_bytes: 35351475694
      [1]: tx_ucast_packets: 191723897
      [2]: rx_bytes: 16569945203
      [2]: rx_ucast_packets: 114055437
      [2]: tx_bytes: 36748975961
      [2]: tx_ucast_packets: 194800859
      [3]: rx_bytes: 16222309010
      [3]: rx_ucast_packets: 109397802
      [3]: tx_bytes: 36034786682
      [3]: tx_ucast_packets: 198238209
      [4]: rx_bytes: 14884911384
      [4]: rx_ucast_packets: 104081414
      [4]: rx_discards: 5828
      [4]: rx_csum_offload_errors: 1
      [4]: tx_bytes: 35663361789
      [4]: tx_ucast_packets: 194024824
      [5]: rx_bytes: 16465075461
      [5]: rx_ucast_packets: 110637200
      [5]: tx_bytes: 43720432434
      [5]: tx_ucast_packets: 202041894
      [6]: rx_bytes: 16788706505
      [6]: rx_ucast_packets: 113123182
      [6]: tx_bytes: 38443961940
      [6]: tx_ucast_packets: 202415075
      [7]: rx_bytes: 16287423304
      [7]: rx_ucast_packets: 110369475
      [7]: rx_csum_offload_errors: 1
      [7]: tx_bytes: 35104168638
      [7]: tx_ucast_packets: 184905201
      [8]: rx_bytes: 12689721791
      [8]: rx_ucast_packets: 87616037
      [8]: rx_discards: 2638
      [8]: tx_bytes: 36133395431
      [8]: tx_ucast_packets: 196547264
      [9]: rx_bytes: 15007548011
      [9]: rx_ucast_packets: 98183525
      [9]: rx_csum_offload_errors: 1
      [9]: tx_bytes: 34871314517
      [9]: tx_ucast_packets: 188532637
      [9]: tx_mcast_packets: 12
      [10]: rx_bytes: 12112044826
      [10]: rx_ucast_packets: 84335465
      [10]: rx_discards: 2494
      [10]: tx_bytes: 36562151913
      [10]: tx_ucast_packets: 195658548
      [11]: rx_bytes: 12873153712
      [11]: rx_ucast_packets: 89305791
      [11]: rx_discards: 2990
      [11]: tx_bytes: 36348541675
      [11]: tx_ucast_packets: 194155226
      [12]: rx_bytes: 12768100958
      [12]: rx_ucast_packets: 89350917
      [12]: rx_discards: 2667
      [12]: tx_bytes: 35730240389
      [12]: tx_ucast_packets: 192254480
      [13]: rx_bytes: 14533227468
      [13]: rx_ucast_packets: 98139795
      [13]: tx_bytes: 35954232494
      [13]: tx_ucast_packets: 194573612
      [13]: tx_bcast_packets: 2
      [14]: rx_bytes: 13258647069
      [14]: rx_ucast_packets: 92856762
      [14]: rx_discards: 3509
      [14]: rx_csum_offload_errors: 1
      [14]: tx_bytes: 35663586641
      [14]: tx_ucast_packets: 189661305
      rx_bytes: 226125043936
      rx_ucast_packets: 1536428109
      rx_bcast_packets: 351
      rx_discards: 20126
      rx_filtered_packets: 8694
      rx_csum_offload_errors: 11
      tx_bytes: 548442367057
      tx_ucast_packets: 2915571846
      tx_mcast_packets: 12
      tx_bcast_packets: 2
      tx_64_byte_packets: 35417154
      tx_65_to_127_byte_packets: 2006984660
      tx_128_to_255_byte_packets: 373733514
      tx_256_to_511_byte_packets: 378121090
      tx_512_to_1023_byte_packets: 77643490
      tx_1024_to_1522_byte_packets: 43669214
      tx_pause_frames: 228

Beberapa info tentang SACK: Kapan mematikan TCP SACK?

Pekerja
sumber
1
Ini dapat membantu: datatag.web.cern.ch/datatag/howto/tcp.html
yrk
Apa faktor pembatasnya? Apakah CPU Anda maksimal? Jika demikian, Anda menggonggong pohon yang salah. Anda perlu melihat apa yang dilakukan CPU.
David Schwartz
NIC apa yang kamu punya?
SaveTheRbtz
1
BTW: Mengapa Anda mematikan SACK?
Nils
1
Anda harus mempertimbangkan kembali menggunakan Broadcom NICs ...
Hubert Kario

Jawaban:

21

Masalahnya mungkin karena Anda mendapatkan terlalu banyak interupsi pada kartu jaringan Anda. Jika Bandwidth bukan masalahnya, frekuensi adalah masalahnya:

  • Munculkan buffer kirim / terima pada kartu jaringan

    ethtool -g eth0
    

Akan menunjukkan kepada Anda pengaturan saat ini (256 atau 512 entri). Anda mungkin dapat meningkatkan ini ke 1024, 2048 atau 3172. Lebih mungkin tidak masuk akal. Ini hanya buffer cincin yang hanya terisi jika server tidak dapat memproses paket yang masuk dengan cukup cepat.

Jika buffer mulai terisi, flow control adalah cara tambahan untuk memberi tahu router atau beralih untuk memperlambat:

  • Nyalakan kontrol aliran masuk / keluar pada server dan sakelar / router-port yang dilampirkan.

    ethtool -a eth0
    

Mungkin akan menunjukkan:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

Periksa / var / log / pesan untuk pengaturan eth0 saat ini. Periksa sesuatu seperti:

eth0: Tautan di atas 1000 Mbps, dupleks penuh, kontrol aliran tx dan rx

Jika Anda tidak melihat tx dan rx admin jaringan Anda harus menyesuaikan nilai pada switch / router. Pada Cisco yang menerima / mentransmisikan kontrol aliran aktif.

Hati-hati: Mengubah Nilai-nilai ini akan membuat tautan Anda naik turun untuk waktu yang sangat singkat (kurang dari 1).

  • Jika semua ini tidak membantu - Anda juga dapat menurunkan kecepatan kartu jaringan menjadi 100 MBit (lakukan hal yang sama pada switch / router-port)

    ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
    

Tetapi dalam kasus Anda, saya akan mengatakan - naikkan buffer penerima di buffer cincin NIC.

Nils
sumber
Melihat nomor Anda dari ethtoolsaya akan mengatakan - mengatur buffer menerima kartu jaringan ke maksimum untuk menghindari buangan RX. Saya harap Broadcom Anda memiliki cukup ini.
Nils
1
Meningkatkan buffering dengan TCP hampir tidak pernah merupakan ide yang baik. Kami sudah memiliki terlalu banyak buffering: bufferbloat.net/projects/bloat/wiki/Introduction
rmalayter
3
Buffer ini adalah buffer perangkat keras langsung di NIC. Saya akan memperbarui jawaban saya dengan lebih detail. Karena Anda kehilangan paket yang masuk, Anda memerlukan buffer itu. Saya memiliki server serupa di mana saya harus beralih ke NIC yang berbeda (dari Broadcom onboard ke PCIe Intel) untuk dapat meningkatkan buffer ini. Setelah itu saya tidak pernah menemukan paket RX yang hilang lagi.
Nils
@malayter: ini adalah ring-buffer pada layer 2. Lihat jawaban saya yang diperbarui.
Nils
1
Akhirnya kami memiliki 1GB. Ada banyak penyetelan di tempat yang berbeda, jadi tidak bisa mengatakan bahwa ada satu masalah.
Pekerja
5

Mengikuti mungkin bukan jawaban yang pasti tetapi pasti akan mengemukakan beberapa ide

Coba tambahkan ini ke sysctl.conf

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

Sementara selektif tcp ack bagus untuk kinerja optimal dalam kasus jaringan bandwidth tinggi. Namun waspadalah terhadap kekurangan lainnya . Manfaat penskalaan jendela dijelaskan di sini . Adapun opsi sysctl ketiga: Secara default, TCP menyimpan berbagai metrik koneksi dalam cache rute ketika koneksi ditutup, sehingga koneksi yang dibuat dalam waktu dekat dapat menggunakannya untuk mengatur kondisi awal. Biasanya, ini meningkatkan kinerja secara keseluruhan, tetapi kadang-kadang dapat menyebabkan penurunan kinerja. Jika diatur, TCP tidak akan melakukan cache metrik pada koneksi penutupan.

Periksa dengan

ethtool -k ethX

untuk melihat apakah pembongkaran diaktifkan atau tidak. TCP checksum offload dan offload segmen besar didukung oleh mayoritas NIC Ethernet saat ini dan Broadcom juga mendukungnya.

Coba gunakan alat

powertop

saat jaringan menganggur dan saat saturasi jaringan tercapai. Ini pasti akan menunjukkan jika NIC menginterupsi pelakunya. Polling perangkat adalah jawaban untuk situasi seperti itu. FreeBsd mendukung polling switch di dalam ifconfig tetapi linux tidak memiliki opsi seperti itu. Konsultasikan ini untuk mengaktifkan polling. Dikatakan BroadCom juga mendukung polling yang merupakan kabar baik bagi Anda.

Tweak paket Jumbo mungkin tidak memotongnya untuk Anda karena Anda menyebutkan traffic Anda sebagian besar berupa paket kecil. Tapi hei coba saja!

kaji
sumber
2kaji, saya akan mencoba saran Anda besok. Tentang PowerTop - haruskah saya menyetel penghematan daya jika tujuan saya adalah kinerja?
Pekerja
Ya tentu saja itu mungkin juga membantu. Saya menyebutkan powertop hanya untuk memastikan apakah interupsi adalah kejahatan. Frekuensi interupsi juga dapat dipanen dari alat lain
kaji
Saya melihat "Rescheduling Interrupts" yang tinggi - bisakah itu menjadi alasan? Apa itu "Menjadwal Ulang Interupsi"?
Pekerja
yeah .. Saya melihat tutorial itu, tetapi untuk laptop sementara saya melihat interupsi tinggi di server. Akan mencoba menerapkannya ke server.
Pekerja
2

Anda perlu mendistribusikan beban di semua inti CPU. Mulai 'irqbalance'.

pengguna175978
sumber
1
Ini tidak akan membantu jika satu IRQ memiliki freuency yang sangat tinggi. IRQBalance mencoba mendistribusikan IRQ tunggal ke prosesor logis yang sesuai - tetapi tidak akan pernah ada lebih dari satu prosesor yang melayani IRQ tunggal.
Nils
2

Saya perhatikan dalam daftar tweak bahwa cap waktu dimatikan, tolong jangan lakukan itu. Itu adalah kemunduran lama ke hari dahulu kala ketika bandwidth benar-benar mahal dan orang-orang ingin menyimpan beberapa byte / paket. Ini digunakan, misalnya, oleh tumpukan TCP hari ini untuk mengetahui apakah paket yang datang untuk soket di "CLOSE_WAIT" adalah paket lama untuk koneksi atau jika itu adalah paket baru untuk koneksi baru dan membantu dalam perhitungan RTT. Dan menyimpan beberapa byte untuk cap waktu TIDAK ADA dibandingkan dengan apa yang akan ditambahkan alamat IPv6. Mematikan stempel waktu lebih berbahaya daripada kebaikan.

Rekomendasi ini untuk mematikan stempel waktu hanyalah sebuah kemunduran yang terus diturunkan dari satu generasi sysadmin ke generasi berikutnya. Semacam semacam "legenda urban".

GeorgeB
sumber
2

Saya mengusulkan ini:

kernel.sem = 350 358400 64 1024
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rmem = 4096 262144 4194304
net.ipv4.tcp_wmem = 4096 262144 4194304
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_keepalive_intvl = 900
net.ipv4.tcp_keepalive_probes = 9

Diuji di server Oracle DB pada RHEL dan dalam perangkat lunak cadangan.

Konrad Puchała
sumber
5
Angka-angka ini dapat dikonfigurasi karena tidak ada satu ukuran untuk semua. Itu berarti angkanya sendiri tidak berharga. Apa yang bisa berharga adalah metode yang Anda gunakan untuk memutuskan angka yang akan digunakan.
kasperd
2

Dalam kasus saya hanya satu tuninng:

net.ipv4.tcp_timestamps = 0

membuat perubahan yang sangat besar dan bermanfaat, waktu pemuatan situs berkurang 50%.

avz2012
sumber
Sesuatu harus rusak parah di pengaturan Anda agar itu terjadi. Stempel waktu menggunakan kurang dari 1% dari bandwidth dalam keadaan normal dan akan memungkinkan TCP untuk melakukan transmisi ulang dengan waktu yang lebih ketat daripada yang sebaliknya.
kasperd