tcpdump เพิ่มประสิทธิภาพ udp

ฉันใช้ชุดทดสอบโหลดเพื่อตรวจสอบประสิทธิภาพของการตั้งค่าต่อไปนี้:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

กล่าวโดยย่อชุดทดสอบ node.js จะส่งจำนวนเมตริกที่กำหนดทุก ๆ วินาทีไปยังอินสแตนซ์ StatsD ซึ่งอยู่บนเซิร์ฟเวอร์อื่น จากนั้น StatsD จะล้างข้อมูลเมตริกทุกวินาทีไปยังอินสแตนซ์ Graphite ที่อยู่บนเซิร์ฟเวอร์เดียวกัน จากนั้นฉันดูจำนวนของเมทริกที่ถูกส่งโดยชุดทดสอบจริงและจำนวนของกราไฟต์ที่ได้รับเพื่อตรวจสอบการสูญหายของแพ็คเก็ตระหว่างชุดทดสอบและกราไฟท์

อย่างไรก็ตามฉันสังเกตเห็นว่าบางครั้งฉันก็มีอัตราการส่งแพ็คเก็ตขนาดใหญ่มาก (โปรดทราบว่ามันถูกส่งด้วยโปรโตคอล UDP) ตั้งแต่ 20-50% ดังนั้นเมื่อฉันเริ่มดูว่าแพ็กเก็ตเหล่านี้ถูกทิ้งไปอย่างไรเนื่องจากเป็นปัญหาด้านประสิทธิภาพของ StatsD ดังนั้นฉันจึงเริ่มบันทึกการวัดในทุกส่วนของระบบเพื่อติดตามว่าการลดลงนี้เกิดขึ้นที่ไหน และนี่คือสิ่งที่แปลก

ฉันใช้tcpdumpเพื่อสร้างไฟล์จับภาพซึ่งฉันตรวจสอบหลังจากการทดสอบเสร็จสิ้นแล้ว แต่เมื่อใดก็ตามที่ฉันทำการทดสอบด้วยการรัน tcpdump การสูญเสียแพ็กเก็ตนั้นแทบจะไม่มีเลย! ดูเหมือนว่า tcpdump กำลังเพิ่มประสิทธิภาพการทดสอบของฉันและฉันไม่สามารถหาสาเหตุและวิธีการนี้ได้ ฉันใช้คำสั่งต่อไปนี้เพื่อบันทึกข้อความ tcpdump บนทั้งเซิร์ฟเวอร์และไคลเอนต์:

tcpdump -i any -n port 8125 -w test.cap

ในกรณีทดสอบหนึ่งกรณีฉันส่ง 40000 เมตริก / s การทดสอบในขณะที่รัน tcpdump มีการสูญเสียแพ็คเก็ตประมาณ 4% ในขณะที่การทดสอบโดยไม่ต้องมีการสูญเสียแพ็คเก็ตประมาณ 20%

ทั้งสองระบบกำลังทำงานเป็น Xen VM ด้วยการตั้งค่าต่อไปนี้:

• Intel Xeon E5-2630 v2 @ 2.60GHz
• 2GB RAM
• Ubuntu 14.04 x86_64

สิ่งที่ฉันตรวจสอบแล้วสำหรับสาเหตุที่เป็นไปได้:

• การเพิ่มขนาดการรับ / ส่งบัฟเฟอร์ของ UDP
• ภาระของ CPU ที่มีผลต่อการทดสอบ (โหลดสูงสุด 40-50% ทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์)
• รัน tcpdump บนอินเตอร์เฟสเฉพาะแทน 'any'
• รัน tcpdump ด้วย '-p' เพื่อปิดโหมด promiscuous
• รัน tcpdump บนเซิร์ฟเวอร์เท่านั้น ส่งผลให้เกิดการสูญเสียแพ็กเก็ต 20% ที่เกิดขึ้นและดูเหมือนว่าจะไม่ส่งผลกระทบต่อการทดสอบ
• รัน tcpdump บนไคลเอ็นต์เท่านั้น ส่งผลให้ประสิทธิภาพเพิ่มขึ้น
• การเพิ่ม netdev_max_backlog และ netdev_budget เป็น 2 ^ 32-1 เรื่องนี้ไม่ทำให้เกิดความแตกต่าง
• พยายามตั้งค่าโหมด promiscuous ที่เป็นไปได้ทุกรูปแบบ (เปิดเซิร์ฟเวอร์และปิดไคลเอ็นต์ปิดเซิร์ฟเวอร์และเปิดไคลเอนต์ทั้งเปิดและปิด) เรื่องนี้ไม่ทำให้เกิดความแตกต่าง

เมื่อ tcpdump ทำงานมันจะค่อนข้างพรอมต์ที่อ่านในเฟรมที่เข้ามา สมมติฐานของฉันคือการตั้งค่าบัฟเฟอร์แพ็คเก็ตแหวนของ NIC อาจมีขนาดเล็กลงเล็กน้อย เมื่อรัน tcpdump มันจะถูกทำให้ว่างเปล่าในเวลาที่เหมาะสมยิ่งขึ้น

หากคุณเป็นสมาชิก Red Hat แล้วบทความสนับสนุนนี้เป็นประโยชน์อย่างมากภาพรวมของ Packet แผนกต้อนรับ มีบางสิ่งในนั้นที่ฉันไม่คิดว่าคุณจะพิจารณา

พิจารณาว่าระบบของคุณเกี่ยวข้องกับ IRQ อย่างไร พิจารณาเพิ่ม 'dev_weight' ของอินเทอร์เฟซเครือข่าย (หมายถึงแพ็กเก็ตเพิ่มเติมที่อ่านจาก NIC ไปยังพื้นที่ผู้ใช้); ดูว่าแอปพลิเคชันอ่านซ็อกเก็ตบ่อยเพียงใด (สามารถใช้เธรดเฉพาะได้หรือไม่

เพิ่มบัฟเฟอร์เฟรม NIC (โดยใช้ethtoolคำสั่ง - ดูที่--set-ringอาร์กิวเมนต์ ฯลฯ )

ดูที่ 'รับการปรับขนาดด้านข้าง' และใช้อย่างน้อยที่สุดที่หลายเธรดรับเพื่ออ่านในการรับส่งข้อมูล

ฉันสงสัยว่า tcpdump จะทำบางสิ่งบางอย่างเย็นเช่นการใช้การสนับสนุนเมล็ดสำหรับบัฟเฟอร์แหวนแพ็คเก็ต นั่นจะช่วยอธิบายพฤติกรรมที่คุณเห็น

คุณกำลังใช้ผู้ว่าราชการคนใด ฉันเคยเห็นพฤติกรรมที่คล้ายกันกับผู้ว่า "ondemand" หรือ "อนุรักษ์นิยม"

ลองใช้ตัวควบคุม "ประสิทธิภาพ" และปิดการใช้งานคุณสมบัติการประหยัดพลังงานใด ๆ ใน BIOS ของเซิร์ฟเวอร์

มันเปลี่ยนอะไรไหม?

อีกวิธีคือip_conntarckโมดูลคุณแน่ใจหรือไม่ว่ากล่อง linux ของคุณสามารถรับการเชื่อมต่อใหม่ได้ ทดสอบผ่าน:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

คุณต้องทดสอบ

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

ถ้านับสูงสุด == การเชื่อมต่อสูงสุดของคุณเต็มและกล่องลินุกซ์ของคุณไม่สามารถยอมรับการเชื่อมต่อใหม่ได้
หากคุณไม่มี ip_conntrack คุณสามารถโหลดได้อย่างง่ายดายผ่านmodprobe ip_conntrack

ฉันสงสัยว่าฝ่ายรับนั้นไม่สามารถจัดการอัตราแพ็คเก็ตได้และนี่คือสาเหตุ:

1. การใช้ tcpdump บนไคลเอนต์จะช่วยลดแพ็กเก็ตที่ลดลง: tcpdump ทำให้ไคลเอ็นต์ช้าลงดังนั้นเซิร์ฟเวอร์จึงเห็นอัตราแพคเกอร์ที่ต่ำกว่ามากซึ่งมันสามารถจัดการบางส่วนได้ คุณควรจะสามารถยืนยันสมมติฐานนี้ได้โดยการตรวจสอบเคาน์เตอร์แพ็คเก็ต RX / TX บนไคลเอนต์และเซิร์ฟเวอร์

2. คุณพูดถึงว่าคุณเพิ่มขนาดรับ / ส่งบัฟเฟอร์ของ UDP คุณสามารถอธิบายรายละเอียดได้อย่างไร เป็นสิ่งสำคัญที่บนเซิร์ฟเวอร์คุณต้องเปลี่ยนทั้งrmem_max และ rmem_default ตัวอย่าง: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

ทดสอบการตั้งค่าของคุณ

หยุด statsd และแอปพลิเคชันโหนดจากนั้นกับระบบที่ไม่ได้ใช้งานใช้iperfเพื่อทดสอบอัตราแพ็คเก็ตที่เครือข่าย / เคอร์เนลสามารถจัดการได้ หากคุณสามารถสตรีมแพ็คเก็ต 40K / s ด้วย iperf แต่ไม่สามารถใช้ statsd ได้คุณควรมีสมาธิในการปรับแต่ง statsd

tunables อื่น ๆ

นอกจากนี้อย่าลืมปรับแต่งnet.core.netdev_max_backlog : จำนวนสูงสุดของแพ็กเก็ตที่อนุญาตให้เข้าคิวเมื่ออินเทอร์เฟซเฉพาะรับแพ็คเก็ตเร็วกว่าที่เคอร์เนลสามารถประมวลผลได้