Chiến lược khắc phục sự cố cho hiệu suất iSCSI / NFS rất kém


9

Chúng tôi có một RS3412RPx Synology mới cung cấp các mục tiêu iSCSI cho ba hộp Windows 2008 R2 và NFS cho một hộp OpenBSD 5.0.

Đăng nhập vào RS3412 bằng ssh và đọc / ghi cả tệp nhỏ và tệp 6GB bằng dd và các khối khác nhau cho thấy hiệu suất I / O của đĩa lớn.

Sử dụng dd hoặc iometer trên các máy khách iSCSI / NFS, chúng tôi đạt tới 20Mb / giây (Đó không phải là một lỗi đánh máy. Hai mươi Mbps). Chúng tôi hy vọng sẽ sử dụng tốt hơn nhiều NIC Gbit trong Synology.

Tôi đã xác minh công tắc và cấu hình cổng NIC được đặt thành gigabit, không tự động đàm phán. Chúng tôi đã thử với và không có Jumboframes không có sự khác biệt. Tôi đã xác minh với ping rằng MTU hiện là 9000. Hai bản nâng cấp firmware đã được triển khai.

Tôi sẽ thử liên kết trực tiếp giữa mục tiêu iSCSI và bộ khởi tạo để loại trừ các vấn đề về chuyển đổi, nhưng các tùy chọn khác của tôi là gì?

Nếu tôi thoát ra khỏi wireshark / tcpdump, tôi sẽ tìm gì?


Kiểm soát dòng chảy có được kích hoạt không? Những loại chuyển đổi ở giữa?
SpacemanSpiff

@SpacemanSpiff: Điều khiển luồng không được kích hoạt. Bạn có mong đợi rằng sẽ làm cho một sự khác biệt? Đó là ZyXEL GS2200.
Alex Holst

Một loại bảng nối đa năng, nhưng đủ để có hiệu suất tốt hơn thế. Tò mò muốn xem những gì cáp chéo giúp bạn thực hiện khôn ngoan.
SpacemanSpiff

Câu trả lời:


4

Dường như là chủ đề phổ biến ở đây, hãy xem xét lại các cài đặt kiểm soát luồng trên công tắc. Nếu (các) công tắc có số liệu thống kê bộ đếm Ethernet, hãy xem chúng và xem liệu có một số lượng lớn các khung Ethernet PAUSE không. Nếu vậy, đó có lẽ là vấn đề của bạn. Nói chung, việc tắt QOS trên (các) công tắc sẽ giải quyết vấn đề này.


Tôi nhìn lại. Kiểm soát luồng đã bị vô hiệu hóa và bộ đếm PAUSE bằng không trên tất cả các giao diện. Việc kích hoạt kiểm soát luồng khiến bộ đếm PAUSE tăng 25% số lượng gói. Chúng tôi đã xác định một số phần cứng không hiển thị hiệu năng yếu tương tự, vì vậy bây giờ chúng tôi đang tìm cách cập nhật trình điều khiển nic và thay thế một số nics nhất định bằng những phần mềm có khả năng hơn. QoS đã bị vô hiệu hóa trên switch. Cảm ơn vì đầu vào của bạn.
Alex Holst

Vui mừng được giúp đỡ ...
joeqwerty

3

Các luồng như vậy gợi ý cho tôi rằng các phương thức điều khiển luồng TCP khác nhau không hoạt động đúng. Tôi đã thấy một số vấn đề với các nhân Linux nói chuyện với các phiên bản Windows sau Vista và bạn có được thông lượng như thế. Họ có xu hướng xuất hiện khá tốt trong Wireshark một khi bạn xem.

Khả năng xấu nhất tuyệt đối là ack bị trì hoãn TCP bị hỏng hoàn toàn và bạn sẽ thấy một mẫu lưu lượng truy cập trông giống như:

packet
packet
[ack]
packet
packet
[ack]

Tôi đã giải quyết vấn đề đó bằng cách áp dụng các bản cập nhật trình điều khiển NIC cho các máy chủ Windows. Các NIC thông minh đi kèm với một số máy chủ (máy chủ rộng) đôi khi có thể thất bại theo những cách thú vị và đây là một.

Một mẫu lưu lượng thông thường sẽ là một số lượng lớn các gói theo sau là một gói Ack.

Điều khác để tìm kiếm là sự chậm trễ lâu. Giá trị đáng ngờ là .2 giây và 1.0 giây. Điều đó cho thấy rằng một bên không nhận được những gì nó mong đợi và đang chờ thời gian chờ hết hạn trước khi trả lời. Kết hợp mẫu gói dữ liệu xấu ở trên với độ trễ 200ms cho ACK và bạn nhận được thông lượng của một con số khổng lồ 1MB / s.

Đó là những mẫu giao thông xấu dễ nhận thấy.

Tôi đã không làm việc với loại thiết bị NAS đó vì vậy không biết nó có thể điều chỉnh được như thế nào để sửa bất cứ thứ gì được tìm thấy.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.