| 1 |
On 10/19/05, Hans-Werner Hilse <hilse@×××.de> wrote: |
| 2 |
> |
| 3 |
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
| 4 |
> > 19328 isabel.s 15 0 511m 204m 16m S 0.0 27.2 0:02.47 firefox-bin |
| 5 |
> > [x4] |
| 6 |
> > 22668 lustosa 15 0 129m 97m 17m S 0.0 13.0 11:50.05 firefox-bin |
| 7 |
> > [x2] |
| 8 |
> |
| 9 |
> Hm, on the hand: yes, it _is_ memory hungry. On the other hand: You've |
| 10 |
> already said: virtual address space. And as I interpret the above |
| 11 |
> numbers, a lot of things is most probably shared among those processes. |
| 12 |
> You can find out e.g. by comparing their /proc/<PID>/maps. |
| 13 |
|
| 14 |
|
| 15 |
Yes, but what caught my eyes was not the virtual address space. The resident |
| 16 |
portion (i.e., what is really allocated on real memory) is huge for that |
| 17 |
first instance. 204mb is way too much for a firefox with 4 tabs open. |
| 18 |
From top output, isn't the SHR the shared memory between them? It's at 16mb |
| 19 |
for the first, and 17mb for the second. This is still too little compared to |
| 20 |
204mb or 511mb. |
| 21 |
|
| 22 |
> You mean that tiny frontend to the OS' functionality? It certainly |
| 23 |
> doesn't need much memory, no. But remember, other Browsers have to |
| 24 |
> implement a lot of this stuff themselves and not rely on the |
| 25 |
> functionality that specific OS and its API offers. |
| 26 |
|
| 27 |
|
| 28 |
I know, I know... this was just a small rant. I'm not using windows for a |
| 29 |
long long time. |
| 30 |
This seems to be a very bad memory leak somewhere, them problem is I don't |
| 31 |
know even how to start a bug report on a situation like this. |
| 32 |
|
| 33 |
-- |
| 34 |
Bruno Lustosa, aka Lofofora | Email: bruno@×××××××.net |
| 35 |
Network Administrator/Web Programmer | ICQ: 1406477 |
| 36 |
Rio de Janeiro - Brazil | |
Archives