[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