[BSD] Wired leak
Robert BARABAS
dc at ktk.bme.hu
2009. Dec. 29., K, 06:10:46 CET
Hello,
> vfs.zfs.arc_min: 50331648
> vfs.zfs.arc_max: 536870912
> kstat.zfs.misc.arcstats.c_min: 50331648
> kstat.zfs.misc.arcstats.c_max: 536870912
> kstat.zfs.misc.arcstats.size: 1403697152
>
> Tehát a ZFS ARC minimum az 48M, a maximum pedig 512M, az aktuális méret
> pedig mintha 1.4G lenne... tippem szerint az előző héten vasárnap illetve
> a mostani héten vasárnap látható wired növekedést okozhatja az, hogy az
> ARC messze többet használ, mint ami meg van neki engedve, és ettől
> függetlenül úgy tűnik, hogy a ZFS nem használ cache-t, ami magyarázhatja a
> gyenge teljesítményt...
Nekem ugy tunik (a cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c alapjan)
hogy a vfs.zfs.arc_{min,max} csupan tunable parameterek amik alapjan
beallitodik egy high illetve low watermark (lasd arc_c_min, arc_c_max es
arc_stats struktura). Ezek alapjan probalgat shrink-elni az
arc_reclaim_thread. Az mar mas kerdes hogy sikerrel jar-e... A fentiek alapjan
nem tunik ugy. Lehet hogy pont a reclaim thread okozza a CPU load-ot (system)?
Azt is erdemes eszben tartani a fenti osszehasonlitasban hogy a kommentek
szerint (buffer allapotok leirasa korul keresd arc arc.c-ben) az
arc_stats.size-ba is beleszamit mindenfele foldi jo (ezeknek a buffereknek
meretet egyebkent az arc_space_consume() adja hozza atomi muvelettel az
arc_size-hoz). Roviden: csatlakozom az elottem szolokhoz, frissits amint
lehetoseged nyilik ra.
Udv
DC
--------- következő rész ---------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://datacast.hu/pipermail/bsd/attachments/20091229/25ed755e/attachment.pgp>
További információk a(z) BSD levelezőlistáról