โหลดเครือข่ายใดที่จำเป็นต้องมีการขัดจังหวะโดย NIC กับการหยั่งเสียง?

มีใครบ้างที่มีข้อมูลหรือการคำนวณขั้นพื้นฐานที่สามารถตอบได้เมื่อต้องการการรวมเฟรม (NAPI) และเมื่อการขัดจังหวะครั้งเดียวต่อเฟรมเพียงพอหรือไม่

ฮาร์ดแวร์ของฉัน: IBM BladeServer HS22, ฮาร์ดแวร์ Broadcom 5709 Gigabit NIC (MSI-X) พร้อมโปรเซสเซอร์ Dual-Core Xeon E5530 วัตถุประสงค์หลักคือ Squid proxy server Switch เป็นชุด Cisco 6500 ที่ดี

ปัญหาพื้นฐานของเราคือช่วงเวลาสูงสุด (ปริมาณการเข้าชม 100 Mbps เพียง 10,000 pps) ที่เวลาแฝงและการสูญเสียแพ็กเก็ตเพิ่มขึ้น ฉันทำการปรับแต่งและอัพเกรดเคอร์เนลเป็น 2.6.38 มากและปรับปรุงการสูญหายของแพ็คเก็ต แต่เวลาแฝงยังไม่ดีพอ ส่ง Ping เป็นระยะ ๆ กระโดดได้สูงถึง 200ms บน LAN Gbps ท้องถิ่น การตอบกลับโดยเฉลี่ยของปลาหมึกกระโดดจาก 30ms เป็น 500 + ms แม้ว่าการโหลด CPU / หน่วยความจำดี

ขัดจังหวะการปีนขึ้นไปประมาณ 15,000 / วินาทีในช่วงสูงสุด Ksoftirqd ไม่ค่อยได้ใช้ CPU มากนัก ฉันได้ติดตั้ง irqbalance เพื่อรักษาความสมดุลของ IRQ (8 แต่ละตัวสำหรับ eth0 และ eth1) ในทุกคอร์ แต่ก็ไม่ได้ช่วยอะไรมาก

ดูเหมือนว่า Intel NIC จะไม่เคยมีปัญหาแบบนี้ แต่ด้วยความจริงของระบบเบลดและฮาร์ดแวร์การกำหนดค่าคงที่เราก็ติดอยู่กับ Broadcom

ทุกอย่างชี้ไปที่ NIC ว่าเป็นผู้ร้ายหลัก ความคิดที่ดีที่สุดที่ฉันมีตอนนี้คือพยายามลดการขัดจังหวะโดยรักษาทั้งเวลาแฝงต่ำและปริมาณงานสูง

น่าเสียดายที่ bnx2 ไม่รองรับ adaptive-rx หรือ tx

Napi VS Adaptive Interruptsคำตอบกระทู้ให้มุมมองในช่วงที่ดีของการดูแลขัดจังหวะ แต่ไม่มีข้อมูลที่เป็นรูปธรรมเกี่ยวกับวิธีการคำนวณที่เหมาะสม ethtool รวมกันการตั้งค่าสำหรับการแก้ปัญหาให้ มีวิธีที่ดีกว่าแล้วเพียงลองผิดลองถูก?

ภาระงานและการกำหนดค่าฮาร์ดแวร์ดังกล่าวข้างต้นจำเป็นต้องใช้ NAPI หรือไม่ หรือควรจะสามารถอยู่บนอินเตอร์รัปต์เดียวต่อแพ็คเก็ตได้หรือไม่

เป็นคำถามที่ดีที่ทำให้ฉันได้อ่านเพื่อลองคิดดู หวังว่าฉันจะบอกว่าฉันมีคำตอบ ... แต่อาจมีคำแนะนำบางอย่าง

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

Sar เอาท์พุท:

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

อย่างที่คุณเห็นจำนวนของแพ็กเก็ตที่สูงมากต่อวินาทีนับและไม่มีการปรับแต่ง ethtool พิเศษใด ๆ บนเครื่องนี้ อ๋อ ... ชิปเซ็ตของ Intel : \

สิ่งเดียวที่ทำคือการปรับสมดุล irq ด้วยตนเองกับ / proc / irq / XXX / smp_affinity บนพื้นฐานต่ออินเตอร์เฟส ฉันไม่แน่ใจว่าทำไมพวกเขาเลือกที่จะไปทางนั้นแทนด้วยความไม่สมดุล แต่ดูเหมือนว่าจะทำงาน

ฉันก็คิดเกี่ยวกับคณิตศาสตร์ที่จำเป็นในการตอบคำถามของคุณ แต่ฉันคิดว่ามีตัวแปรมากเกินไป ดังนั้น ... โดยสรุปในความคิดของฉันคำตอบคือไม่ฉันไม่คิดว่าคุณสามารถทำนายผลลัพธ์ได้ที่นี่ แต่ด้วยการเก็บข้อมูลที่เพียงพอคุณควรปรับแต่งมันให้ดีขึ้น

ต้องบอกว่าสิ่งที่ฉันรู้สึกว่าคุณกำลังผูกฮาร์ดแวร์ - นี่ ... ในเฟิร์มแวร์หรือ interop บั๊กบางชนิด

แน่นอนว่าได้รับความสามารถของซีพียูชิปเซ็ตและบัสเปรียบเทียบกับปริมาณการใช้งานที่ต่ำมากคุณไม่มีเหตุผลอะไรเลยที่คุณจะต้องจัดการการขัดจังหวะในรูปแบบใด ๆ เรามีเครื่อง RHEL 5.3 64- บิตหลายเครื่องที่มี 10Gbps NIC และการขัดจังหวะของพวกเขาก็ไม่ได้เลวร้ายอะไรเลยนี่คือน้อยกว่า 100 เท่า

เห็นได้ชัดว่าคุณมีการกำหนดค่าคงที่ (ฉันใช้เบลดของ HP ซึ่งคล้ายกันมาก) ดังนั้นการเปลี่ยน NICs สำหรับ Intels ตอนนี้เป็นตัวเลือกที่ง่าย แต่สิ่งที่ฉันจะพูดคือฉันเริ่มเห็นปัญหาที่คล้ายกันหลายรอบฟอรัมนี้และที่อื่น ๆ กับ Broadcom NIC นั้นโดยเฉพาะ เว็บไซต์ SE เคยมีปัญหาบางอย่างกับความไม่ลงรอยกันแบบนี้และการแลกเปลี่ยนกับ Intel NICs ช่วยอย่างแน่นอน

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

คำถามเกี่ยวกับการขัดจังหวะคือผลกระทบต่อประสิทธิภาพโดยรวมของระบบ อินเทอร์รัปต์สามารถจองผู้ใช้และการประมวลผลเคอร์เนลได้แม้ว่าคุณจะไม่เห็นการใช้งาน CPU มากนัก แต่ก็มีการสลับบริบทจำนวนมากที่เกิดขึ้นและเป็นผลการดำเนินงานที่ยอดเยี่ยม คุณสามารถใช้vmstatและตรวจสอบsystemคอลัมน์csส่วนหัวสำหรับอินเทอร์รัปต์และสวิทช์บริบทต่อวินาที (อินเตอร์รัปต์รวมนาฬิกาดังนั้นคุณต้องน้ำหนักในนั้น) ซึ่งคุ้มค่ากับการตรวจสอบ

คำตอบสั้น ๆ โดยตรง:

หากคุณเปิดใช้งานการลงคะแนนคุณจะลดการสลับบริบท (ตามปกติเนื่องจากการหยุดทำงาน) จากสิ่งที่พวกเขามีตอนนี้ (15kips ในกรณีของคุณ) เป็นจำนวนที่กำหนดไว้ล่วงหน้า (ปกติ 1k ถึง 2k)

หากปัจจุบันคุณมีปริมาณการใช้ข้อมูลสูงกว่าจำนวนที่กำหนดไว้คุณควรมีเวลาตอบสนองที่ดีขึ้นด้วยการเปิดใช้การสำรวจความคิดเห็น การสนทนาก็เป็นจริงเช่นกัน ฉันจะไม่บอกว่านี่เป็น "จำเป็น" นอกเสียจากว่าบริบทสวิตช์จะส่งผลกระทบต่อประสิทธิภาพ

หากต้องการติดตาม: ด้วยโมดูล NAT และ conntrack ที่ไม่ได้ทำการโหลดและกฎไอเท็ม iptables ที่ย่อเล็กสุดเราจะได้รับประสิทธิภาพที่ยอดเยี่ยม ตัวโหลดบาลานซ์ IPVS ทำได้มากกว่า 900 Mbps / 150 kpps นี่คือขณะที่ยังคงใช้ชิปเซ็ต Broadcom bnx2 เดียวกัน

ดังนั้นในการสรุป: การจัดการขัดจังหวะดูเหมือนดีและเป็นค่าเริ่มต้นสำหรับ Debian ด้วยเคอร์เนล 2.6.38 / 3.0.x ดูเหมือนจะยอมรับได้

แน่นอนฉันต้องการใช้ Intel NICs เพื่อให้เราสามารถใช้แพ็คเกจ Debian มาตรฐาน การต่อสู้กับเฟิร์มแวร์ปลอด bnx2 นั้นเป็นการเสียเวลาอย่างมาก