Die unendlich lange miese Geschichte mit dem Server (FreeNas)

T

TH-SH

Aktives Mitglied
Thread Starter
Dabei seit
18.09.2004
Beiträge
779
Reaktionspunkte
19
Moin.

Seit einigen Jahren (mein erste Beitrag dazu im MacMini-Forum ist vom Februar 2014!! habe ich Probleme mit der Netzwerkanbindung meines Minis. Das Problem ist immer noch dasselbe: In einem Gigabit Heimnetzwerk fängt eine Kopieraktion (egal ob Datei, Dateien oder Ordner mit Inhalt) mit 120-165 MB/s (125MB/s ist theoretisches Maximum, 165MB/s sind Schwächen der Meßmethode) an, nach kurzer Zeit (mal 10% mal 50% der kopierten Datenmenge) geht die Datenrat auf Null, manchmal auf fast Null (kB/s) zurück. Egal ob 800MB Kopiervolumen oder 20 Gigabyte. Sporadisch (nach 2-5 MINUTEN) gibt es dann mal einen 10-20 Sekunden-Schwung mit max. Netzwerkgeschwindigkeit.

Im Laufe der fast 3 Jahren hat sich einiges geändert: Der Mini ist derzeit das aktuelle Modell (Late 2014, Macmini7,1), zu Anfang war es das Modell davor. Der Server war zu Anfang ein HP Proliant G7, inzwischen ist es ein G8 (G1610T), beide male mit max. RAM-Ausbau (jetzt 16GB), sonst "wie ausgepackt". Bedingt durch 2 Umzüge ist das Netzwerk 2 mal komplett neu aufgebaut wurden (jedesmal neue Kabel, andere Entfernungen (früher 20 Meter, heute 2 Meter). Auch der Router hat sich verändert (Fritzbox 7490, Irgendwas mit O2-Logo, Fritzbox 6490 (Kabel D), jetzt Speedport (wegen Netzteildefekt neuestes Gerät seit 2 Monaten).

Beim OS fing ich bei 10.6.8 an, über 10.7.5 (Neuinstallation), beim aktuellem Rechner 10.11, jetzt 10.12.2. Teilweise mehrfache "Clean Installs" durch den Apple Store in Hamburg, wo der Rechner 3 mal zur Reparatur war (keine Fehler gefunden).

Der Server hatte zu Anfang als OS FreeNAS 8.x, später 9.2, aktuell 9.10.1-U4.

Zum Test hatte ich auf dem Server auch Nas4Free installiert (da lief irgendwas nicht, also kein Realtest), Omnios (habe ich auch nicht installiert bekommen), Ubuntu 16.4 Desktop (exakt gleiche Probleme wie mit FreeNAS).

Als Protokoll habe ich APF, SMB, NFS probiert. Egal welches Protokoll, der Fehler ist reproduzierbar.

HDDs? Zu Anfang hatte ich NAS-HDDs von WD drin, 4 TB-Klasse. Dann 6 TB, dann 8TB Archives. (auch Seagate dazwischen) Nun "normale" 8 TB-WD (mit 2 Stück 4TB gemischt). Also mehr als 2 mal komplett durchgetauscht. Der Fehler bleibt.

Komischerweise hat der Mini kein Problem, DVD-Images mit 2 oder 3 GB aus den Netz zu saugen und das bei voller Geschwindigkeit (100MB Kabelanschluß zwischenzeitlich, derzeit leider nur 16MB). Dann zeigt mir die Aktivitätsanzeige eine glatte Linie am phsysikalischem Maximum an.

Also, Glaskugeldeuter vor: Wo ist der Hund begraben? Warum haben andere Leute mit ähnlicher Hardware keine Probleme? Was kann ich noch machen? Ich bin ja bereit einiges auszuprobieren, allerdings gibt es eine Produktklasse die mir NIE ins Haus kommt: All das was mit "Windows" anfängt.

Thomas
 
Zuletzt bearbeitet von einem Moderator:
...hängt ein Switch dazwischen? Falls ja, tausche den mal aus oder verbinde den Mac versuchsweise direkt per Kabel mit dem NAS, ohne Switch oder irgend etwas dazwischen. Der Mac braucht dann logischerweise eine manuell zugewiesene IP aus dem Subnetz des NAS.
Kaputte Switche können die krudesten Netzwerkprobleme verursachen. In der gleichen Problemklasse auch sehr beliebt: Überspannungsschutz-Steckdosenleisten mit durchgeschleiftem Netzwerk - allerdings wird hier das Netz meist nur langsam...
 
Hmm, getauscht hast Du schon vieles. Was ist denn jedes mal gleich geblieben und um gegen zu prüfen, was hat sich schon alles verändert/wurde erneuert?
 
...hängt ein Switch dazwischen? Falls ja, tausche den mal aus oder verbinde den Mac versuchsweise direkt per Kabel mit dem NAS, ohne Switch oder irgend etwas dazwischen. Der Mac braucht dann logischerweise eine manuell zugewiesene IP aus dem Subnetz des NAS.

Auch schon probiert - keine Änderung...

Thomas
 
Hmm, getauscht hast Du schon vieles. Was ist denn jedes mal gleich geblieben und um gegen zu prüfen, was hat sich schon alles verändert/wurde erneuert?

Das Einzige, was immer gleich blieb ist >> Mac OS <<.

Thomas
 
log files auf dem NAS oder mac mal angeguckt, wenn die datenrate einbricht?
 
auf dem mac halt die konsole auf, k.a. wie du auf das NAS zugreifst? web gui oder per ssh?
 
Das Einzige, was immer gleich blieb ist >> Mac OS <<.

Thomas

Denk mal ein bisschen outside of the box. zB Die USB-Ports, WLanchip oder ethernetanschluss hast doch nicht auch schon abgelötet und ersetzt, oder? Mit den Standarts kommst Du hier ja wohl nicht weiter, sonst hättest das in den 2 Jahren gefunden. Die Standart Tricks brauchen wir also nicht durch gehen. Darum mal ein neuer Ansatz, ganz von Anfang an
 
...nur zur Klarstellung: Bei einer Direktverbindung Mac - NAS mit jeweils manuell zugewiesener IP tritt das Problem auch auf? Tritt das Problem auch bei anderen, so angeschlossenen Rechnern auf? Hast Du evtl. auf den ProLiants ein modifiziertes BIOS geflasht? Hast Du das ZFS-SLOG auf dem FreeNAS evtl. auf eine SSD ausgelagert, die möglicherweise einen Schaden hat?
 
In einem Gigabit Heimnetzwerk fängt eine Kopieraktion (egal ob Datei, Dateien oder Ordner mit Inhalt) mit 120-165 MB/s (125MB/s ist theoretisches Maximum, 165MB/s sind Schwächen der Meßmethode) an, nach kurzer Zeit (mal 10% mal 50% der kopierten Datenmenge) geht die Datenrat auf Null, manchmal auf fast Null (kB/s) zurück. Egal ob 800MB Kopiervolumen oder 20 Gigabyte. Sporadisch (nach 2-5 MINUTEN) gibt es dann mal einen 10-20 Sekunden-Schwung mit max. Netzwerkgeschwindigkeit.


...noch ein Gedanke: Hast Du an den Cache-Parametern der ZFS-Konfiguration herumgeschraubt? Ich zitiere mal aus

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

"Tangent: Dangers of overly large ZFS write cache.

FreeBSD's ZFS implementation defaults to allowing up to 1/8th your system's memory for a transaction group. Already explained, "if the new transaction group fills before the previous one finishes writing, ZFS pauses I/O". This is a critical factor to consider.

If you are expecting your system to remain responsive under heavy load, it is important to consider the pool's ability to sustain a given I/O load. A few notes:

1) Heavy use of in-pool ZIL has a substantial negative effect on the pool's overall IOPS capability. Hopefully you've already decided SLOG is the way to go, but if not, be aware that you can actually cause everything to crawl at a snail's pace through poor design...

2) A small pool on a system with a lot of memory, such as one where a designer has included lots of ARC for maximum responsiveness, can counter-intuitively perform very poorly due to the increased default size for transaction groups. In particular, if you have a system with four disks, each of which is capable of writing at 150MB/sec, and the pool can actually sustain 600MB/sec, that still doesn't fit well with a system that has 32GB of RAM, because it allows up to 4GB per txg, which is greater than the 3GB per 5 seconds that the pool can manage.

As a result, tuning the size of a transaction group to be appropriate to a pool is advised, and since that maximum size is directly related to SLOG sizing, it is all tied together."
 
Kannst du dir eine Intel-Ethernetkarte für den Server besorgen und testen wie die Übertragungsrate damit ist? Von Broadcom wird im Freenas-Forum immer abgeraten.
 
...noch ein Gedanke: Hast Du an den Cache-Parametern der ZFS-Konfiguration herumgeschraubt? Ich zitiere mal aus

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

"Tangent: Dangers of overly large ZFS write cache."
Ich hab schon ein ZFS Server mit 2 GB RAM betrieben, und selbst da ging die LESErate niemals auf die hier beschrieben xx kb/s. Das halte ich mal für unwahrscheinlich, dass man das per caching so kaputt tunen kann.

Kannst du dir eine Intel-Ethernetkarte für den Server besorgen und testen wie die Übertragungsrate damit ist? Von Broadcom wird im Freenas-Forum immer abgeraten.

Bei meiner kurzen Googlesuche steht nicht, dass die HP-Kisten Broadcom Chipsätze haben? Auch glaub ich nicht, dass die so schlecht wären. Selbst die gammeligen 10 Jahre alten Realtek RTL8139 100Mbits chipsets schaffen konstant mehr als 10mb/s.

@TS: Du hast wirklich schon alles gemacht. Ich glaube auch es liegt an deinem OS X. Starte doch mal ein Linux Livesystem (einfach iso saugen -> usb stick) auf dem Mac und kopiere die gleiche Datei, die vorher einen Einbruch in der Datenrate gezeigt hat. Falls es da nicht zu Einbrüchen kommt, würde ich mal das OS X sichern, dann platt machen, und schauen wie es sich mit einer Neuinstallation verhält. Oder den Tipp von oneOeight befolgen und mal in die Konsole (Dienstprogramme->Konsole) schauen zur Fehlersuche.
 
Denk mal ein bisschen outside of the box. zB Die USB-Ports, WLanchip oder ethernetanschluss hast doch nicht auch schon abgelötet und ersetzt, oder? Mit den Standarts kommst Du hier ja wohl nicht weiter, sonst hättest das in den 2 Jahren gefunden. Die Standart Tricks brauchen wir also nicht durch gehen. Darum mal ein neuer Ansatz, ganz von Anfang an

Also, in Englisch denken ist nicht so mein Ding... ;-))

Klar sind Chips getauscht, in Form des neuen Rechners. Inzwischen habe ich sogar eine Thunderbolt Dockingstation dran, das hat aber auch keine Besserung gebracht.

Thomas
 
...nur zur Klarstellung: Bei einer Direktverbindung Mac - NAS mit jeweils manuell zugewiesener IP tritt das Problem auch auf?

Ja.

Tritt das Problem auch bei anderen, so angeschlossenen Rechnern auf?

Ja.

Hast Du evtl. auf den ProLiants ein modifiziertes BIOS geflasht?

Nein.


Hast Du das ZFS-SLOG auf dem FreeNAS evtl. auf eine SSD ausgelagert, die möglicherweise einen Schaden hat?

Nein.
 
Zugriff auf den Server: Dateien per Finder, Administration per WebGUI.

kann man in der web gui auch die log files einsehen?
interessant wäre halt, ob der irgendwelche pakete dropt oder das interface sonst wie tcp fehler meldet …
 
Kannst du dir eine Intel-Ethernetkarte für den Server besorgen und testen wie die Übertragungsrate damit ist? Von Broadcom wird im Freenas-Forum immer abgeraten.

Muß ich mal sehen. Ist so eine Karte beim "Höker um die Ecke" vorrätig? Worauf muß ich achten?

Thomas
 
Ich hab schon ein ZFS Server mit 2 GB RAM betrieben, und selbst da ging die LESErate niemals auf die hier beschrieben xx kb/s. Das halte ich mal für unwahrscheinlich, dass man das per caching so kaputt tunen kann.



Bei meiner kurzen Googlesuche steht nicht, dass die HP-Kisten Broadcom Chipsätze haben? Auch glaub ich nicht, dass die so schlecht wären. Selbst die gammeligen 10 Jahre alten Realtek RTL8139 100Mbits chipsets schaffen konstant mehr als 10mb/s.

@TS: Du hast wirklich schon alles gemacht. Ich glaube auch es liegt an deinem OS X. Starte doch mal ein Linux Livesystem (einfach iso saugen -> usb stick) auf dem Mac und kopiere die gleiche Datei, die vorher einen Einbruch in der Datenrate gezeigt hat. Falls es da nicht zu Einbrüchen kommt, würde ich mal das OS X sichern, dann platt machen, und schauen wie es sich mit einer Neuinstallation verhält. Oder den Tipp von oneOeight befolgen und mal in die Konsole (Dienstprogramme->Konsole) schauen zur Fehlersuche.

Heute abend...

Standard 19:44:06.171849 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:06.392310 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:06.392315 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:06.392320 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:06.392324 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:06.392789 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:06.172601 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.485028 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.264680 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.485411 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.265339 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.506833 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.286633 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.506854 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.507483 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.287182 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.527524 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.307180 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.527540 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.307379 +0100 KernelEventAgent tid 54485244 type 'nfs', mounted on '/Volumes/NAS-Bilder', from '192.168.2.100:/mnt/NAS-Bilder', not responding
Standard 19:44:07.527935 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.307846 +0100 KernelEventAgent tid 54485244 found 1 filesystem(s) with problem(s)
Standard 19:44:07.307975 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.548863 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.548880 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.549305 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.328977 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.329291 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.570187 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.349843 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.350050 +0100 KernelEventAgent tid 54485244 type 'nfs', mounted on '/Volumes/NAS-Bilder', from '192.168.2.100:/mnt/NAS-Bilder', not responding
Standard 19:44:07.570630 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.350591 +0100 KernelEventAgent tid 54485244 found 1 filesystem(s) with problem(s)
Standard 19:44:07.350750 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.591534 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.371193 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:07.591548 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:07.591968 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:07.371748 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:13.652408 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 0, EGID: 0
Standard 19:44:13.652810 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 20, EGID: 20
Standard 19:44:13.653675 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:13.669025 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:16.313689 +0100 CommCenter #watchdog #I Callback Watchdog: checkin 7046
Standard 19:44:16.313809 +0100 CommCenter #watchdog #I Server Watchdog: checkin 7046
Standard 19:44:18.391536 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:18.171681 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:18.391550 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:18.391555 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:18.391560 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:18.391996 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:18.172608 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:23.681638 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 0, EGID: 0
Standard 19:44:23.682059 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 20, EGID: 20
Standard 19:44:23.682656 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:23.695596 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:31.314232 +0100 CommCenter #watchdog #I Callback Watchdog: checkin 7047
Standard 19:44:31.314356 +0100 CommCenter #watchdog #I Server Watchdog: checkin 7047
Standard 19:44:33.705872 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 0, EGID: 0
Standard 19:44:33.706860 +0100 opendirectoryd Client: <private>, UID: 0, EUID: 0, GID: 20, EGID: 20
Standard 19:44:33.707697 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:33.720770 +0100 opendirectoryd Client: <private>, UID: 502, EUID: 502, GID: 20, EGID: 20
Standard 19:44:36.776927 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:36.777008 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:36.777047 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:36.777105 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:37.397761 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:37.398216 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:37.179283 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)
Standard 19:44:38.393015 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393027 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393031 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393034 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393038 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393050 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393054 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393058 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393062 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393066 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: not responding
Standard 19:44:38.393390 +0100 kernel nfs server 192.168.2.100:/mnt/NAS-Bilder: is alive again
Standard 19:44:38.175297 +0100 KernelEventAgent tid 54485244 received event(s) VQ_NOTRESP (1)

(Die Mac-user Webseite meckert, das ich nicht mehr als 10000 Zeichen eingeben darf. daher nur der mir wichtig erscheinende Teil)
 
Zuletzt bearbeitet:
kann man in der web gui auch die log files einsehen?
interessant wäre halt, ob der irgendwelche pakete dropt oder das interface sonst wie tcp fehler meldet …

Nicht das ich wüßte. Per WebGUI ist auf eine Shell zugreifbar. Aber wo auf der Kiste liegen Logfiles? Ich bin Mac-Nutzer, mit BSD habe ich keine Erfahrung.

Thomas
 
Zurück
Oben Unten