Re: tar und senden via ssh schlaegt fail

On Thu, Jun 23, 2011 at 09:54:29AM +0200, Martin Sugioarto wrote:
> Am Thu, 23 Jun 2011 12:06:50 +1000
> schrieb "Peter Ross" <Peter.Ross(at)bogen.in-berlin.de>:
>
> > Quoting "Peter Ross" <Peter.Ross(at)bogen.in-berlin.de>:
> >
> > >> Peter Ross wrote:
> > >>
> > >> > Bei einem ziemlich grossen Verzeichnisbaum (200G) geht das in
> > >> > die
> > >> Hose, mit
> > >> >
> > >> > Write failed: Cannot allocate memory
> >
> > Ich habe die Memory-Statistiken nicht richtig gelesen, und habe nun
> > bemerkt, dass es der ZFS ARC-Speicher ist, der groesser und groesser
> > wird und so ziemlich allen verfuegbaren Speicher "auffrisst"
> > (kstat.zfs.misc.arcstats.size)
>
> Hallo,
>
> das ist normal. ZFS nimmt sich einfach was frei ist und was es gerade
> braucht. Das ist auch sehr effizient. Wieso soll man den Speicher nicht
> benutzen, wenn man ihn brauchen könnte?
>
> > Mit ARC ist wohl ein "Schatten-Puffer" im System, der nur waechst
> > und nicht freigibt(?) Nun ja.. es hat wohl seinen Preis.
>
> Er müsste den wieder frei geben, aber dazu musst Du eine Situation
> provozieren wo der Speicher tatsächlich gebraucht wird (und zwar für
> etwas anderes als ZFS).

Im Zweifelsfall in einem Socketbuffer und das widerlegt den Punkt,
dass man ihn nicht anders brauchen könnte.
Das Problem mit ZFS ist, dass es ziemlich unsozial mit dem Speicher
umgeht und man den auch nur im großen Massstab reglementieren kann,
soll heissen, dass der leicht mal einige hundert MB über das Ziel
hinaus schiesst, weil man keine harten Grenzen einstellt, sondern
nur Watermarks, ab derer expired wird.
Die eingestellten Marken sind letzlich auch statisch, d.h. es hat
nicht viel damit zu tun, ob das System RAM anderweitig gebrauchen
könnte oder brach liegt, sondern man gibt ZFS RAM und sollte dem
das tunlichst auch immer mit Reserve zur Verfügung halten.

> Hier zum Beispiel, gerade bei mir (chronologisch):
> kstat.zfs.misc.arcstats.size: 788487520
> kstat.zfs.misc.arcstats.size: 764255592
> kstat.zfs.misc.arcstats.size: 763023408
>
> Bei (Standardeinstellung):
> vfs.zfs.arc_max: 5120782336

Ja, mit sehr viel arc_max greift dann irgendwann eine inzwischen
eingeführte Dynamik, aber man muss wirklich etwas RAM haben, um in
den Genuss zu kommen.

> > Das laesst auch auf Speicherstress schliessen.
>
> Ich würde eher von Netzwerkproblemen ausgehen (ganz ehrlich gesagt;
> irgendwelche Paketfiltereinstellungen? Socket-Timeouts? Seltsame
> Netzwerkkonfigurationen?). Ich würde aber auch auf RELEASE aktualisieren
> (mindestens!). PRERELEASE ist sehr alt und da waren glaube ich noch
> Fehler bezüglich ZFS drin.

Sicherlich keine schlechte Idee.
Gerade wegen der Problematik wird viel am Speichermanagement vom ZFS
rumgedreht und letzlich muss man sagen, dass sich das durchaus verbessert
hat - ideal ist aber was anderes, zum Glück ist das mit der Möglichkeit
ausreichend RAM-Riegel reinzustecken inzwischen bezahlbarer geworden.
Mein erster lokaler ZFS-Server lief mit IIRC 384MB - würde ich bei den
aktuellen Preisen nicht mal mehr ansatzweise in Betracht ziehen, sondern
8GB als Minimum einstufen, auch wenn man auf weniger tunen kann.

> Manche Leute haben auch Probleme gemeldet beim Mischbetrieb von ZFS und
> UFS. Ich kann das bei mir nicht nachvollziehen.

Kommt halt darauf an, wie viel RAM frei verfügbar ist.
Mit 8G kann das Ok sein, wenn man keine fetten Prozesse laufen hat.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message