กลยุทธ์การแก้ไขปัญหาสำหรับประสิทธิภาพ iSCSI / NFS ที่แย่มาก


9

เรามี Synology RS3412RPxs ใหม่ที่ให้บริการ iSCSI เป้าหมายไปยังกล่อง Windows 2008 R2 สามกล่องและ NFS เป็นหนึ่งกล่อง OpenBSD 5.0

เข้าสู่ระบบ RS3412 ด้วย ssh และอ่าน / เขียนทั้งไฟล์ขนาดเล็กและไฟล์ 6GB โดยใช้ dd และบล็อคขนาดต่างๆแสดงประสิทธิภาพของดิสก์ I / O ที่ยอดเยี่ยม

ด้วยการใช้ dd หรือ iometer บนไคลเอนต์ iSCSI / NFS เราสามารถเข้าถึงได้สูงสุด 20Mbps (นั่นไม่ใช่การพิมพ์ผิดยี่สิบ Mbps) พวกเราหวังว่าจะใช้ประโยชน์จาก NIC ของ Gbit หลายตัวใน Synology ได้ดีขึ้น

ฉันตรวจสอบสวิตช์แล้วและการกำหนดค่าพอร์ต NIC ถูกตั้งค่าเป็นกิกะบิตไม่ใช่การต่อรองอัตโนมัติ เราได้ลองใช้ทั้ง Jumboframes และไม่มีความแตกต่าง ฉันตรวจสอบกับ ping ว่า MTU ปัจจุบันเป็น 9000 แล้วมีการปรับใช้เฟิร์มแวร์สองตัว

ฉันจะลองเชื่อมโยงโดยตรงระหว่างเป้าหมาย iSCSI และผู้เริ่มต้นเพื่อตัดปัญหาการสลับ แต่ตัวเลือกอื่นของฉันคืออะไร

ถ้าฉันแยกออก wireshark / tcpdump ฉันจะมองหาอะไร


เปิดใช้งานการควบคุมการไหลหรือไม่ สวิตช์ชนิดใดที่อยู่ระหว่าง
SpacemanSpiff

@SpacemanSpiff: ไม่ได้เปิดใช้งานการควบคุมการไหล คุณคาดหวังว่าจะสร้างความแตกต่าง? มันคือ ZyXEL GS2200
Alex Holst

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

คำตอบ:


4

ดูเหมือนว่าจะเป็นธีมทั่วไปที่นี่ลองพิจารณาการตั้งค่าการควบคุมการไหลของสวิตช์อีกครั้ง หากสวิตช์มีสถิติการนับอีเธอร์เน็ตลองดูที่และดูว่ามีเฟรมอีเทอร์เน็ตหยุดชั่วคราวจำนวนมากหรือไม่ ถ้าเป็นเช่นนั้นนั่นอาจเป็นปัญหาของคุณ โดยทั่วไปการปิดใช้งาน QOS บนสวิตช์ (es) สามารถแก้ไขปัญหานี้ได้


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

ดีใจที่ได้ช่วย ...
joeqwerty

3

โฟลว์ดังกล่าวแนะนำให้ฉันทราบว่าวิธีการควบคุมโฟลว์ TCP หลายวิธีไม่ทำงาน ฉันเคยเห็นปัญหาบางอย่างกับ Linux-kernels ที่พูดคุยกับ Vista รุ่นหลังของ Windows และคุณจะได้รับปริมาณงานเช่นนั้น พวกเขามักจะปรากฏตัวได้ดีใน Wireshark เมื่อคุณดู

ความเป็นไปได้ที่เลวร้ายที่สุดคือการที่ TCP ล่าช้า ack เสียแล้วและคุณจะเห็นรูปแบบการรับส่งข้อมูลที่มีลักษณะดังนี้:

packet
packet
[ack]
packet
packet
[ack]

ฉันได้แก้ไขแล้วโดยใช้การอัพเดทไดรเวอร์ NIC กับเซิร์ฟเวอร์ Windows NIC ที่ชาญฉลาดที่มาพร้อมกับเซิร์ฟเวอร์ (Broadcom) บางครั้งอาจล้มเหลวในรูปแบบที่น่าสนใจและนี่คือหนึ่ง

รูปแบบการรับส่งข้อมูลปกติจะเป็นแพ็กเก็ตจำนวนมากตามด้วยแพ็กเก็ต Ack

สิ่งอื่น ๆ ที่มองหาคือความล่าช้านาน ค่าที่น่าสงสัยคือ 0.2 วินาทีและ 1.0 วินาที นั่นแสดงให้เห็นว่าด้านหนึ่งไม่ได้รับสิ่งที่คาดหวังและกำลังรอการหมดเวลาก่อนที่จะตอบกลับ รวมรูปแบบแพ็กเก็ตที่ไม่ดีด้านบนเข้ากับความล่าช้า 200ms สำหรับ ACK และคุณจะได้รับปริมาณงานที่มากถึง 1MB / s

นั่นเป็นรูปแบบการรับส่งข้อมูลที่ไม่ดีซึ่งสังเกตเห็นได้ง่าย

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


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