Re: gigantic memory leak in Clock Applet...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



I'm still not really out of the problem either:

On 2013-01-09 14:21, fred smith wrote:
>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>    11159 fredex    16   0  263m 149m  10m S  0.3  3.8   1:36.87 clock-applet

263m VIRT: We understand that virtual memory is sum of all, including the read
only/executable parts of lots of shared libraries which are not using many
resources in fact because they are backed by the real files.

149m RES: The parts that are really in use by "this" program, but including
the parts shared by many others of the Gnome package that are running.
(I put "this" between quotes, because someone seemed to believe that
top or ps or some other program adds memory sizes in in "unfair" way
to some processes only, while they should have been distributed over many.
Actually I can't find any reason, or explanation of that.)

10m SHR:  of those 149m that are in use, 10m is the shared portion.

That leaves 139m allocated exclusively by the clock-applet.
Incredibly large yes.

What is that clock-applet doing with 139m?
Or is that just because you do have lots of RAM, and in fact, lots of those
pages could be swapped out (= for executables like shared libraries, just
be removed; they can be swapped in from the file itself), but never had to
be swapped out/deleted, because the OS still had unused pages.

I have rebooted my workstation (due to postponed kernel upgrade) yesterday.
I have now:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
5908 paulb     15   0  283m  13m 9496 S  0.0  0.3   0:25.29 wnck-applet
5950 paulb     15   0  268m  10m 8968 S  0.0  0.3   0:54.00 clock-applet

and I can't find any process that is taking large amounts of memory.
Firefox & Thunderbird are using considerable amounts but not more than usual.
I did not run any real large program yet (swap use is 0 now), and did not
do heavy memory using programs except ff & tb.
So why is my RES on 10m now? Probably because the clock-applet did not
even touch more of the shared libraries (totaling 268m possibly being touched).

As I said, the problem of the large clock-applet magically disappeared for me
somewhere between 5.1 and 5.5 or so.
I remember fiddling with the seconds indicator, changing every option to default,
monitoring the mem over several weeks, seeing it increasing, but seeing no
trend/reason/cause. Gave up on searching intensly. And then some time later
noticed the problem disappeared.
Yesterday I thought wcnk-applet had the enormous amount of RAM, but I think
I was looking at the VIRT size only then.  VIRT is a useless indicator here.

Inspecting /proc/PID/smaps of such a large process may reveal something?


(Nostalgia: 1m private data for my running clock-applet still seems large to me,
remembering to program on a mainframe with a total memory of 12 Mbyte, supporting
hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum
amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size
of a washing machine.)


-- 
Paul Bijnens, Xplanation
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., *
* stop, end, ^]c, +++ ATH, disconnect,  halt,  abort,  hangup,  KJOB, *
* ^X^X,  :D::D,  kill -9 1,  kill -1 $$,  shutdown,  init 0,  Alt-F4, *
* Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux