X using tons of memory [SOLVED?]

Message

selig · Post by **selig** » Sat Sep 25, 2010 4:07 pm

I am having a problem with Xorg on my laptop. It is basically the same configuration as my PC, the only difference in X I can see is the graphics card driver. My PC used to have the "radeon" driver and X consumed about 130 MB of memory. Now I am running it with the proprietary nVidia driver (I changed cards) and it eats about 40 MB.

However, the laptop is a completely different issue. X server there can eat up to 380 MB memory. It is running the "intel" video card driver. Is there a memory leak in this driver? Can someone please explain or point me to the right direction of finding out where that memory goes? It is terrible because it tends to swap and get slow while running KDE...

Both are running the latest Gentoo stable versions of everything, USE flags are almost identical as well as the CFLAGS, LDFLAGS etc.. I even tried minimising CFLAGS on the laptop and recompile everything X-related - however, that did not help at all. It starts with ~130 MB but gradually eats up as much as those 380 MB in a few hours.

Thank you for any suggestions!

Ant P. · Post by **Ant P.** » Sat Sep 25, 2010 5:40 pm

X on my laptop with xf86-video-intel 2.12.0 is using less than 9MB... have you tried other DEs?

dmpogo · Post by **dmpogo** » Sat Sep 25, 2010 10:21 pm

Ant_P wrote:X on my laptop with xf86-video-intel 2.12.0 is using less than 9MB... have you tried other DEs?

Did you run it over a long time ? I never so as low as 9 Mb consumption from X

chithanh · Post by **chithanh** » Sat Sep 25, 2010 10:31 pm

You can find out if applications use X memory (to cache pixmaps etc.) with xrestop.

Ant P. · Post by **Ant P.** » Sat Sep 25, 2010 11:43 pm

Also you might find this interesting.

selig · Post by **selig** » Sun Sep 26, 2010 4:11 pm

Thank you for the tips! hmm, xrestop is not showing much usage.

Code: Select all

xrestop - Display: localhost:0
          Monitoring 29 clients. XErrors: 0
          Pixmaps:   33367K total, Other:     322K total, All:   33690K total

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
1200000    55    1    1 2381 2774     9192K     67K   9260K 14741 kwin
1400000    38   28    5  620  770     8473K     24K   8497K 14747 plasma-desktop
1800000    15   55    1   36   85     5543K      4K   5547K 32014 chrome
2800000    30   11    9 3700 3811     3885K     99K   3984K 14891 Endow (PĹ~Yipo
2400000     8    3   33 1725 1761     1547K     74K   1621K 14879 sharn-lugonn :
3c00000     4   35    1   28   24     1532K      2K   1534K 12123 dscf2039.jpg -
2600000    12   33    1   25   62     1511K      3K   1514K 14882 Audacious
2000000     5   33    5  298  339     1261K     13K   1275K 14820 krunner
3800000     3    1    1  177  192      153K      5K    159K 11349 kwalletd
0400000    16    4    1   18   45      119K      2K    121K 14877 kmix
1600000     3    1    1    2  402       24K     10K     34K 14743 kglobalaccel
1e00000     3    1    1    6   19       26K      1K     27K 14784 kxkb
2a00000     6    1    1    3   18       24K      1K     26K 14914 klipper
0c00000     4    1    1    2   12       24K      1K     25K 14715 kded4
1c00000     3    1    1    2   10       24K      1K     25K 14751 kaccess
1a00000     3    1    1    2   10       24K      1K     25K 14746 knotify4
0000000     2    0    2    0   97        0B      4K      4K   ?   <unknown>
1000000     4    1    1    2   11        0B      1K      1K 14739 Qt-subapplicat
3200000     0    1    0    0    4        0B    120B    120B   ?   <unknown>

However, top is nice:

Code: Select all

top - 18:09:45 up 13 days, 21:37,  5 users,  load average: 0.08, 0.22, 0.10
Tasks: 160 total,   1 running, 159 sleeping,   0 stopped,   0 zombie
Cpu(s):  8.2%us,  7.0%sy,  0.0%ni, 84.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1921964k total,  1835904k used,    86060k free,   260732k buffers
Swap:   996024k total,    98996k used,   897028k free,   672220k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
14660 root      20   0 1202m 467m  59m S   18 24.9  40:48.40 X                  
14741 sharn-lu  20   0  491m  16m 8324 S    7  0.9  21:08.17 kwin               
32174 sharn-lu  20   0  913m  96m  21m S    2  5.1   0:06.57 chrome             
32014 sharn-lu  20   0  455m  60m  28m S    1  3.2   0:10.75 chrome             
14879 sharn-lu  20   0  342m  17m 7184 S    1  0.9   2:34.01 konsole            
 1785 sharn-lu  20   0 17292 1396 1004 R    0  0.1   0:00.01 top                
14704 sharn-lu  20   0 19940 1552  772 S    0  0.1   0:03.90 dbus-daemon        
14715 sharn-lu  20   0  379m  11m 5816 S    0  0.6   0:08.20 kded4              
14747 sharn-lu  20   0  807m  36m  14m S    0  1.9   2:18.99 plasma-desktop     
31376 root      20   0     0    0    0 S    0  0.0   0:01.38 kondemand/1        
    1 root      20   0  4008  588  540 S    0  0.0   0:02.84 init               
    2 root      20   0     0    0    0 S    0  0.0   0:00.01 kthreadd           
    3 root      RT   0     0    0    0 S    0  0.0   0:01.14 migration/0        
    4 root      20   0     0    0    0 S    0  0.0   0:03.30 ksoftirqd/0        
    7 root      20   0     0    0    0 S    0  0.0   0:07.67 events/0           
    9 root      20   0     0    0    0 S    0  0.0   0:00.01 khelper            
   14 root      20   0     0    0    0 S    0  0.0   0:00.00 async/mgr

I will try some other DE too, just to be sure it is not KDE eating the memory... I will report my findings here.

BTW my software versions:

Code: Select all

$ emerge -pv xf86-video-intel libX11 xorg-server mesa

These are the packages that would be merged, in order:

Calculating dependencies                                    ... done! 
[ebuild   R   ] x11-libs/libX11-1.3.4  USE="xcb -doc -ipv6 -static-libs -test" 0 kB
[ebuild   R   ] media-libs/mesa-7.8.2  USE="nptl pic xcb -debug (-gallium) -motif (-selinux)" VIDEO_CARDS="intel -mach64 -mga -nouveau -r128 -radeon -radeonhd -savage -sis -svga -tdfx -via" 0 kB                                              
[ebuild   R   ] x11-base/xorg-server-1.7.7-r1  USE="hal nptl sdl xorg -debug -dmx -ipv6 -kdrive -minimal -tslib" 0 kB                                           
[ebuild   R   ] x11-drivers/xf86-video-intel-2.9.1  USE="dri -debug" 0 kB

Total: 4 packages (4 reinstalls), Size of downloads: 0 kB

selig · Post by **selig** » Sun Oct 03, 2010 2:09 pm

It seems that KDE is the culprit - when I use fluxbox, the usage of RAM by Xserver is about 30-40 MB. But I really do not know why X server should eat so much memory when running KDE - what is KDE doing to it?

selig · Post by **selig** » Fri Oct 08, 2010 9:02 am

I have noticed another weird X behaviour on this machine. Whenever I switch to a VC from X and back again, X starts eating 100% CPU, all of it system time. The cursor moves very slowly across the screen and the screen almost does not get updated. After 10-30 seconds it returns to normal. The same behaviour appears when starting the X server for the first time.

X starts with memory usage at ~35 MB and continuously increases it during hours and days of uptime, bringing it to numbers like 500.

What should I try? An ~amd64 driver for intel graphics?

cach0rr0 · Post by **cach0rr0** » Fri Oct 08, 2010 9:56 am

very strange

mine is KDE-4.5.1, on an Intel GM45

Code: Select all

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                
 2103 root       0   0  264m  79m  32m S    3  2.0  21:11.03 X                                                                                                                      
12650 meat       1   0  479m  75m  28m S    0  1.9  13:22.46 chrome                                                                                                                 
 2289 meat       1   0  481m  62m  28m S    1  1.6  44:48.83 kwin                                                                                                                   
17533 meat       1   0  851m  54m  14m S    0  1.4   0:21.01 chrome                                                                                                                 
24046 meat       1   0  833m  49m  16m S    0  1.3   2:01.45 chrome                                                                                                                 
 2348 meat       1   0  347m  46m  26m S    0  1.2   0:00.61 python2.6

Code: Select all

hplaptop cups # uptime
 04:55:25 up 1 day,  9:26,  4 users,  load average: 1.21, 1.10, 1.09

this is with the full set of desktop effects enabled.

you sure nothing got buggered in an update somewhere, that might have resulted in you using the dreaded software rasterizer?

Code: Select all

$ glxinfo |grep render

pingufunkybeat · Post by **pingufunkybeat** » Fri Oct 08, 2010 10:40 am

selig wrote:It seems that KDE is the culprit - when I use fluxbox, the usage of RAM by Xserver is about 30-40 MB. But I really do not know why X server should eat so much memory when running KDE - what is KDE doing to it?

Compositing maybe? Fluxbox doesn't do it, and it gobbles up memory.

selig · Post by **selig** » Fri Oct 08, 2010 11:01 am

Well I have all desktop effects enabled in KDE and I am using OpenGL hardware acceleration for that. Do not worry, it is not software renderer, that is slow like hell and noticeable at a first glance.

I checked glxinfo too.

I do not really need those effects - but what I do want is a transparent KDE panel. When I disable compositing, transparency is gone.

It is probable that some update did that because it had not been like that until a few months ago. Unfortunately, I do not know what exactly had been updated before the issue started to be apparent.

My graphics chip is Intel 4500MHD - I think it is GM45 but it might be GS45 too.

pingufunkybeat · Post by **pingufunkybeat** » Fri Oct 08, 2010 11:41 am

It's got nothing to do with OpenGL acceleration, really. When you have compositing enabled (like you do), the X server stores a perfect copy of every single window you have open in your video memory (which in your case is the main memory). A full-screen app (even when not shown, like when it's on a different desktop or minimised) will easily take up many megabytes (1920 x 1080 x 32 bits). Additional effects come with their own memory requirements.

Try disabling all the effects and compositing, and looking whether the memory footprint changes. How many apps do you typically use concurrently?

I should note, however, that the creeping increase to 500MB does sound very much like a memory leak somewhere.

selig · Post by **selig** » Fri Oct 08, 2010 12:54 pm

Mostly I use konsole with 4-5 tabs, Chromium with ~8 tabs, Sylpheed, GQView and Audacious, sometimes mplayer or GIMP. So not really many applications are running at the same time. I will try disabling all effects in KDE and see if it helps.

selig · Post by **selig** » Sat Oct 09, 2010 12:08 pm

It seems that disabling all effects in KDE helped with the memory usage - I have not used the system for long enough so I am not absolutely sure yet. However, it did not help with the issue with switching VCs (ctr+alt+F1 ; ctrl+alt+F7).

selig · Post by **selig** » Sat Oct 09, 2010 4:59 pm

After some 8 hours of usage with effects turned off, memory of X increased from 95 to 115 MB (it started at 95 MB because I had had effects running before starting this test). It seems that the memory leak is still present but leaks memory more slowly.

Nerdanel · Post by **Nerdanel** » Sat Oct 09, 2010 5:53 pm

I've also had problems with KDE leaking memory. For me, turning off all the plasmoids stopped it, although I had to restart KDE to get the memory back. I'm not sure if the memory leak is a general plasmoid thing or if a specific plasmoid was doing it. This was a few versions ago, though.

selig · Post by **selig** » Thu Nov 04, 2010 5:05 pm

Well, it seems to have stopped. Or at least it is not as dramatical, maybe thanks to a kernel upgrade... I will probably never know. But it is still using more than twice as much memory than on my desktop with nVidia drivers.