Re: ZFS Cache

On Tue, Jun 29, 2010 at 12:50:38PM +0200, Alvar Freude wrote:
> Hi,
>
> -- Bernd Walter <ticso(at)cicely7.cicely.de> wrote:
>
> >Damit wird der zwischen 1,6G und 200M hin und her pendeln.
> >D.h. sobald der über 1,6G ist wird der auf 200M runter-expiren.
>
> das habe ich mir fast gedacht -- allerdings steht er meist mer oder
> minder stabil bei ca. 1,4.
>
>
> >Damit passt auch deine 500MB MySQL Datei nicht immer rein.
>
> in der Tat, von den anderen (deutlich größeren) Tabellen ganz zu
> schweigen -- aber darum hatte ich das ja mit der 50 MB Datei gemacht,
> gleiches Verhalten.
>
> Und auch bei "echten" MySQL-Lese-Zugriffen, die wiederholt die gleichen
> Datensätze aus der Tabelle einlesen.
>
>
> >Mit MySQL solltest du eh die Blocksize vom Filesystem auf 4k setzen.
>
> ja, das ist aber nochmal was anderes ;) und dann muss ich auch die
> Kompression ausschalten.

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

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

Sehr weise :-)

> >>Auch nach mehrfachem Lesen einer 50 MB-Datei wird diese nicht gecacht.
> >
> >Möglich - der führt Statistiken und wenn der andere Daten als
> >wahrscheinlicher einstuft, dann wird der auch das nicht cachen.
>
> das war meine Vermutung -- aber nach mehrfachem Lesen sollte er es ja mal
> langsam anders einstufen ... ;)
>
> 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,
zumal der besagte Rechner nicht mehr in Betrieb ist und mein heimischer
parallel ja auch den Level-2 Cache füllt, sodass der mitunter was
kompensieren könnte.

> >>Es wundert mich, warum auch nach mehrfachem Lesen das ZFS die Datei
> >>nicht in den Cache packt; immerhin ist ja noch was frei.
> >>
> >>Und: Warum wird der Maximalwert für ARC auf nur ca. 1.6 GB gesetzt,
> >>ist es sinnvoll den in /boot/loader.conf hochzusetzen? Der FreeBSD
> >>ZFS Tuning Guide sagt, unter AMD64 bräuchte man nichts machen.
> >>Ich denke ich könnte nochmal 1 bis 1.5 GB zusätzlich für den Cache
> >>nutzen.
> >
> >Ich habe meinen Fileserver mit 8G RAM auf 3G/4G ARC eingestellt.
>
> 3GB Ziel, 4GB Max?

Ja.

> Das muss in /boot/loader.conf, oder?

Ja.

> vfs.zfs.arc_max setzt das Maximum, und vfs.zfs.arc_min das Minimum --
> aber die "Target Size" kann man nicht setzen?

Target Size?
Keine Ahung - ich habe das immer als Watermarks verstanden.

> Hier sind auch ein paar Tuning-Vorschläge, aber zu den Einträgen findet
> sich insgesamt kaum Doku:
>
> <http://submesa.com/data/bsd/setup>
>
>
> Was macht zum Beispiel vfs.zfs.arc_meta_limit?
>
> 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.

> >Udn zusätzlich noch Flash-Laufwerke für Level-2 Caching, wobei dort
> >nur Daten landen, die vorher als Random eingestuft wurden.
>
> solange der Rest läuft und ich sonst keine Performance-Probleme bekomme
> ... ;)
>
>
> >MySQL könnte davon aber gut profitieren.
>
> das fliegt eh bald mehr oder minder raus. ;-)
>
> Aber vom Prinzip her ist es bei Postgres ja ähnlich.

Ja - gleiches Grundproblem, nur dass Postgres _richtig_ arbeitet und
eine Bestätigung bis zur Platte haben will.
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.
MySQL hat ja eher die Tendenz nach einen power-loss mal nicht mehr hoch
zu kommen, weil es lieber nicht auf Platten wartet.

> >Als Level-2 kann man billige MLC-SSD Laufwerke benutzen, weil es nur
> >auf random read und sequentiel-write ankommt, aber nicht auf randowm
> >write oder hohe Zuverlässigkeit.
> >Wichtiger ist hier die Kapazität.
>
> habe gelesen, dass man auch fürs ZIL eine SSD nutzen soll; aber auch das
> ist bei mir erstmal nicht relevant ...

Möglich - aber Postgres macht auf dem ZIL mehr Last.
Und wie ich oben schrieb: Für ZIL braucht man andere Eigenschaften.
Dafür braucht ZIL zum Glück aber nicht viel Platz.
Ein ZIL-Laufwerk kann man leider auch nicht mehr dekonfigurieren.
AFAIK im aktuellen ZFS, aber noch nicht mit dem in FreeBSD.

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

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