you're looking at threads. they aren't really taking up 16m x 4 of memory...
try enabling nptl, and re-emerging glibcIf your going that route (which i highly recommend) rebuild w/ nptl and nptlonly.thanks, joshua
Bruno Lustosa wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
19199 isabel.s 15 0 511m 204m 16m S 0.0 27.2 7:49.58 firefox-bin
19263 isabel.s 16 0 511m 204m 16m S 0.0 27.2 0:00.00 firefox-bin
19264 isabel.s 16 0 511m 204m 16m S 0.0 27.2 0:02.13
Bruno Lustosa wrote:
Yes, but what caught my eyes was not the virtual address space. The
resident portion (i.e., what is really allocated on real memory) is
huge for that first instance. 204mb is way too much for a firefox with
4 tabs open.
I'm not so sure that the resident memory number ca
On Wednesday 19 October 2005 15:57, Bruno Lustosa wrote:
> I can't understand how firefox evolved from small and fast phoenix to this
> memory hungry beast that has a virtual space of half a gigabyte.
Google for "firefox memory leak"
--
Mike Williams
--
gentoo-user@gentoo.org mailing list
On 10/19/05, Hans-Werner Hilse <[EMAIL PROTECTED]> wrote:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND> 19328 isabel.s 15 0 511m 204m 16m S 0.0 27.2 0:02.47 firefox-bin> [x4]> 22668 lustosa 15 0 129m 97m 17m S 0.0 13.0 11:50.05 firefox-bin> [x2]
Hm, on the hand: yes, it _is_ memory hungr
Hi,
On Wed, 19 Oct 2005 12:57:02 -0200
Bruno Lustosa <[EMAIL PROTECTED]> wrote:
> Just had a look at 'top' here, and was astonished by its output:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 19328 isabel.s 15 0 511m 204m 16m S 0.0 27.2 0:02.47 firefox-bin
> [x4]
> 22668 lustosa 1
Just had a look at 'top' here, and was astonished by its output:
PID USER PR NI
VIRT RES SHR S %CPU %MEM TIME+
COMMAND
19199 isabel.s 15 0 511m 204m 16m S 0.0 27.2 7:49.58 firefox-bin
19263 isabel.s 16 0 511m 204m 16m S 0.0 27.2 0:00.00 firefox-bin
19264 isabel.s 16
7 matches
Mail list logo