Re: tar und senden via ssh schlaegt fail

On Mon, Jun 27, 2011 at 01:56:14PM +1000, Peter Ross wrote:
> Quoting "Bernd Walter" <ticso(at)cicely7.cicely.de>:
>
> >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?
>
> >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 hundertt 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.
>
> Das Problem scheint zu sein, dass diese "Reserve" unbegrenzt sein
> muss, um solide zu laufen, um es mal etwas polemisch auszudruecken.
> Was mit der Realitaet des endlichen RAM zwangsweise kollidiert.

Ja, leider, wobei die Wahrscheinlichkeit mit steigender Größe
der Reserve abfällt und irgendwann (leider unberechenbar) sich
doch irgendwie ein Maxiumum einstellt.

> Ich habe festgestellt, dass ich bei Kopieraktionen via ssh/scp bei
> Groessenordnungen von einigen Gigabyte "zuverleassig" den ARC
> auffuelle, und dann irgendwann diese Fehlermeldung bekomme.
>
> Allerdings kann der Fehler auch schon _vor_ dem Erreichen des Maximums
> auftreten, und ein Kopiervorganmg bricht nicht zwangslaeufig mit dem
> Erreichen des Maximums sofort ab, sondern nur "irgendwann" in den
> nachfolgenden Minuten.
>
> Dabei sind "im Restsystem" nach Ausgaben von top und vmstat noch 2.7GB
> frei..

Es geht nicht um freies RAM alleine, sondern um freies kmem plus RAM.

> Ich kann dann auch das System fuer zwei Stunden alleine lassen, ARC
> gibt keinen Speicher mehr her. Lediglich ein Zerstoeren des
> ZFS-Filesystems via ZFS destroy (es ist ein klon eines Snapshots) gibt
> den Speicher, den diese Kopieraktionen belegt haben, wieder frei.

Es hat keine bessere Verwendung dafür - das andere Stellen im System
damit was anfangen könnten interessiert ZFS nicht.

> Das ist natuerlich aeusserst unsozial. Ich wundere mich sehr, dass ARC
> keinerlei Anstrengungen unternimmt, lange nicht benutzten Filebuffer
> wieder zurueckzugeben.

Ja, dass ist ziemlich doof.

> Ist das wirklich so beabsichtigt, oder ein Fehler durch die Portierung
> von Solaris?

Scheinbar - auch bei Solaris wird einem viel RAM nahegelegt.
Sicherlich ist die Interagtion bei FreeBSD etwas problematisch, weil
Daten teilweise doppelt gepuffert werden, einmal im ARC und einmal
zur vnode, aber ARC wäre denoch masslos.

> Das angewandte Tar ist uebrigens unwesentlich, selbst ein simples scp
> grosser Files fuehrt zum gleichen Ergebnis.

Ist das eine amd64?
Eine i386 für alle Anwendungsfälle stabil zu bekommen ist schwer.

> Ich frage mich, wie ich das Auftreten des Write-Errors eingrenzen
> kann, welche Statistiken hilfreich sein koennten etc. Ich habe
> inzwischen alles "Wichtige" auf eine Zwillingsmaschine geschoben, so
> dass ich mit einer Dell-Maschine temporaer alles Moegliche machen
> kann, inklusive Reboots etc., ohne den Alltagsbetrieb zu stoeren.
>
> Ich hatte ja einen aehnlich gelagerten Fall mit einer Dell-Machine und
> bge(4) erwaehnt, der "Betroffene" hat damals keine Loesung gefunden
> und am Ende Citrix installiert. Das wuerde ich gern vermeiden..

Naja, wenn etwas anderes ein Speicherleck hat, dann wird dem System
natürlich zwangsläufig die Luft ausgehen, ob mit oder ohne ARC.
vmstat -m liefert die Info darüber wer Speicher belegt.
ZFS handelt (wegen Wrapperfunktionen) fast alles unter "solaris" ab.

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