Nathan Kroenert
2007-Nov-08 21:21 UTC
[zfs-discuss] mdb ::memstat including zfs buffer details?
Hey all - Just a quick one... Is there any plan to update the mdb ::memstat dcmd to present ZFS buffers as part of the summary? At present, we get something like: > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 28859 112 13% Anon 34230 133 15% Exec and libs 10305 40 5% Page cache 16876 65 8% Free (cachelist) 26145 102 12% Free (freelist) 105176 410 47% Balloon 0 0 0% Total 221591 865 Which just (as far as I can tell) includes the zfs buffers in Kernel memory. And what I''d really like is: > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 28859 112 13% Anon 34230 133 15% Exec and libs 10305 40 5% Page cache 16876 65 8% Free (cachelist) 26145 102 12% Free (zfscachelist) 1827346 1700 xx% Free (freelist) 105176 410 47% Balloon 0 0 0% Total 221591 865 Which then represents the pages that *could* be freed up by ZFS in the event that they are needed for other purposes... Any thoughts on this? Is there a great reason why we cannot do this? Also - Other utilities like vmstat, etc that print out memory... Thoughts on those guys and the way they treat the ufs buffers versus the zfs buffers? Cheers! Nathan.
I''m not aware of any plans to do this. If you''re on S10U4 or NV, can use kstat to fetch arcstats on ZFS memory usage: kstat -n arcstats. Prior to the addition of arcstats, you needed to use mdb to determine how much memory ZFS was using...> Which just (as far as I can tell) includes the zfs buffers in Kernel memory. >That''s correct. The ZFS ARC will show up in "Kernel".> Any thoughts on this? Is there a great reason why we cannot do this? >Anything is possible is software. It''s a time and resources issue (as always - what do we not work on to get this done...)> Also - Other utilities like vmstat, etc that print out memory... > > Thoughts on those guys and the way they treat the ufs buffers versus the > zfs buffers? >I don''t understand this part of your question.... Thanks, /jim> Cheers! > > Nathan. > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Jonathan Adams
2007-Nov-12 20:42 UTC
[zfs-discuss] mdb ::memstat including zfs buffer details?
On Nov 8, 2007 4:21 PM, Nathan Kroenert <Nathan.Kroenert at sun.com> wrote:> Hey all - > > Just a quick one... > > Is there any plan to update the mdb ::memstat dcmd to present ZFS > buffers as part of the summary? > > At present, we get something like: > > ::memstat > Page Summary Pages MB %Tot > ------------ ---------------- ---------------- ---- > Kernel 28859 112 13% > Anon 34230 133 15% > Exec and libs 10305 40 5% > Page cache 16876 65 8% > Free (cachelist) 26145 102 12% > Free (freelist) 105176 410 47% > Balloon 0 0 0% > > Total 221591 865 > > Which just (as far as I can tell) includes the zfs buffers in Kernel > memory. > > And what I''d really like is: > > > ::memstat > Page Summary Pages MB %Tot > ------------ ---------------- ---------------- ---- > Kernel 28859 112 13% > Anon 34230 133 15% > Exec and libs 10305 40 5% > Page cache 16876 65 8% > Free (cachelist) 26145 102 12% > Free (zfscachelist) 1827346 1700 xx% > Free (freelist) 105176 410 47% > Balloon 0 0 0% > > Total 221591 865 > > Which then represents the pages that *could* be freed up by ZFS in the > event that they are needed for other purposes... > > Any thoughts on this? Is there a great reason why we cannot do this? > > Also - Other utilities like vmstat, etc that print out memory...File an RFE. I don''t think it should be too bad (for ::memstat), given that (at least in Nevada), all of the ZFS caching data belongs to the "zvp" vnode, instead of "kvp". The work that made that change was: 4894692 caching data in heap inflates crash dump Of course, this so-called "free" memory does act a bit differently than the cachelist, etc., so maybe it should be named slightly differently. Cheers, - jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20071112/b00445ac/attachment.html>
johansen at sun.com
2007-Nov-12 21:16 UTC
[zfs-discuss] mdb ::memstat including zfs buffer details?
> I don''t think it should be too bad (for ::memstat), given that (at > least in Nevada), all of the ZFS caching data belongs to the "zvp" > vnode, instead of "kvp".ZFS data buffers are attached to zvp; however, we still keep metadata in the crashdump. At least right now, this means that cached ZFS metadata has kvp as its vnode. -j
Jonathan Adams
2007-Nov-12 21:25 UTC
[zfs-discuss] mdb ::memstat including zfs buffer details?
On Nov 12, 2007 4:16 PM, <johansen at sun.com> wrote:> > I don''t think it should be too bad (for ::memstat), given that (at > > least in Nevada), all of the ZFS caching data belongs to the "zvp" > > vnode, instead of "kvp". > > ZFS data buffers are attached to zvp; however, we still keep metadata in > the crashdump. At least right now, this means that cached ZFS metadata > has kvp as its vnode. > >Still, it''s better than what you get currently. Cheers, - jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20071112/a57e8f04/attachment.html>
johansen at sun.com
2007-Nov-12 21:46 UTC
[zfs-discuss] mdb ::memstat including zfs buffer details?
> ZFS data buffers are attached to zvp; however, we still keep > metadata in the crashdump. At least right now, this means that > cached ZFS metadata has kvp as its vnode. > > Still, it''s better than what you get currently.I absolutely agree. At one point, we discussed adding another vp for the metadata. IIRC, this was in the context of moving all of ZFS''s allocations outside of the cage. There''s no reason why you couldn''t do the same to make counting of buffers more understandable, though. -j