On Thu, Sep 16, 2010 at 12:46 PM, Louis Munro wrote:
> Hi,
> I'm trying to understand the relationship between semaphores, semaphore sets
> and the relevant resource controls in solaris 10.
>
> My current understanding is that the total number of semaphores available to
> a project is the produc
t and guarantee your seat to this year's event!
--
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241
___
perf-discuss mailing list
perf-discuss@opensolaris.org
your seat to this year's event!
http://omniti.com/surge/2010/register
Thanks,
--
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241
___
perf-discuss mailing list
perf-discuss@opensolaris.org
your business sponsor/exhibit at Surge 2010, please contact us at
su...@omniti.com.
Thanks!
--
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241
___
perf-discuss mailing list
perf-discuss@opensolaris.org
icipating as an exhibitor, please
visit the Surge website or contact us at su...@omniti.com.
Thanks,
--
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241
___
perf-discuss mailing list
perf-discuss@opensolaris.org
n
Surge is just what you've been waiting for. For more information,
including CFP, sponsorship of the event, or participating as an
exhibitor, please contact us at su...@omniti.com.
Thanks,
--
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.co
On Wed, Sep 16, 2009 at 6:19 PM, John Levon wrote:
> On Tue, Sep 15, 2009 at 11:46:55PM -0500, Jason King wrote:
>
>> Being distracted by other things for the past few months, I'd like to
>> get moving on this again and try to get it knocked out.
>>
>> To recap,
On Wed, Sep 16, 2009 at 5:18 PM, Peter Tribble wrote:
> On Wed, Sep 16, 2009 at 5:46 AM, Jason King wrote:
>> Being distracted by other things for the past few months, I'd like to
>> get moving on this again and try to get it knocked out.
>>
>> To recap, the idea
Being distracted by other things for the past few months, I'd like to
get moving on this again and try to get it knocked out.
To recap, the idea is to associate stability levels to kstats
analogous to the stability levels assigned to dtrace probes.
Defined stability levels:
KSTAT_STABILITY_PR
On Thu, Apr 16, 2009 at 4:07 PM, Peter Tribble wrote:
> On Tue, Apr 7, 2009 at 8:25 PM, Jason King wrote:
>> To get around the hurdle of all kstats being effectively private,
>> which in turn makes it difficult to effectively build any sort of
>> tools that use them,
&g
On Thu, Apr 16, 2009 at 4:07 PM, Peter Tribble wrote:
> On Tue, Apr 7, 2009 at 8:25 PM, Jason King wrote:
>> To get around the hurdle of all kstats being effectively private,
>> which in turn makes it difficult to effectively build any sort of
>> tools that use them,
&g
Responses inline :)
On Wed, Apr 15, 2009 at 11:22 PM, Erik O'Shaughnessy
wrote:
> Jason,
>
> I am interested in this happening, so I thought I would at least comment.
>
> Some of my questions are more implementation detail specific, but I hope
> they should incite some
On Tue, Apr 7, 2009 at 5:09 PM, Dan Price wrote:
> On Tue 07 Apr 2009 at 02:25PM, Jason King wrote:
>> To get around the hurdle of all kstats being effectively private,
>> which in turn makes it difficult to effectively build any sort of
>> tools that use them, I'm
To get around the hurdle of all kstats being effectively private,
which in turn makes it difficult to effectively build any sort of
tools that use them, I'm proposing adding stability attributes to
kstats, similar to how dtrace providers have stability attributes. (I
believe this was originally su
On Fri, Feb 20, 2009 at 2:10 PM, Peter Tribble wrote:
> On Wed, Feb 4, 2009 at 8:22 AM, adrian cockcroft
> wrote:
>>
>> Don't write yet another performance stats collector / plotter, its been done
>> to death.
>
> It may have been done to death; has it been done properly?
>
> I've been playing wi
On Fri, Feb 13, 2009 at 3:45 PM, Dan Price wrote:
> On Fri 13 Feb 2009 at 03:32PM, Jason King wrote:
>>
>> I would like the think that, all the (summarized) 'never use any
>> kstats -- those are private' emails I'm getting off list, as well as
>> past rea
On Fri, Feb 13, 2009 at 4:49 PM, Dan Price wrote:
> On Fri 13 Feb 2009 at 04:28PM, Jason King wrote:
>> getting it working), me and Steven Stallion were told it will _never_
>> be putback into any Opensolaris consolidation, even if it were perfect
>> in every possible way (
On Fri, Feb 13, 2009 at 3:45 PM, Dan Price wrote:
> On Fri 13 Feb 2009 at 03:32PM, Jason King wrote:
>>
>> I would like the think that, all the (summarized) 'never use any
>> kstats -- those are private' emails I'm getting off list, as well as
>> past rea
On Fri, Feb 13, 2009 at 3:53 PM, Richard Lowe wrote:
> Jason King writes:
>
>> On Fri, Feb 13, 2009 at 3:12 PM, Brendan Gregg - Sun Microsystems
>> wrote:
>>> On Fri, Feb 13, 2009 at 08:09:52PM +, Peter Tribble wrote:
>>>> On Fri, Feb 13, 2009 at 12:
On Fri, Feb 13, 2009 at 3:12 PM, Brendan Gregg - Sun Microsystems
wrote:
> On Fri, Feb 13, 2009 at 08:09:52PM +, Peter Tribble wrote:
>> On Fri, Feb 13, 2009 at 12:26 AM, Brendan Gregg - Sun Microsystems
>> wrote:
>> >
>> > No. Stop. Do not assume any data is better than no data. Wrong or
On Fri, Feb 13, 2009 at 2:48 PM, David Collier-Brown wrote:
> I'll see you on the list (;-))
>
> Back when I was full-time (I'm a contractor
> who does capacity planning), I was part of the
> ABI team, who managed the stable/unstable
> interfaces, so as not to suffer "dll hell"
> like some other
On Fri, Feb 13, 2009 at 12:09 PM, David Collier-Brown wrote:
> Brendan Gregg wrote:
>> No. Stop. Do not assume any data is better than no data. Wrong
>> or misleading data is *worse* than no data.
>
> I agree most emphatically. Most metrics recorded by programs
> are those needed by the autho
On Thu, Feb 12, 2009 at 6:26 PM, Brendan Gregg - Sun Microsystems
wrote:
> On Wed, Feb 11, 2009 at 05:32:37PM -0600, Jason King wrote:
>> On Wed, Feb 11, 2009 at 4:33 PM, Brendan Gregg - Sun Microsystems
>> wrote:
> [..]
>> >> However if that's all that's
On Tue, Feb 10, 2009 at 1:10 PM, Peter Tribble wrote:
> On Tue, Feb 10, 2009 at 5:38 PM, Jason King wrote:
>>
>>> See if this sounds good:
>>>
>>> Project Leaders: Jason King (if anyone else would like to join up, I'd
>>> be happy to add)
>
worse (one in particular would force
itself to always run in the RT scheduling class!). Don't
underestimate the amount of administrative overhead that can generate.
SMA is supposedly the snmp solution for Opensolaris, let's stop
treating it like a third-class citizen.
>
> Adrian
>
On Wed, Feb 11, 2009 at 9:37 PM, Jason King wrote:
> On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig wrote:
>> Hi!
>>
>> On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
>> wrote:
>>
>>> Your 'top' program obviously has some sort of bug but o
On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig wrote:
> Hi!
>
> On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
> wrote:
>
>> Your 'top' program obviously has some sort of bug but otherwise I don't see
>> anything necessarily out of the ordinary in the top listings.
>
>
> Does this explain why
On Wed, Feb 11, 2009 at 4:33 PM, Brendan Gregg - Sun Microsystems
wrote:
> On Tue, Feb 10, 2009 at 11:56:10PM -0600, Jason King wrote:
>> On Tue, Feb 10, 2009 at 11:08 PM, Brendan Gregg - Sun Microsystems
>> wrote:
>> > G'Day Folks,
>> >
>> >
On Tue, Feb 10, 2009 at 11:08 PM, Brendan Gregg - Sun Microsystems
wrote:
> G'Day Folks,
>
> On Tue, Feb 10, 2009 at 08:03:17PM +, Peter Tribble wrote:
> [...]
>> Create a net-snmp module that exposes well known Solaris performance
>> metrics via SNMP. If possible, this will include presentin
On Tue, Feb 10, 2009 at 10:28 PM, Dale Ghent wrote:
> On Feb 10, 2009, at 11:22 PM, Jason King wrote:
>
>
> Quite reasonable. This is a great idea, Jason. I just love telemetry and
> this is a great idea.
>
> One thing to note, there's a RFE and (maybe? I think?) an ass
On Tue, Feb 10, 2009 at 5:37 PM, Dale Ghent wrote:
> On Feb 10, 2009, at 3:03 PM, Peter Tribble wrote:
>
>>
>> Create a net-snmp module that exposes well known Solaris performance
>> metrics via SNMP. If possible, this will include presenting kstat
>> metrics in a generic fashion via SNMP.
>
> +
t)
>
> Sponsoring Communities:
>
> Systems Administration Community Group
>
> Project Leaders:
>
> Jason King (jbk)
>
> Description:
>
> Create a net-snmp module that exposes well known Solaris performance
> metrics via SNMP. If possible, this will include pre
On Mon, Feb 9, 2009 at 12:59 PM, Jason King wrote:
> On Sun, Feb 8, 2009 at 3:59 PM, Peter Tribble wrote:
>> On Sun, Feb 8, 2009 at 12:33 PM, Octave Orgeron
>> wrote:
>>> I think this would make a great project as monitoring for Solaris has
>>> pretty much be
On Mon, Feb 9, 2009 at 1:42 PM, Ben Rockwood wrote:
> Octave Orgeron wrote:
>> What I meant what the such things have been left to 3rd party tools and
>> products by Sun. That should change. Monitoring and administrative tools are
>> essential and should be robust out of the box.
>>
>
> I know w
ve support from 3 CCs in sysadmin, so if
> Jason can put together all the information required by the project
> instantation
> process we can have a formal vote and get this thing underway.
>
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot
On Sat, Feb 7, 2009 at 3:20 PM, Peter Tribble wrote:
> On Fri, Feb 6, 2009 at 8:30 PM, Ben Rockwood wrote:
>> Jason King wrote:
>>> Doing some more digging, it appears that the number of performance
>>> metrics that can be viewed via SNMP on OpenSolaris is minimal. I
Doing some more digging, it appears that the number of performance
metrics that can be viewed via SNMP on OpenSolaris is minimal. I am
proposing a project that will enhance the number of metrics available
via SNMP. Since SNMP is fairly widespread, it allows one to avoid the
whole collector/record
death.
>
> Adrian
>
> On Tue, Feb 3, 2009 at 7:57 PM, rickey c weisner
> wrote:
>>
>> Jason,
>> I have my own home grown script. It is named data_collector which
>> is a ksh script controlled by an configuration file. It runs
>> various stat tools pl
I'm curious if anyone has experiences with tools that will all you to
store (and later view) historic performance data. Right now sar seems
to be it. I was thinking about throwing together some scripts using
kstat + rrdtool, but wanted to see if anyone's found anything better,
or if this might be
On Fri, Jan 30, 2009 at 2:49 PM, Elad Lahav wrote:
>> Getting back to the original problem, I'm wondering if a more detailed
>> explanation of what is trying to be measured and why might help. Is it
>> crypto performance (in which case, the crypto apis might be useful to
>> look at), or something
On Fri, Jan 30, 2009 at 2:21 PM, Darryl Gove wrote:
>
>
> On 01/30/09 12:10 PM, Elad Lahav wrote:
>>> I think the point was that with 64-bit ints you might be able to use a
>>> different algorithm, or perhaps require fewer iterations and converge
>>> faster.
>> I guess that part of the answer is t
On Fri, Jan 30, 2009 at 11:20 AM, Darryl Gove wrote:
> Hi,
>
> 64-big gives you a larger address space. The downside of this is that
> pointers and longs go from 32-bits to 64-bits. This results in a slight
> drop in performance.
>
> So in general you should probably expect a 64-bit application to
We have a third party library (which we do not have the source for), that calls
getpid() everytime it logs something. Unfortunately, in the application where
the library is being used, this results in over 4000 getpid calls/sec
(accounting for over half the total system calls/sec being made by
43 matches
Mail list logo
