Extrem schlechte Geschwindigkeit beim Kopieren von Massendateien auf AFP-Freigaben in Yosemite

Einige Hardware-Hintergrundinformationen: Ich verwalte ein 3D-Grafiklabor mit etwa einem Dutzend iMac-Clients, auf denen 10.10.5 ausgeführt wird, und einem Mini, auf dem Server 10.10.2 ausgeführt wird (Server.app v4.0.3 / Build 14S350). Der Mini befindet sich in einem Sonnet xMac-Gehäuse, das ihn über Thunderbolt mit einem Areca ARC-1883X SAS-RAID-Controller und einer SmallTree P2E10G-1-T 10-Gb-Ethernet-Karte verbindet. Der Areca verwaltet zwei 40-TB-SAS-RAIDs und die SmallTree-Karte verbindet den Mini über Cat6a mit einem NetGear ProSafe XS708E 10-GbE-Switch. Die iMacs sind alle über 1 GbE Cat6 mit einem HP 1810-48G-Switch verkabelt, der wiederum über einen 6-Gb-Trunk mit dem NetGear-Switch verbunden ist.

Meine Künstler sind auf ein Problem mit Massenkopien von Dateien zwischen Verzeichnissen der AFP-Freigabe auf dem Mini gestoßen, mit dem sie arbeiten. Sie rendern häufig Sequenzen von Hunderten oder Tausenden von Bildern, und nachdem diese Bilder in ihren Ausgabeordner gerendert wurden, müssen sie in ein zweites Verzeichnis kopiert werden, damit unsere Compositoren damit arbeiten können. Der Kopiervorgang krabbelt absolut. Ein Beispiel von vor einer halben Stunde: 861 .exr-Dateien mit einer Gesamtgröße von etwa 350 MB dauerten etwa 3 Stunden, bevor wir sie bei ~75 % beendeten und es stattdessen vom Desktop des Servers aus per Bildschirmfreigabe in etwa 30 Sekunden erledigten (Aber unsere Künstler tun es dies Dutzende Male am Tag und kann natürlich keinen Zugriff auf die Bildschirmfreigabe mit dem Server erhalten, daher ist dies keine Lösung). Sie hängen nicht immer so, aber wir stoßen mindestens einmal am Tag auf einen solchen Fall und alle Massenkopien gehen viel langsamer als sie sollten. Dies passiert nur bei großen Dateigruppen: Wir können eine einzelne 300-MB-Datei ziemlich sofort zwischen Verzeichnissen kopieren.

Ich habe einige Tests durchgeführt, und dies scheint mehr als alles andere ein Problem des Yosemite-Clients zu sein. Ich führe Mountain Lion auf meinem eigenen Laptop aus und habe einige Tests in 10.8 und 10.10 mit WLAN und kabelgebundenem Ethernet sowie in lokalen und Netzwerkprofilen durchgeführt, da sich unsere Künstler bei Netzwerkkonten anmelden. Einige eingeschränkte Ergebnisse für 300 .exr-Dateien mit insgesamt 133 MB:

10.8 / WLAN / Lokales Profil: 300 Elemente kopieren in 53 Sek

10.8 / Verkabelt / Lokales Profil: Kopieren von 300 Elementen in 47 Sek

10.10 / Verkabelt / Lokales Profil: Kopieren von 300 Elementen in 223 Sek

10.10 / Verkabelt / Netzwerkprofil: 300 Elemente kopieren in 263 Sek

Netzwerkkonten sind etwas langsamer, aber der große ungeheure Unterschied scheint der 10.8-Client gegenüber dem 10.10-Client zu sein. Auch hier liegt das Problem bei langen Dateilisten und nicht bei einzelnen monolithischen Dateien. Unsere direkten Ethernet-Geschwindigkeiten zum Server sind fantastisch: Sowohl im 10.8 als auch im 10.10 Blackmagic Speed ​​Test erreiche ich Lese- und Schreibzugriffe auf den Server von über 110 MB/s und bin mit Wireless N Wi-Fi nur geringfügig langsamer. Dies wird nur dann zu einem Problem, wenn wir lange Listen von Dateien kopieren müssen, was wir viele Male am Tag tun müssen.

JEDE Hilfe, um herauszufinden, was hier schief läuft, wäre sehr willkommen! Das macht uns derzeit absolut wahnsinnig und tötet die Produktivität. Gerne posten Sie angeforderte Protokolle oder versuchen vorgeschlagene Systemoptimierungen. Danke schön!

Das ist ein fantastischer Detaillierungsgrad. Ich werde sehen, ob ich irgendwelche Ideen habe, aber ich frage mich, ob eine Anfrage an AppleCare Ihnen technische Unterstützung beim Abrufen von Protokollen verschaffen würde. Wenn dies über Neustarts hinweg reproduzierbar ist, wären sie sehr an einer Geschwindigkeitsregression interessiert, wie Sie sie melden. Möglicherweise können Sie herausfinden, was mit TCPDUMP zwischen der responsiven Kopie und den langsamen passiert.
Bitte fügen Sie die Server.app-Version auf dem Mini (Server) 10.10.2 hinzu!
Server.app v4.0.3 / build 14S350 - zu den Hintergrundinformationen oben hinzugefügt.

Antworten (1)

Hier ist, wie ich das Problem angreifen würde. Es ist keine Antwort, aber hoffentlich können wir Ideen sammeln, bis Sie Erfolge melden oder zumindest eine Möglichkeit haben, die Dinge zu messen.

  1. Richten Sie einen Testfall-Client ein, bei dem beim Anmelden keine Apps von Drittanbietern ausgeführt werden. Starten Sie diesen Client neu und stellen Sie die Netzwerkfreigabe bereit. Ausführen sudo sysdiagnose Finder, bevor Sie eine Kopie starten.
  2. Starten Sie einen TCP-Trace auf dem Netzwerkadapter, auf den Sie die Datei kopieren. Wenn Sie keine Verbindung herstellen en0, verwenden Sie die Systeminformationen, um den BSD-Namen der Netzwerkverbindung anzuzeigen.
  3. Sobald der Trace gestartet ist, starten Sie die Kopie der betreffenden Datei.
  4. Drücken Sie nach 3 Minuten (oder weniger, wenn die Übertragung früher erfolgt ist) Strg+C, um die Aufnahme zu beenden
  5. Führen Sie eine Sekunde sudo sysdiagnose Findernach der Netzwerkerfassung aus

Bei dieser langsamen Übertragungsgeschwindigkeit passiert etwas ernsthaftes im Netzwerkstapel, aber ohne einen Blick auf die Client-Protokolle zu werfen, wird es schwierig sein, mit Sicherheit zu wissen, was den Vorgang stoppt. Sie können auch eine Sysdiagnose auf der Serverseite ungefähr zur gleichen Zeit wie auf der Clientseite ausführen, um einen langsamen Server als Problem zu eliminieren. Es scheint, dass Sie genügend PS haben, damit sich der Speicher schnell bewegen kann, aber das Abrufen serverseitiger Protokolle wird auch helfen:

sudo sysdiagnose
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serverdiagnose

Die Spur ist:

sudo tcpdump -i en0 -s 0 -B 524288 -w ~/Desktop/AFPslow.pcap

Geben Sie hier die Bildbeschreibung ein

Jetzt denke ich, dass wir tatsächlich an etwas dran sind. Ich möchte nicht den gesamten Dump posten, da er 100 MB groß ist (ich kann bei Bedarf weitere Einzelheiten posten), aber bei etwa der HÄLFTE der Pakete fehlt die Prüfsumme! Ich weiß nicht genau, ob das normal ist, aber ich kann es mir nicht vorstellen. Die Inhalte dieser fehlgeschlagenen Prüfsummenpakete sind alle etwas unterschiedlich, aber viele von ihnen enthalten "[Dateiname einer der kopierten Dateien] #com.apple.metadata:_kMDItemUserTags" in der Nutzlast ... Schlagen Sie vielleicht schlechte Metadaten vor?
Außerdem können Sie das Fenster verkürzen. Meine Dump-Parameter enthalten wahrscheinlich Dateiinformationen und möglicherweise Schlüssel für Anmeldeinformationen. Aber wenn Sie den Nachrichtentyp in großen Mengen filtern, wird Ihnen der Fehler angezeigt. Ich werde versuchen, dies auch zu reproduzieren @infinitesunrise.