4.5.3 was just released, could you try to upgrade to that? there were some
fixes with the shared memory cache in kdelibs that might be related.

if the problem persists, it would be quite valuable to know if the problem
occurs with a "stock" configuration on your machine.

if it doesn't, then tracking down what triggers it in your configuration
(per-virtual-desktop views? a specific plasmoid? etc) would be very interesting
information to have.

Okay, I'm running 4.5.3 now. Some X.org stuff was also upgraded (but not
xorg-server itself), so I guess the crash right after the first login came due
to this (I had not restarted X/kdm yet). Another observation is that a nasty
problem with graphics distortion when scrolling in all applications (kmail,
konqueror, chromium, ...) is now gone, which is great. I had this since I moved
from the closed-source fglrx ATI drivers to radeon.

There _is_ some change in plasma behaviour, it comsumes nearly no CPU time now
- top shows it a 0% often. CPU usage was not really high before, around 5-10%.
That's really cool, actually some KDE things DO improve.

No change in memory consumption, though. Except that it's now at 1.4G after
startup instead of 1.3G.

Now I will try to remove plasmoids until hopefully the memory problem is gone.
If not, I will try a fresh start, which should work. When I log in with a test
user that has no ~/.kde4 yet, plasma does not use that much memory. So I assume
it must be something with my configuration.

great news about the improvements! please do keep us posted with your search
for what triggers the memory consumption. once identified, we can figure out
what to do about it. thanks in advance ...

I will. I just removed the plasma-desktop-appletsrc file and logged into KDE.
plasma-desktop uses 215M now. Is this okay, or still somewhat large?

Before, I removed all plasmoids from the desktop (except for the logging one on
my first desktop which I forgot), but kept those in the panel. Memory usage was
somewhat reduced, but still took around 800M.

BTW, I'm using Gentoo Linux with kernel 2.6.36 on an AMD Athlon(tm) Dual Core
Processor 4850e with 6G RAM, in 64bit mode.

how are you measuring memory consumption?

I'm looking at top's RES column.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 6266 root      20   0 1303m 471m 108m S    1  8.2   1:04.80 X                  
 8236 wonko     20   0 1887m 257m  15m S    0  4.5   0:02.65 java               
 8048 wonko     20   0  953m 228m  95m S    0  4.0   0:02.02 plasma-desktop     
 8235 wonko     20   0  713m 140m  38m S    0  2.4   0:03.40 kontact

top is notoriously bad at these things. it's useful for relative, rough numbers
but not very useful for determining "is that normal / reasonable?"

the system monitor (Ctrl+Esc, or the "graph" icon in the run command interface
(Atl+F2)) does a better job, though it isn't perfect either. can you pop that
up, enter "plasma-desktop" in the search bar and post those numbers?

(228MB is not a normal #, though it depends on your set up. here, plasma is
taking a little over 20MB, and that's a full debug build with all possible
dependencies satisfied at build time. still, it's hard to tell if you are
experiencing a real, fixable problem there due to the relatively unhelpfulness
of top.)

Thanks! The system monitor gives 136892K in the "memory" column, and 97900K in
the Common memory" column. Or whatever the exact names are in English.

And this is what ps thinks about it:

wonko@weird ~ $ ps aux | head -n 1; ps aux | grep [p]lasma-desktop
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
wonko     8048  0.0  4.0 977968 234792 ?       Sl   19:00   0:02 kdeinit4:
plasma-desktop [kdeinit]

Do you have each desktop as a single activity? I still do. I'll remove plasma*
and activitymanagerrc (not only plasma-desktop-appletsrc), maybe this gives an
even fresher start, with a single activity on all desktops. I'll rather not
remove my whole .kde4, I'd hate to configure all of that again. But I'll try
this once, let's see how much memory I need then.

Here am again. I removed plasma* and activitymanagerrc, now the system monitor
shows 53M right after login, and 68M now (44M of common memory). Without a
.kde4, I got a similar value 56M. top gives 109M.

Okay, this still looks a little large, but hey, it's been 1.4G a while ago :)
Now I will add activities/plasmoids and monitor memory usage.

Some figures. I'm using the system monitor now.

When I enable 'different mini programs per desktop' in the virtual desktop
settings, memory jumps from 61M to 112M. With another, unconfigured activity, I
have 181M, and a little later (without major changes) it's 223M.

Um, did the activity handling change from 4.5.2 to 4.5.3? I think the virtual
desktop setting was 'different activities for each desktop', while now I can
enable different mini programs per desktop. I'm not sure if I even need another
activity now, while I had eight before. If something did change here, could
this be responsible for my memory problems?
Just for fun, I added another 7 activities of mixed type, memory is at 572M
now. So these activities for sure use lots of memory.

Now I will have to think a little about my desktop philosophy, and what
different acitivities I need.

Okay, here's the final update I think. The current setup has only one activity
(instead of eight), but different mini-programs for each of my now six
desktops. The other setup is quite similar as before.

Memory for plasma-desktop is at 240M / 102M, CPU usage is 1%. KDE feels real
fast now, and I'm happy.

Oh, and be careful when playing around with activities or plasmoids... I had
about five X crashes, and 2-3 plasma crashes. No big probelm while configuring
stuff, but I'll be careful to save my important stuff when adding plasmoids
again.

BTW, I have LOTS (100M) of these liens in kdm.log: 
__glXDRIbindTexImage: Failed to register texture offset override
Just in case this might somehow be related.

So I re-arranged my desktops a little, backed up my .kde4 directory, made
screenshots of the desktop (http://www.wonkology.org/comp/desktop/2010-11-11/),
and suddenly the problem happened again. I backed out the plasma config and
tried to reproduce the problem, and finally I did.

So, the problem was the logging plasmoid (file monitor, 'Dateiüberwachung'
in German). It's on desktop2.png, at the top. When I changed the file to log
from /var/log/hdstate to /var/state/hdstate, plasma-desktop started eating RAM
until it was at 1.5G. It turned out that I had an error in the script that
creates /var/state/hdstate. I have this in my /etc/conf.d/local.start:
(
        while :
        do
                hdstate >> /var/state/hdstate
                sleep 10
        done
) &

At system start, a loop is sent to the background, updating this file every ten
seconds, in order to show the state of my hard drives. Well, the '>>' was a
silly mistake, this file had grown to 45 MB. I replaced it by a '>', and it's
fine now, with plasma-desktop useing 250 MB.

So, while this was sort of my own fault, the plasmoid still should not use 1 GB
to read a file of 45 MB... and it probably should not read it as a whole, a
tail -n 500 or so would be enough in any case.

Happy fixing!

first, as to usage of memory by activities: activity handling has changed
somewhat. now when you have "per virtual desktop" turned on, have M virtual
desktops and N plasma activities, then N*M Plasma::Contaiments are created.
that means with 6 desktops and 8 activities, you'd have 48 Containments on your
system.

it still looks like your system is using excessive amounts of memory, but it's
growing and shrinking in ratio to the components (e.g. containments) that are
being created, so i'm just going to chalk that up to differences in build
environments and build-time options rather than it being an actual bug or
something we can do something about here.

one thing you can do that helps _alot_ with memory is to stop the activities
you aren't actively using. all but the current activity has a "stop" button on
the activity icon that you can press: that actually unloads the activity from
memory. this allows one to have as many activities as you want defined without
having them all in memory at once.

as for the real problem here, thanks for doing the detective work to figure out
the culprit: the watch file plasmoid! great work on tracking it down, now we
know what needs to be done.

i'm going to change the title of this bug and the component to reflect this and
we'll eventually fix it. cheers and thanks for your cooperation in helping
figure this one out.

Aaron, thanks for the tip. I had up to eight acitivities, but only for testing.
And indeed memory rose up. Now that I can have different plasmoids on different
desktops, the main need for other activities is gone, so I already use only
one. Maybe I will add another one, to quickly change the pasmoids to different
ones, not sure yet if I need this. BTW, are the plasmoids also called
'mini-programs', or is this only in my German locale?

Another BTW: I now remember why I used >> instead of >. It's because > creates
a new file, but the original file is still in place while it's opened by the
file watch plasmoid, despite being already deleted. It's the inode that counts
here. But I found a workaround, I simple delete the file once in a while and
give the plasmoid some seconds to detect this - somehow this works, I guess it
does perodical checks for the file's existance, using the file name here, not
the inode. I found bug #203956 that deals with this, and suggested this to be
changed, similar to tail which has the --follow=name option for this.

KDE SC 4.6.2 and the same. It's almost impossible to watch my /var/log/messages
(40Mb) because plasma-desktop consumes 300Mb of RAM.
Furthermore, it doesn't free (or heap become very fragmented) and it still
wasting 250Mb of RAM.

*** Bug 262415 has been marked as a duplicate of this bug. ***