+1
Jonathan Chew wrote:
Eric Saxe wrote:
Eric Saxe wrote:
Also, in the past I've acted as de facto facilitator for this
community...but we've never had a vote around that (at least not one
that I remember).
Are you interested Krister? If so, I nominate you. :)
Krister has accepted my nomin
Eric Saxe wrote:
Eric Saxe wrote:
Also, in the past I've acted as de facto facilitator for this
community...but we've never had a vote around that (at least not one
that I remember).
Are you interested Krister? If so, I nominate you. :)
Krister has accepted my nomination for community facili
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 available at the time, a working 'wrong'
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 available at the time, a working 'wrong'
> >> solution is better than a non-existant 'right' solution.
> >
> > Why would t
Eric Saxe wrote:
Also, in the past I've acted as de facto facilitator for this
community...but we've never had a vote around that (at least not one
that I remember).
Are you interested Krister? If so, I nominate you. :)
Krister has accepted my nomination for community facilitator. All those
johan...@sun.com wrote:
Folks,
The voting for core contributor grants has been open for a week. At
this point we've received enough votes to proceed.
Here are the renewals:
akolb Core Contributor+1: esaxe, jjc, johansen, mpogue
barts Core Contributor+1: esa
Brian Nitz wrote:
Was this recently ported from Linux?
your best chance to find this out would be to check the PSARC archives, I
think.
btw: it's interesting to note that in the Solaris 7 days there was a period
where top used to be a CPU pig (IIRC) ... it's somehow amusing to see
history
Folks,
The voting for core contributor grants has been open for a week. At
this point we've received enough votes to proceed.
Here are the renewals:
akolb Core Contributor+1: esaxe, jjc, johansen, mpogue
barts Core Contributor+1: esaxe, jjc, johansen, mpogue
Ouch, mistakenly I posted a private response to list.
Worst of it: Most URL's are not yet online.
More infos at a given time in separate announcements.
I apologize to world for this mistake :(
%martin
___
perf-discuss mailing list
perf-discuss@open
> Or using an older version that works. The one
> integrated reports itself as
>
> top: version 3.8beta1
>
> I've never seen a memory leak in any of the other
> versions I've used, which covers 20 years.
Yep, same here.
I've attached a fix for the top 3.8beta1 memory leak to bug 5482,
and I've
>> Bob
>> ==
>> Bob Friesenhahn
>> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Martin Bochnig,
Sun CertifiedSytemAdmin for Solaris 10, 9, 8
Sun CertifiedNetworkAdmin
"some users"?
On Thu, Feb 12, 2009 at 6:23 PM, Bob Friesenhahn
wrote:
> I checked the bug tracker for 'top' and did not see any memory leak bug
> listed so I opened up SourceForge bug ID 2593511 so that the top maintainer
> is aware of the issue.
>
> http://sourceforge.net/tracker/index.php?fun
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)
>>> Sponsoring Communities: sysadmin (that seems to be whe
I checked the bug tracker for 'top' and did not see any memory leak
bug listed so I opened up SourceForge bug ID 2593511 so that the
top maintainer is aware of the issue.
http://sourceforge.net/tracker/index.php?func=detail&aid=2593511&group_id=72892&atid=536042
Please add any additional info
On Thu, Feb 12, 2009 at 4:02 PM, Bob Friesenhahn
wrote:
> As a useful data-point, the 'top' that I use (version 3.7) was compiled from
> source code and does not leak any memory on Solaris 10. Fixing the leak is
> likely as easy as using a more modern version of the software.
Or using an older ve
On Thu, 12 Feb 2009, Brian Nitz wrote:
'pmap -x' may help identify those pieces of memory.
I just had a quick look at this. To be honest, this is the first I'd heard
that top was in opensolaris. I've always used prstat. But yes, top does
leak heap space:
As a useful data-point, the 'to
On Thu, Feb 12, 2009 at 1:06 AM, adrian cockcroft
wrote:
> There is an endless number of free performance monitoring tools, it would
> make more sense to me to build something more portable distributed and high
> level like ganglia or xetoolkit into opensolaris.
Perhaps I didn't look close enough
On 02/12/09 03:47, Michael Schuster wrote:
Martin Bochnig wrote:
I mean, ok: I got used to it, that small daemons like the
network-auto-magic manager can consume 86MB. Also, that small almost
useless little Gnome-applets can consume hundreds of MB's (wnck-applet
104MB, clock-applet 80MB, mixer-
On Thu 12 Feb 2009 at 09:12AM, Peter Tribble wrote:
> On Thu, Feb 12, 2009 at 3:05 AM, Bob Friesenhahn
> wrote:
> > On Thu, 12 Feb 2009, Martin Bochnig wrote:
> >>
> >> So, one day later they had grown further, but here comes the absolute
> >> HAMMER: One top process was at 1340MB!!!
> >
> > Your
On Thu, Feb 12, 2009 at 3:05 AM, Bob Friesenhahn
wrote:
> On Thu, 12 Feb 2009, Martin Bochnig wrote:
>>
>> So, one day later they had grown further, but here comes the absolute
>> HAMMER: One top process was at 1340MB!!!
>
> Your 'top' program obviously has some sort of bug
That would be bug 6777
>Does this explain why a wget process grew to 2.2GB (where I killed it) ??
>Then wget must have exactly the same bug, which is unlikely. Therefore
>the bug must be in a shared lib which both use. This suggests (but is
>not limited to) libc.
Run them with libumem and start them with UMEM_DEBUG set
21 matches
Mail list logo
