Re: tar und senden via ssh schlaegt fail

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.

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

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.

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

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

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

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

Es gruesst
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 27 Jun 2011 - 05:56:18 CEST