Re: ZFS Cache

Hi,

-- Bernd Walter <ticso(at)cicely7.cicely.de> wrote:

> Ist was anderes - compression bin ich mir nicht sicher, ob das
> wirklich schaded.

bei PostgreSQL hatte ich es wenn ich mich recht erinnere mal getestet, da
war es mit Kompression schneller, sicherlich weil sie da auch gut greift:
Faktor 2.36 oder so bei meinen derzeitigen Daten. Bei bei den jetzigen
MySQL-Test-Daten nur Faktor 1.63.

Aber mit Kompression braucht er eine variable Blockgröße, sofern ich
das richtig verstanden habe.

>> MySQL ist da eh nur eine Übergangslösung weil Altlast, das Zeug wird
>> alles auf PostgreSQL migriert.
>
> Sehr weise :-)

:)

Ich war ja schon am Schimpfen auf MySQL, bis ich merkte dass es am ZFS
liegt. Aber es gibt noch genug anderes zu meckern an dem Ding ;)

>> Kann es auch sein, dass aufgrund der Laufzeit (128 Tage) sich da
>> intern Daten quasi festgesetzt haben, die zum Beispiel einmal am Tag
>> eingelesen werden (und damit nicht wirklich zeitkritisch sind)?
>
> Ich denke das kommt durchaus vor.
> Ich hatte in den frühen ZFS-Tagen einen MySQL Server, der wirklich
> einmal pro Monat rebootet werden musste, sonst frass der sich mit
> Platten-IO richtig fest.
> Inwieweit das inzwischen ein Problem ist kann ich nicht sagen,

Habe nun mal alle jails gestoppt und die dazugehörigen ZFS Mountpoints
ausgehängt. Nun sind es nur noch 400 MB ARC Cache. Aber die 50 MB Datei
will er immer noch nicht cachen ;)

>> > Ich habe meinen Fileserver mit 8G RAM auf 3G/4G ARC eingestellt.
>>
>> 3GB Ziel, 4GB Max?
>
> Ja.

ich denke, ich mache dann mal 2GB Ziel, 3 GB max.

>> Bei mir steht es auf:
>> vfs.zfs.arc_meta_limit: 432312320
>> vfs.zfs.arc_meta_used: 1124905688
>
> Das hat was mit der Anzahl der gecachten Metadaten zu tun.
> Details kenne ich nicht, aber viele Metadaten hast du tendenziel eher
> wenn du auf viele verschiedene Dateien zugreifen willst.

Die Frage wäre, ob da auch was anzupassen wäre.

Nach dem Unmount/remount steht es bei mir auf:

  vfs.zfs.arc_meta_limit: 432312320
  vfs.zfs.arc_meta_used: 210102192

Damit wieder unter dem Limit; vorher war es deutlich über dem Limit ...

Nachts läuft immer ein find aus /etc/periodic/security/100.chksetuid --
und wie mir scheint auch noch in jedem Jail; zumindest letzteres wollte
ich mal abstellen, da das für die Zeit die Platten-Performance drastisch
in den Keller zieht, da die doch ziemlich parallel laufen.

> Ja - gleiches Grundproblem, nur dass Postgres _richtig_ arbeitet und
> eine Bestätigung bis zur Platte haben will.

ja, wenn fsync an ist (was bei mir der Fall ist).

Vermutlich kann man sich das mit ZFS dank Copy-on-Write insofern sparen,
dass zumindest nichts "richtig" kaputt geht, außer dass einzelne
Datensätze nicht geschrieben sind.

> Das sorgt dafür, dass ZFS nicht mehr so intensiv beim schreiben cachen
> kann, bzw ZFS cached trotzdem aber notiert sich das im ZIL, was dort
> für mehr Last sorgt - ein extra ZIL Laufwerk sollte aber ein schnelles
> sein - also teures (kleines) SLC Flash-Laufwerk oder eine hoch drehende
> Festplatte.

ja, das hatte ich so auch gelesen. Vermutung: evtl. wäre es sogar
sinnvoll, das WAL auf eine UFS-Partition zu packen.

> MySQL hat ja eher die Tendenz nach einen power-loss mal nicht mehr hoch
> zu kommen, weil es lieber nicht auf Platten wartet.

;-/

>> >> Wie läuft das Speicher-Handling, wenn aber doch mal die laufenden
>> >> Prozesse 1.5 GB mehr brauchen? Normalerweise würde dann ja der
>> >> Cache freigegeben werden, klappt das auch mit ZFS sauber?
>> >
>> > Leider nein - ein riesen Nachteil des Konzeptes :(
>> > Keine Ahnung wie da der Entwicklungsstand ist.
>>
>> Aber wenn er von alleine runter geht gibt er es schon frei, oder?
>
> Dann schon, aber der geht ja nicht runter wenn andere den Speicher
> besser gebrauchen können - im Gegensatz zum caching bei UFS.

Ist das ein FreeBSD-spezifisches Problem? Denn eigentlich ist das ja in
den meisten Fällen eher ungeschickt.

Ciao
  Alvar

-- 
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.assoziations-blaster.de/
** http://www.wen-waehlen.de/
** http://www.perl-blog.de/

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 29 Jun 2010 - 15:14:24 CEST