SMB3 sürücüsüne neden dd, cp, rsync ve macOS Finder arasında yazma hızı farkı var?

Tl; dr - NAS'ımıza iki farklı Mac istemcisinden SMB ve AFP aracılığıyla 60 MB / sn'lik sınırlı yazma hızının nedenini bulamıyoruz. Karşılaştırma: Aynı ağdaki eski bir Windows 7 dizüstü bilgisayar sürekli 100 MB / sn yazar.

Bu soruyu ilk kez okuduysanız, lütfen Güncelleme 4 bölümüne geçin . rsyncnedenini (tek bir dosya için!) anlamasak bile düşük hızın ana sebebidir.

Orijinal Soru: Mac OS 10.11.5 ve üstü ile hız darboğazı SMB3 / NAS'ı bulun

rsync --progress -a /localpath/test.file /nas/test.fileMacOS ve Windows kopya bilgileri üzerinden test ettik .

NAS, RAID1'de sadece gigabit ethernet bileşenleri ve yeni ethernet kabloları (en azından Cat5e) bulunan iki HGST Deskstar NAS SATA 4 TB (HDN724040ALE640) ile mevcut DSM 6.0.2'yi (5.x ile test edilmiştir) çalıştıran bir DS713 + 'dır.

Mac istemcileri ilk önce yalnızca 20 MB / sn. Ancak signing_required=nodüzeltmeyi uygulamak ( burada açıklanan ) SMB2 ve SMB3 aracılığıyla yazma hızını 60 MB / saniyeye itti. AFP ayrıca yaklaşık 60 MB / sn. Sonuç, protokole ve (Mac) istemciye bağlı olarak yaklaşık 5 MB / sn'dir.

Zaten denediklerimiz:

Ağ

1. İperf3 üzerinden ağ performansı test edildi. Sonuç: 926 Mbit / s. İyi görünüyor.
2. Denenmiş Dual Link Toplama / Gümrüklü ağ arayüzleri. Değişiklik yok.
3. MTU 6000 ve 9000'e yükseltildi. Değişiklik yok.
4. Tüm kabloları kontrol ettim. Hepsi iyi durumda en azından Cat5e iyi.

Diskler

1. Checked SMART Sağlıklı görünüyor.
2. dd if=/dev/zero of=write.test bs=256M count=4Çeşitli bsve countayarlarla (128/8, 512M / 2, 1024/1) doğrudan yazma diskine test hızı . Sonuç: yaklaşık 120 MB / s (blok boyutuna / sayısına bağlı olarak)

SMB / AFP

1. Karşılaştırma SMB2, SMB3 ve AFP birbirlerine karşı. Eşittir.
   Aşağıdaki güncelleştirmeye bakın: macOS'un SMB uygulamasını dışlamak için yanlış yöntem kullanıldı. Windows'ta SMB daha hızlıdır, macOS 10.11 ve 10.12 ile gelen yeni SMB ayarları bunun nedeni olabilir.
2. Soket seçenekleri de dahil olmak üzere SMB ayarlarını değiştirmeye çalıştı (bu talimatları izleyerek )
3. Gecikmiş ack ayarlarının farklı sürümünü denedim ve rsync --sockopts=TCP_NODELAY(yorumlar)

Yazma hızında önemli bir değişiklik yok. Yapılandırmanın gerçekten yüklendiğini ve doğru smb.conf dosyasını düzenlediğimizi iki kez kontrol ettik .

sistem

1. İzlenen CPU ve RAM yükü. Hiçbir şey azami düzeye çıkar. CPU yaklaşık% 20, RAM yaklaşık% 25 aktarım sırasında.
2. Neredeyse hazır bir kurulumda DSM 5.xx ile aynı NAS'ı test etti. Yüklü ek yazılım yok. Not: Bunlardan iki tanesi farklı konumlarda. Synology'nin CloudSync'i ile senkronize durumdalar. Aynı sonuç.
3. Sistem kaynaklarını çekebilecek gereksiz her şeyi devre dışı bıraktı.

Bunun oldukça varsayılan bir kurulum olduğunu, süslü uyarlamalar, istemciler veya ağ bileşenleri olmadığını düşünüyoruz. Synology'nin yayınladığı metriklere göre NAS, 40 MB / sn ile 75 MB / sn arasında daha hızlı çalışmalıdır. Ama darboğazı bulamıyoruz.

Müşteriler / NAS

Mac istemcileri, NAS'dan sadece 2m uzakta, aynı üzerinden çalışan bir MacPro 5,1 (standart kablolu NIC, 10.12.3 (16D32) çalışıyor) ve bir MacBookPro10,1 (Thunderbolt ağ adaptörü, 10.11.6 çalışıyor) testte Windows dizüstü bilgisayar olarak gigabit anahtarı.

Farklı yerlerde bu NAS'lardan ikimiz var ve sonuçlar aynı. NAS'ın az çok fabrika varsayılan değeri (3. taraf yazılım yüklü olmasa bile). Synology CloudSync aracılığıyla diğer NAS ile senkronize edilen yalnızca iki RAID1, EXT4 formatlı disk. Anahtar olmadan NAS'a doğrudan bağlanmak kadar ileri gittik, aynı sonuç.

Önemli Güncelleme

MacOS / OS X'in SMB uygulamasını dışlamak için kullanılan yöntem yanlıştı. Kendi SMB sürümünü kullanacağını varsayarak sanal bir makine aracılığıyla test ettim, ancak açıkçası trafik, SMB sürümü üzerinden çalışan macOS'a teslim edildi.

Windows dizüstü bilgisayar kullanarak artık ortalama 100 MB / sn'lik bir hız elde edebildim. KOBİ uygulamasının / 10.11 ve 10.12 ile gelen güncellemelerin gösterilmesi düşük performansa neden olabilir. Olarak signing_requiredayarlanmış olsa bile no.

Birisi güncellemelerle değişmiş olabilecek ve performansı etkileyebilecek bazı diğer ayarlara dikkat çekebilirse harika olur.

Güncelleme 2 - yeni bilgiler

AndrewHenle , yorumlarda daha fazla bilgi için Wireshark'ı kullanarak trafiği ayrıntılı olarak incelemem gerektiğini belirtti.

Bu nedenle sudo tcpdump -i eth0 -s 65535 -w tcpdump.dump, biri 512 MB ve diğeri 1 GB olan iki test dosyasını aktarırken NAS üzerinde çalıştım . Ve çöplüğü Wireshark ile inceledi.

Bulduğum:

1. NAS'da SMB3 etkinleştirilmiş olmasına rağmen (hem en azından Wireshark'a göre) hem OS X hem de Windows SMB2 kullanıyor gibi görünüyor .
2. OS X, MTU ile uyumlu görünüyor . Paketler, daha fazla ağ ek yükü ve gönderilen paketler (dökümlerde görülebilir) sağlayan 1514 bayta sahiptir .
3. Windows , 26334 bayta kadar paketleri gönderiyor gibi görünüyor (verileri doğru okuduysam! Lütfen doğrulayın.) MTU buna izin vermemeli bile, NAS'ta 1500'e ayarlandığından, maksimum ayar orada 9000 olacaktır (Synology ayrıca testlerinde 1500 ayarını kullanır).
4. Ekleyerek kullanım SMB3 için MacOS zorlamak için çalışıyorum smb_neg=smb3_onlyiçin /etc/nsmb.conf değil işi yoktu ya da en azından daha hızlı transfer yol açmadı.
5. Koşu rsync --sockopts=TCP_NODELAYack ayarları (3 0) TCP çeşitli kombinasyonları ile herhangi bir etkisi vardı geciken (Not: Ben 3 varsayılan ack ayarıyla tcpdump ran).

512 MB (test-2.file) kopyalarken 2 ve 1024 MB (test.file) kopyalarken 2 .csv dosyası olarak 2 döküm oluşturdum. Şunları yapabilirsiniz buraya Wireshark ihracatını indirmek (25.2 MB). Yerden tasarruf etmek için sıkıştırılmış ve açıklayıcı olarak adlandırılmıştır.

Güncelleme 3 - Smbutil Çıktısı

Yorumlarda harrymcsmbutil statshares -a tarafından talep edildiği gibi çıktı .

==================================================================================================
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

--------------------------------------------------------------------------------------------------

Bununla ilgili not: Burada SIGNING_SUPPORTEDolmanın true, yapılandırmadaki ayarın çalışmadığı anlamına gelmediğinden eminim . Ama sadece NAS tarafından destekleniyor. Üç kez signing_requiredyapılandırmamın ayarının değiştirilmesinin yazma hızı üzerinde bir etkisi olduğunu kontrol ettim (ayarlandığında ~ 20 MB / s, kapalı olduğunda ~ 60 MB / s).

Güncelleme 4 - Samba Savaşları: Yeni Bir Umut

Biraz utanç verici hissettiriyor, ancak buradaki ana sorun - yine - ölçüm gibi görünüyor.

Dışarı Dönüşler rsync --progress -a30 MB hakkında maliyetlerin / hız yazma s. İle yazma ddSMB paylaşımına doğrudan ve kullanma time cp /local/test.file /NAS/test.filehızlı 85-90 MB / s hakkında altındadır ve görünüşe kopyasına hızlı yolu MacOS Bulucu civarında hiçbir olmadığından, ölçmek için en zor da yöntemdir 100 MB / sn ( zamanlama veya hız göstergesi - buna kimin ihtiyacı var, değil mi? İlk önce 1 GB ve sonra 10 GB'lık bir dosyayı kronometre kullanarak kopyalayarak ölçtük.

Bu sorunun son güncellemesinden bu yana denediklerimiz.

1. Mac istemcisinden Mac istemcisine kopyalayın. Her ikisi de SSD'lere sahiptir (MacPro, kendi diske 250 MB / s ile yazar, 300 MB / s ile MacBook Pro). Sonuç: ddMacBook Pro'dan MacPro'ya ( rsync25 MB / s) yazarak yetersiz 65 MB / sn . 25 MB / sn'yi görmek rsync'i sorgulamaya başladığımız andı. Yine de 65 MB / s son derece yavaş. Yani macOS'taki KOBİ uygulaması… iyi, tartışmalı görünüyor.
2. DD ve CP ile farklı ack ayarları denendi - şans yok.
3. Son olarak, mevcut tüm nsmb.conf seçeneklerini listelemenin bir yolunu bulduk. Çok basit man nsmb.conf. Dikkat ! Çevrimiçi sürüm eskidir!

Bu yüzden aralarında birkaç ayar daha denedik:

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

Not: smb_neg=smb3_only- beklediğim gibi - geçerli bir ayar değil. protocol_vers_map=4geçerli eşdeğer olmalıdır.

Her neyse, bu ayarların hiçbiri bizim için fark yaratmadı.

Bir bakışta yeni sorular

1. Neden rsync bir (1!) Dosyasını kopyalamak için pahalı bir yoldur? Burada senkronize edilecek / karşılaştırılacak çok şey yok, değil mi? Tcpdump olası ek yükü de göstermez.

2. Bir SMB paylaşımına aktarırken neden macOS bulucudan daha yavaş ddve cpyavaş? Finder ile kopyalama yaparken, TCP iletişiminde önemli ölçüde daha az bildirim olduğu görülmektedir. (Tekrar: Ack ayarı, örneğin delayed_ack=1bizim için bir fark yaratmadı .)

3. Windows neden MTU'yu görmezden geliyor ve macOS aracılığıyla mümkün olan her şeye kıyasla en iyi performansı veren önemli ölçüde daha az TCP paketi gönderiyor.

Paketler macOS'tan böyle görünüyor (sürekli 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"

Ve bu Windows'dan geliyor (boyut olarak değişen 26334'e kadar)

"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"

Sen edebilirsiniz tamamını buradan .csv indirmek (25.2 MB) dosya adları (OS transfer yöntemi ve dosya boyutu) kopyalandıktan açıklamak.

1. benzer bir soru var ama ilginç cevapları var, belki de bu konuyu kontrol edebilirsiniz 5 yorum: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Burada alıntı "Peter van Hooft". Ne / hangi linux dist test temel emin değilim. ve rsync sürümü de. Ancak: 1. o bize denemek için bir fikir verebilir --sparse artışlar performansı mümkün olabilir eğer bayrak. 2. O NFS protokolü üzerinde test ama aynı hız sorunu bir araya geldi, bu nedenle, BT belki protokol (SMB2 / 3, AFP, vb) nedeni.

10 Gb'lık bir bağlantı üzerinden NFS3 bağları kullanarak verileri bir dosya sunucusundan diğerine kopyalamak için rsync kullanıyoruz . Tampon boyutlarının artırılmasının (hızlı test olarak) performansı artırdığını bulduk . Kullanırken --sparse 2Mbps gelen 100Mbps elli kat, bu artışlar performans.

2. İşte rsync performansı hakkında ilginç bir inceleme. https://lwn.net/Articles/400489/

LWN.net, performans sorununun 2010'da yayınlanan makale bile çekirdekle ilgili olabileceği ve NAS veya MacOS'ta değiştirilemeyeceğine dair bir sonuca sahiptir. Ancak, bu makale bize çekirdek sorununun sağlama toplamı (tahminim) hesaplamasından kaynaklanabileceğini düşünmektedir .

Açık olan bir şey var: Mythtv sistemimin çekirdeğini yükseltmeliyim. Genel olarak, 2.6.34 ve 2.6.35-rc3 çekirdekleri eski 2.6.27 çekirdeğinden daha iyi performans verir. Ancak, tinkering veya değil, rsync hala 100MiB / s üzerinde kopyalayan basit bir cp'yi yenemez. Gerçekten de, rsync basit yerel kopyalar için gerçekten çok fazla CPU gücüne ihtiyaç duyar. En yüksek frekansta cp, rsync'in 70 + 55 saniyesine kıyasla sadece 0.34 + 20.95 saniye CPU süresine ihtiyaç duyuyordu.

Ayrıca alıntı yorumları var:

Bu rsync'i Not zaman doğrular her transfer dosya düzgün bir bütün dosya kontrol ederek alıcı tarafında yeniden ve sağlama dosya transfer gibi üretilir

güncelleme 1 : benim hatam, bu açıklama --checksum içindir. burada kontrol edin: [--checksum seçeneği açıklaması geliştirildi.] PS, ben 2'den fazla bağlantı göndermek için yeterli bir üne sahip değilim.

ama ben rsync adam sayfasından aynı açıklamayı bulamıyorum, bu yüzden birinin aşağıda Kalın hakkında konuştuğunu tahmin ediyorum:

Rsync, boyutu veya son değiştirilme zamanında değişen dosyaları arayan bir "hızlı kontrol" algoritması (varsayılan olarak) kullanılarak aktarılması gereken dosyaları bulur . Diğer korunmuş özniteliklerdeki değişiklikler (seçeneklerin istediği gibi), hızlı kontrol, dosyanın verilerinin güncellenmesi gerekmediğini gösterdiğinde doğrudan hedef dosyada yapılır.

Bu nedenle, cp / tar / cat ile karşılaştırın, eğer küçük veya büyük dosyaları bir grup kopyalamak için rsync kullanırsak performans sorununa neden olabilir. AMA nedeniyle rsync kaynak kodunu okuyamıyorum nedeniyle bu nihai nedeni olduğunu onaylayamıyorum.

benim fikrim kontrol etmeye devam etmek:

1. Awenro test için hangi rsync sürümünü kullanıyor? En son sürüme güncelleyebilir misiniz?
2. --debug = FLAGS ile --stats ve -v kullanıldığında hangi çıktıyı görelim

bayraklar

--stats Bu, rsync'e dosya aktarımı üzerinde ayrıntılı bir istatistik kümesi yazdırmasını söyleyerek, rsync algoritmasının verileriniz için ne kadar etkili olduğunu söylemenizi sağlar.

--debug = BAYRAKLAR Bu seçenek, görmek istediğiniz hata ayıklama çıktısı üzerinde ayrıntılı denetime sahip olmanızı sağlar. Tek bir bayrak adının ardından bir seviye numarası gelebilir; 0, bu çıkışın susturulması anlamına gelir, 1 varsayılan çıkış seviyesidir ve bu bayrağın çıkışını artıran daha yüksek sayılar (daha yüksek seviyeleri destekleyenler için). Tüm düzey bayrak adlarını , çıktılarını ve ayrıntılı düzeydeki her artış için hangi bayrak adlarının eklendiğini görmek için --debug = help kullanın .

sonunda, daha fazla bilgi almak için bu ek yazı okumak tavsiye ederim.
"Ağ üzerinden büyük miktarda veri aktarımı" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Doğru hatırlıyorsam, Rsync / ssh bağlantı smb değil şifreler. Sadece bir dosyaysa, bir sistem o dosyayı okuyabilir ve diğeri okuyamayabilir. Ayrıca, MTU'nun 1514'ün üzerinde olması için "devler" / "Jumbo Çerçeveler" paketlerini etkinleştirmeniz gerektiğini unutmayın, paketlerin daha fazla kesilmesi gerektiği gerçeği, paketi "yeniden paketlemek" için ek yükün olabileceğini ima edebilir. Dikkat edilmesi gereken ikinci şey, "devler" / "Jumbo Çerçeveler" in her iki uçta ve HER ŞEYİN ARASINDA etkinleştirilmesi gerektiğidir.

1514 normal Ethernet çerçeveleridir. İşletim sistemine / uygulamaya bağlı olarak 6k-9k çerçeveler devler veya "Jumbo Çerçeveler" olarak adlandırılır

Nas'ım (VM'leri olan bir bilgisayar VM'lerden biri NAS) ve sftp (sshfs kullanan) [devler etkin değil] ile istasyonum (aradaki cihaz) microtik 2011 (devam ediyor) arasında ortalama 80MB / s sadece anahtar anahtar çipi)

MTU'nun iki nokta arasında müzakere edildiğini ve bir yol boyunca farklı kapasitede birkaç MTU'nuz olabileceğini ve MTU'nun mevcut en düşük seviyede olacağını unutmayın.

edit: SMB dosya aktarımı için çok verimli değil.