การปรับปรุงประสิทธิภาพ TCP บนเครือข่ายกิกะบิตที่มีการเชื่อมต่อจำนวนมากและปริมาณการใช้งานสูงของแพ็กเก็ตขนาดเล็ก


37

ฉันกำลังพยายามปรับปรุงปริมาณงาน TCP ผ่าน "เครือข่ายกิกะบิตที่มีการเชื่อมต่อจำนวนมากและปริมาณการใช้งานสูงของแพ็กเก็ตขนาดเล็ก" ระบบปฏิบัติการเซิร์ฟเวอร์ของฉันคือ Ubuntu 11.10 Server 64 บิต

มีลูกค้าประมาณ 50,000 ราย (และเติบโต) ที่เชื่อมต่อกับเซิร์ฟเวอร์ของฉันผ่าน TCP Sockets (ทั้งหมดบนพอร์ตเดียวกัน)

95% ของแพ็คเก็ตของฉันมีขนาด 1-150 ไบต์ (ส่วนหัว TCP และส่วนของข้อมูล) ส่วนที่เหลือ 5% แตกต่างจาก 150 ถึง 4096+ ไบต์

ด้วยการกำหนดค่าด้านล่างเซิร์ฟเวอร์ของฉันสามารถรองรับปริมาณข้อมูลสูงถึง 30 Mbps (ดูเพล็กซ์เต็มรูปแบบ)

คุณช่วยแนะนำวิธีปฏิบัติที่ดีที่สุดในการปรับแต่งระบบปฏิบัติการตามความต้องการของฉันได้หรือไม่?

/etc/sysctl.congหน้าตาของฉันเป็นแบบนี้:

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

นี่คือข้อ จำกัด ของฉัน:

$ 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

[เพิ่ม]

นิคส์ของฉันมีดังต่อไปนี้:

$ 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

[เพิ่ม 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

[เพิ่ม 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

ข้อมูลบางอย่างเกี่ยวกับ SACK: เมื่อใดที่จะปิด TCP SACK


1
สิ่งนี้อาจช่วยได้: datatag.web.cern.ch/datatag/howto/tcp.html
yrk

ปัจจัย จำกัด คืออะไร CPU ของคุณมีค่าสูงสุดหรือไม่? ถ้าเป็นเช่นนั้นคุณกำลังเห่าต้นไม้ผิด คุณต้องดูว่า CPU กำลังทำอะไรอยู่
David Schwartz

คุณมี NIC อะไร
SaveTheRbtz

1
BTW: ทำไมคุณถึงปิด SACK
นิลส์

1
คุณควรพิจารณาใหม่โดยใช้ Broadcom NICs ...
Hubert Kario

คำตอบ:


21

ปัญหาอาจเป็นได้ว่าคุณได้รับการขัดจังหวะมากเกินไปในการ์ดเครือข่ายของคุณ หาก Bandwidth ไม่ใช่ปัญหาความถี่จะเป็นปัญหา:

  • เปิดบัฟเฟอร์การส่ง / รับบนการ์ดเครือข่าย

    ethtool -g eth0
    

จะแสดงการตั้งค่าปัจจุบัน (256 หรือ 512 รายการ) คุณอาจยกระดับเหล่านี้เป็น 1024, 2048 หรือ 3172 เพิ่มเติมอาจไม่สมเหตุสมผล นี่เป็นเพียงบัฟเฟอร์วงแหวนที่จะเติมให้เต็มหากเซิร์ฟเวอร์ไม่สามารถประมวลผลแพ็กเก็ตที่เข้ามาได้เร็วพอ

หากบัฟเฟอร์เริ่มเติมการควบคุมการไหลคือวิธีการเพิ่มเติมเพื่อแจ้งให้เราเตอร์หรือสวิตช์ช้าลง:

  • เปิดโฟลว์คอนโทรลใน / ขาออกบนเซิร์ฟเวอร์และสวิตช์ / เราเตอร์พอร์ตที่ต่ออยู่

    ethtool -a eth0
    

อาจจะแสดง:

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

ตรวจสอบ / var / log / messages สำหรับการตั้งค่าปัจจุบันของ eth0 ตรวจสอบสิ่งที่ชอบ:

eth0: การเชื่อมโยงขึ้นที่ 1000 Mbps, full duplex, flow control tx และ rx

หากคุณไม่เห็น tx และ rx ผู้ดูแลระบบเครือข่ายของคุณต้องปรับค่าบนสวิตช์ / เราเตอร์ บน Cisco ที่รับ / ส่งโฟลว์คอนโทรลบน

ระวัง:การเปลี่ยนค่าเหล่านี้จะทำให้ลิงค์ของคุณขึ้นและลงในเวลาอันสั้น (น้อยกว่า 1 วินาที)

  • หากสิ่งนี้ไม่ได้ช่วย - คุณสามารถลดความเร็วของการ์ดเครือข่ายเป็น 100 MBit (ทำเช่นเดียวกันกับสวิตช์ / เราเตอร์พอร์ต)

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

แต่ในกรณีของคุณฉันจะบอกว่า - เพิ่มบัฟเฟอร์รับในบัฟเฟอร์วงแหวน NIC


ดูที่ตัวเลขของคุณจากที่ethtoolฉันจะบอก - ตั้งค่าบัฟเฟอร์การรับของการ์ดเครือข่ายเป็นสูงสุดเพื่อหลีกเลี่ยงการละทิ้ง RX ฉันหวังว่า Broadcom ของคุณมีสิ่งเหล่านี้เพียงพอ
นิลส์

1
การเพิ่มบัฟเฟอร์ด้วย TCP แทบจะไม่เป็นความคิดที่ดีเลย เรามีวิธีการบัฟเฟอร์มากเกินไปแล้ว: bufferbloat.net/projects/bloat/wiki/Introduction
rmalayter

3
บัฟเฟอร์นี้เป็นบัฟเฟอร์ฮาร์ดแวร์โดยตรงบน NIC ฉันจะอัปเดตคำตอบของฉันพร้อมรายละเอียดเพิ่มเติม เนื่องจากคุณกำลังปล่อยแพ็กเก็ตขาเข้าคุณต้องใช้บัฟเฟอร์นั้น ฉันมีเซิร์ฟเวอร์ที่คล้ายกันซึ่งฉันต้องเปลี่ยนเป็น NIC อื่น (จาก onboard Broadcom เป็น PCIe Intel) เพื่อให้สามารถเพิ่มบัฟเฟอร์เหล่านี้ หลังจากนั้นฉันไม่เคยพบ RX-packets ที่สูญหายอีกต่อไป
นิลส์

@malayter: นี่เป็นวงแหวนบัฟเฟอร์ในเลเยอร์ 2 ดูคำตอบที่อัปเดตของฉัน
นิลส์

1
ในที่สุดเราก็มี 1GB มีการปรับแต่งมากมายในสถานที่ต่าง ๆ ดังนั้นจึงไม่สามารถพูดได้ว่ามีปัญหาเดียว
คนงาน

5

การติดตามอาจไม่ใช่คำตอบที่ชัดเจน แต่แน่นอนว่าความคิดบางอย่างจะนำออกมา

ลองเพิ่มสิ่งเหล่านี้ไปยัง 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

ในขณะที่ selectc tcp ack นั้นดีสำหรับประสิทธิภาพที่ดีที่สุดในกรณีของเครือข่ายแบนด์วิธสูง แต่ระวังข้อเสียอื่น ๆด้วย ประโยชน์ของการปรับขนาดหน้าต่างอธิบายไว้ที่นี่ สำหรับตัวเลือก sysctl ตัวที่สาม: ตามค่าเริ่มต้น TCP จะบันทึกเมตริกการเชื่อมต่อต่างๆในแคชเส้นทางเมื่อการเชื่อมต่อปิดลงดังนั้นการเชื่อมต่อที่สร้างขึ้นในอนาคตอันใกล้นี้สามารถใช้สิ่งเหล่านี้เพื่อตั้งค่าเงื่อนไขเริ่มต้น โดยปกติแล้วจะเพิ่มประสิทธิภาพโดยรวม แต่บางครั้งอาจทำให้ประสิทธิภาพลดลง หากตั้งค่าไว้ TCP จะไม่แคชเมตริกในการปิดการเชื่อมต่อ

ตรวจสอบกับ

ethtool -k ethX

เพื่อดูว่าเปิดใช้งานการถ่ายโหลดหรือไม่ TCP checksum offloadและoffloadเซ็กเมนต์ขนาดใหญ่ได้รับการสนับสนุนโดย Ethernet NIC ส่วนใหญ่ในปัจจุบันและเห็นได้ชัดว่าBroadcomยังรองรับ

ลองใช้เครื่องมือ

powertop

ในขณะที่เครือข่ายไม่ได้ใช้งานและเมื่อถึงความอิ่มตัวของเครือข่าย นี่จะแสดงให้เห็นอย่างแน่นอนว่าการขัดจังหวะของ NIC นั้นเป็นตัวการหรือไม่ การสำรวจความคิดเห็นของอุปกรณ์เป็นคำตอบสำหรับสถานการณ์ดังกล่าว FreeBsd รองรับการสลับโพลใน ifconfig แต่ linux ไม่มีตัวเลือกดังกล่าว ศึกษาสิ่งนี้เพื่อเปิดใช้การสำรวจ มันบอกว่า BroadCom ยังสนับสนุนการเลือกตั้งซึ่งเป็นข่าวดีสำหรับคุณ

บิดแพ็คเก็ตจัมโบ้อาจไม่ตัดให้คุณเนื่องจากคุณกล่าวถึง consitutes การจราจรของคุณส่วนใหญ่เป็นแพ็คเก็ตขนาดเล็ก แต่เดี๋ยวก่อนลองดูสิ!


2kaji ฉันจะลองแนะนำคุณในวันพรุ่งนี้ เกี่ยวกับ PowerTop - ฉันควรปรับแต่งการประหยัดพลังงานหรือไม่หากเป้าหมายของฉันคือประสิทธิภาพ
ผู้ปฏิบัติงาน

ใช่แน่นอนว่าอาจช่วยได้ ฉันพูดถึง powertop เพียงเพื่อให้แน่ใจว่าการขัดจังหวะเป็นสิ่งที่ชั่วร้าย ความถี่อินเทอร์รัปต์สามารถเก็บเกี่ยวได้จากเครื่องมืออื่น ๆ
kaji

ฉันเห็น "การกำหนดตารางเวลาขัดจังหวะใหม่" สูง - อาจเป็นเหตุผลหรือไม่ "การจัดกำหนดการใหม่ขัดจังหวะ" คืออะไร
ผู้ปฏิบัติงาน

ลองทำตามนี้ ---> help.ubuntu.com/community/ReschedulingInterrupts
kaji

ใช่ .. ฉันเห็นการกวดวิชานั้น แต่สำหรับแล็ปท็อปในขณะที่ฉันเห็นการขัดจังหวะสูงในเซิร์ฟเวอร์ จะพยายามนำไปใช้กับเซิร์ฟเวอร์
คนงาน

2

คุณต้องกระจายภาระให้กับคอร์ CPU ทั้งหมด เริ่ม 'irqbalance'


1
สิ่งนี้จะไม่ช่วยถ้า IRQ เดียวมีอิสระสูงมาก IRQBalance พยายามแจกจ่าย IRQ เดี่ยวเพื่อฟ้องร้องโปรเซสเซอร์เชิงตรรกะ - แต่จะไม่มีโปรเซสเซอร์มากกว่าหนึ่งตัวที่ให้บริการ IRQ เดียว
นิลส์

2

ฉันสังเกตเห็นในรายการ tweaks ที่ปิดการบันทึกเวลาโปรดอย่าทำเช่นนั้น นั่นคือการย้อนกลับไปสู่สมัยก่อนเมื่อแบนด์วิดท์มีราคาแพงมากและผู้คนต้องการที่จะประหยัดไม่กี่ไบต์ / แพ็คเก็ต ตัวอย่างเช่นใช้โดยสแต็ก TCP ในวันนี้เพื่อบอกว่าแพ็กเก็ตมาถึงซ็อกเก็ตใน "CLOSE_WAIT" เป็นแพ็กเก็ตเก่าสำหรับการเชื่อมต่อหรือเป็นแพ็กเก็ตใหม่สำหรับการเชื่อมต่อใหม่และช่วยในการคำนวณ RTT และการบันทึกไม่กี่ไบต์สำหรับการประทับเวลาจะไม่มีอะไรเมื่อเทียบกับที่อยู่ IPv6 ที่จะเพิ่ม การปิดการประทับเวลาจะเป็นอันตรายมากกว่าดี

คำแนะนำสำหรับการปิดการประทับเวลานี้เป็นเพียงการย้อนกลับที่ยังคงได้รับการส่งผ่านจากรุ่นหนึ่งของระบบการดูแลต่อไป เรียงลำดับของสิ่งที่ "ตำนานเมือง" เรียงลำดับของสิ่งต่าง ๆ


2

ฉันเสนอสิ่งนี้:

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

ทดสอบในเซิร์ฟเวอร์ Oracle DB บน ​​RHEL และในซอฟต์แวร์สำรองข้อมูล


5
ตัวเลขเหล่านี้สามารถกำหนดค่าได้เนื่องจากไม่มีขนาดที่เหมาะกับทุกคน นั่นหมายความว่าตัวเลขตัวเองไม่ได้มีค่า สิ่งที่อาจมีค่าคือวิธีการที่คุณใช้ในการตัดสินใจว่าจะใช้หมายเลขใด
kasperd

2

ในกรณีของฉันเพียง tuninng เดียว:

net.ipv4.tcp_timestamps = 0

ทำการเปลี่ยนแปลงครั้งใหญ่และมีประโยชน์มากเวลาโหลดไซต์ลดลง 50%


สิ่งที่จะต้องเสียหายอย่างรุนแรงในการตั้งค่าของคุณเพื่อที่จะเกิดขึ้น การประทับเวลาใช้น้อยกว่า 1% ของแบนด์วิดท์ภายใต้สถานการณ์ปกติและจะอนุญาตให้ TCP ทำการส่งสัญญาณซ้ำอีกครั้งอย่างแน่นหนากว่าเวลาอื่น
kasperd
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.