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!
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.
sudo sysdiagnose Finder
, bevor Sie eine Kopie starten.en0
, verwenden Sie die Systeminformationen, um den BSD-Namen der Netzwerkverbindung anzuzeigen.sudo sysdiagnose Finder
nach der Netzwerkerfassung ausBei 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
Fahrrad
klanomath
unendlicher Sonnenaufgang