On Sun, Feb 8, 2009 at 4:11 AM, Ben Rockwood <benr at cuddletech.com> wrote:
> I'm generally happy with the zone level kstat data available today. I > think that maintaining the kind of granular data your talking about via > kstats is excessive... but I'd be interested in other opinions. > I agree with Ben here, yes all the information in kstat is nice, but we do have a problem with growing kstat, I'm not an experpert machine language developer but here is my guess to what we will run into, yes the CPU and compiler can hide away the increment of a memory location using spare cycles, but thanks to Solaris wider CPU support gone are the days where all huge CPU caches, the typical x86 cpu has 512KB of cache, and every time we increment a kstat counter we muddy the cache lines, so eventually we could end up with 1000's of counters each using at lest 4bytes in l1 and l2 cache doing nothing more than counting things that most people won' t even look at slowing down the systems. I think new counters shouldn't be implemented unless the OS it self can use them to better tune it self gaining performance. Otherwise the user can just watch what ever they need to using dtrace without the permanent cost of built in kstat growth. > > Using the existing kstats in conjunction with a process that "rolls up" > daily extended accounting data would allow me to see not just how much CPU > and memory a zone is using, but what processes they are most actively > running... a historical top 10 workloads by day, etc. That could be handy. > yes that would be nice. James Dickens uadmin.blogspot.com > > One thing that does bug me is that quantifying how much performance impact > exacct has is very hard to determine. I'd like more research there. (The > same goes for BSM actually.) > > > As for improving the visability into sys%, I totally agree. As the Solaris > kernel gets more and more complex I think we're all seeing a lot more system > time on our production systems and quantifying what that is, even with > DTrace, is very complex. > > benr. > -- > This message posted from opensolaris.org > _______________________________________________ > observability-discuss mailing list > observability-discuss at opensolaris.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/observability-discuss/attachments/20090208/760c212f/attachment.html>
