Tl; dr - Chúng tôi không thể tìm thấy lý do cho tốc độ ghi giới hạn 60 MB / giây vào NAS của chúng tôi thông qua SMB và AFP từ hai máy khách Mac khác nhau. So sánh: Một máy tính xách tay Windows 7 cũ trong cùng một mạng ghi ổn định 100 MB / giây.
Nếu bạn đọc câu hỏi này lần đầu tiên, vui lòng bỏ qua phần Cập nhật 4 . rsynclà lý do chính cho tốc độ thấp, mặc dù chúng tôi không hiểu tại sao (đối với một tệp duy nhất!).
Câu hỏi gốc: Tìm nút cổ chai tốc độ SMB3 / NAS với Mac OS 10.11.5 trở lên
Chúng tôi đã thử nghiệm rsync --progress -a /localpath/test.file /nas/test.filetrên macOS và thông tin sao chép của Windows.
NAS là DS713 + chạy DSM 6.0.2 hiện tại của họ (cũng đã thử nghiệm với 5.x), với hai HGST Deskstar NAS SATA 4TB (HDN724040ALE640) trong RAID1 chỉ với các thành phần ethernet gigabit và cáp ethernet mới (ít nhất là Cat5e).
Máy khách Mac đầu tiên chỉ thực hiện 20 MB / giây. Nhưng việc áp dụng bản signing_required=nosửa lỗi (được mô tả ở đây ) đã đẩy tốc độ ghi lên 60 MB / giây thông qua SMB2 và SMB3. AFP cũng cung cấp khoảng 60 MB / giây. Kết quả thay đổi khoảng 5 MB / giây tùy thuộc vào giao thức và máy khách (Mac).
Những gì chúng tôi đã thử:
Mạng
- Đã kiểm tra hiệu suất mạng thông qua iperf3. Kết quả: 926 Mbit / s. Có vẻ tốt.
- Đã thử giao diện kết nối / kết nối mạng ngoại quan kép. Không thay đổi.
- Tăng MTU lên 6000 và 9000. Không thay đổi.
- Đã kiểm tra tất cả các dây cáp. Tất cả đều tốt ít nhất là Cat5e, trong tình trạng tốt.
Đĩa
- Đã kiểm tra SMART Có vẻ khỏe mạnh.
- Đã kiểm tra tốc độ ghi trực tiếp vào đĩa với
dd if=/dev/zero of=write.test bs=256M count=4nhiều cài đặtbsvà khác nhaucount(128/8, 512M / 2, 1024/1). Kết quả: khoảng 120 MB / s (tùy thuộc vào kích thước khối / số lượng)
SMB / AFP
Điểm chuẩn SMB2, SMB3 và AFP với nhau. Về bằng nhau.
Xem cập nhật bên dưới: Đã sử dụng phương pháp sai để loại trừ việc triển khai SMB của macOS. SMB trên Windows nhanh hơn, cài đặt SMB mới đi kèm với macOS 10.11 và 10.12 có thể là lý do.- Đã thử điều chỉnh cài đặt SMB, bao gồm các tùy chọn ổ cắm (theo hướng dẫn này )
- Đã thử phiên bản khác nhau của cài đặt ack bị trì hoãn và
rsync --sockopts=TCP_NODELAY(ý kiến)
Không có thay đổi đáng kể về tốc độ ghi. Chúng tôi đã kiểm tra lại xem cấu hình đã thực sự được tải chưa và chúng tôi đang chỉnh sửa smb.conf đúng .
Hệ thống
- Đã xem CPU và RAM. Không có gì tối đa. CPU khoảng 20%, RAM khoảng 25% trong quá trình chuyển.
- Đã thử nghiệm cùng một NAS với DSM 5.xx trong một thiết lập gần như vượt trội. Không có phần mềm bổ sung được cài đặt. Lưu ý: Chúng tôi có hai trong số này ở các địa điểm khác nhau. Chúng được đồng bộ hóa thông qua CloudSync của Synology. Cùng một kết quả.
- Vô hiệu hóa mọi thứ không cần thiết có thể rút tài nguyên hệ thống.
Chúng tôi nghĩ rằng đây là một thiết lập mặc định, không thích ứng, ứng dụng khách hoặc thành phần mạng. Theo số liệu Synology xuất bản, NAS sẽ thực hiện nhanh hơn 40 MB / s đến 75 MB / s. Nhưng chúng ta không thể tìm thấy nút cổ chai.
Khách hàng / NAS
Các máy khách Mac là MacPro 5,1 (NIC có dây tiêu chuẩn, chạy 10.12.3 (16D32)) và MacBookPro10,1 (bộ điều hợp mạng Thunderbolt, chạy 10.11.6) chỉ cách NAS khoảng 2m, chạy trên cùng gigabit chuyển đổi như máy tính xách tay Windows trong thử nghiệm.
Chúng tôi có hai trong số các NAS ở các địa điểm khác nhau và kết quả là giống hệt nhau. Các giây NAS ít nhiều mặc định xuất xưởng (thậm chí không cài đặt phần mềm của bên thứ 3). Chỉ cần hai đĩa định dạng RAID1, EXT4 đồng bộ hóa với NAS khác thông qua Synology CloudSync. Chúng tôi đã đi xa như kết nối trực tiếp với NAS mà không cần chuyển đổi, kết quả tương tự.
Cập nhật quan trọng
Phương pháp được sử dụng để loại trừ việc triển khai SMB của macOS / OS X là sai. Tôi đã thử nghiệm nó thông qua một máy ảo, giả sử rằng nó sẽ sử dụng phiên bản SMB của riêng nó, nhưng rõ ràng lưu lượng được chuyển sang macOS, chạy qua phiên bản SMB của nó.
Sử dụng máy tính xách tay Windows Bây giờ tôi đã có thể đạt được trung bình 100 MB / s. Việc chỉ ra việc thực hiện / cập nhật SMB đi kèm với 10.11 và 10.12 có thể gây ra hiệu suất kém. Ngay cả khi signing_requiredđược đặt thành no.
Sẽ thật tuyệt nếu ai đó có thể chỉ ra một số cài đặt khác có thể đã thay đổi với các bản cập nhật và có thể ảnh hưởng đến hiệu suất.
Cập nhật 2 - những hiểu biết mới
AndrewHenle đã chỉ ra trong các ý kiến rằng tôi nên điều tra giao thông một cách chi tiết bằng cách sử dụng Wireshark để có cái nhìn sâu sắc hơn.
Do đó, tôi đã chạy sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumptrên NAS, trong khi chuyển hai tệp thử nghiệm một với 512 MB và một với 1 GB. Và kiểm tra bãi rác với Wireshark.
Những gì tôi tìm thấy:
- Cả OS X và Windows dường như đều sử dụng SMB2 mặc dù SMB3 được kích hoạt trên NAS (ít nhất là theo Wireshark).
- OS X dường như gắn bó với MTU . Các gói có 1514 byte dẫn đến nhiều mạng hơn và các gói được gửi (hiển thị trong các bãi chứa).
- Windows dường như gửi các gói lên tới 2634 byte (nếu tôi đọc dữ liệu chính xác! Vui lòng xác minh.) Ngay cả khi MTU không cho phép điều đó, vì nó được đặt thành 1500 trên NAS, cài đặt tối đa sẽ là 9000 ở đó (Synology cũng sử dụng cài đặt 1500 trong các thử nghiệm của họ).
- Cố gắng buộc macOS sử dụng SMB3 bằng cách thêm
smb_neg=smb3_onlyvào /etc/nsmb.conf không hoạt động hoặc ít nhất không dẫn đến chuyển nhanh hơn. - Chạy
rsync --sockopts=TCP_NODELAYvới các kết hợp khác nhau của cài đặt ack bị trì hoãn TCP (0 đến 3) không có hiệu lực (Lưu ý: Tôi đã chạy tcpdump với cài đặt ack mặc định là 3).
Tôi đã tạo 4 kết xuất dưới dạng tệp .csv, 2 trong khi sao chép 512 MB (test-2.file) và 2 trong khi sao chép 1024 MB (test.file). Bạn có thể tải xuống bản xuất của Wireshark tại đây (25,2 MB). Chúng được nén để tiết kiệm không gian và được đặt tên tự giải thích.
Cập nhật 3 - đầu ra smbutil
Đầu ra smbutil statshares -atheo yêu cầu của harrymc trong các ý kiến.
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
home
SERVER_NAME server-name._smb._tcp.local
USER_ID 502
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
QUERYINFO_NOT_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
--------------------------------------------------------------------------------------------------
Lưu ý về điều này: Tôi chắc chắn SIGNING_SUPPORTEDlà trueở đây không có nghĩa là các thiết lập trong cấu hình không hoạt động. Nhưng chỉ có điều nó được hỗ trợ bởi NAS. Tôi đã kiểm tra ba lần rằng việc thay đổi signing_requiredcài đặt trong cấu hình của tôi có ảnh hưởng đến tốc độ ghi (~ 20 MB / s khi được điều chỉnh, ~ 60 MB / s khi tắt).
Cập nhật 4 - Cuộc chiến Samba: Hy vọng mới
Nó cảm thấy hơi xấu hổ, nhưng vấn đề chính ở đây - một lần nữa - dường như là sự đo lường.
Hóa ra rsync --progress -achi phí khoảng 30 MB / s tốc độ viết. Viết ddtrực tiếp vào chia sẻ SMB và sử dụng time cp /local/test.file /NAS/test.filenhanh hơn với tốc độ khoảng 85-90 MB / giây và rõ ràng cách nhanh nhất để sao chép là Trình tìm kiếm macOS với tốc độ khoảng 100 MB / giây (đây cũng là phương pháp khó đo nhất, vì không có chỉ báo thời gian hoặc tốc độ - ai cần điều đó, phải không? o_O). Chúng tôi đã đo nó bằng cách đầu tiên sao chép tệp 1 GB và sau đó là tệp 10 GB, sử dụng đồng hồ bấm giờ.
Những gì chúng tôi đã cố gắng kể từ khi cập nhật cuối cùng của câu hỏi này.
- Sao chép từ máy khách Mac sang máy khách Mac. Cả hai đều có ổ SSD (MacPro ghi với 250 MB / s để sở hữu đĩa, MacBook Pro với 300 MB / s). Kết quả: 65 MB / s ít ỏi thông qua
ddviệc viết từ MacBook Pro sang MacPro (rsync25 MB / s). Thấy 25 MB / giây là lúc chúng tôi bắt đầu đặt câu hỏi về rsync. Vẫn còn 65 MB / s là cực kỳ chậm. Vì vậy, việc triển khai SMB trên macOS có vẻ như rất tốt. - Đã thử cài đặt ack khác nhau với dd và cp - không có may mắn.
- Cuối cùng, chúng tôi đã tìm thấy một cách để liệt kê tất cả các tùy chọn nsmb.conf có sẵn. Nó là một đơn giản
man nsmb.conf. Chú ý phiên bản trực tuyến đã lỗi thời!
Vì vậy, chúng tôi đã thử thêm một vài cài đặt, trong số đó:
notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes
Lưu ý: smb_neg=smb3_onlylà - như tôi đã mong đợi - không phải là cài đặt hợp lệ. protocol_vers_map=4nên tương đương hợp lệ.
Dù sao, không có cài đặt nào trong số này tạo ra sự khác biệt cho chúng tôi.
Câu hỏi mới trong nháy mắt
Tại sao rsync lại là một cách đắt tiền để sao chép một (1!) Tệp. Không có nhiều thứ để đồng bộ hóa / so sánh ở đây, phải không? Các tcpdump không chỉ ra chi phí có thể.
Tại sao
ddvàcpchậm hơn công cụ tìm macOS khi chuyển sang chia sẻ SMB? Có vẻ như khi sao chép bằng Finder, có ít sự thừa nhận hơn trong giao tiếp TCP. (Một lần nữa: Cài đặt ack, ví dụ:delayed_ack=1không có sự khác biệt đối với chúng tôi.)Tại sao Windows dường như bỏ qua MTU, gửi các gói TCP lớn hơn đáng kể và do đó ít hơn, dẫn đến hiệu suất tốt nhất, so với mọi thứ có thể thông qua macOS.
Đây là những gì các gói trông giống như từ macOS (liên tục 1514)
"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445 > 56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"
Và điều này đến từ Windows (lên tới 26334, kích thước khác nhau)
"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445 > 49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"
Bạn có thể tải xuống .csv đầy đủ tại đây (25,2 MB), tên tệp giải thích những gì đã được sao chép (HĐH, phương thức truyền và kích thước tệp).