This seems like a long-standing issue for certain systems and I am apparently the lucky winner . After years of flawless KDE operation in my Kubuntu 10.04 system, I setup a box with Kubuntu 12.04. I'm running single display with a recent Nvidia adapter and the version 304 Nvidia driver. When I first log into the desktop session, things are as snappy as I'd expect them to be. However, over about a day of normal use things get slower and slower. I first notice it as a "catch" or "jerk" while scrolling in Firefox, but it eventually drags almost everything down. Xorg begins to eat more and more memory and use increasing amounts of CPU time. Eventually, things become almost non-responsive for 10-15 seconds at a time while Xorg spikes to 80-90% CPU. Memory usage of xorg starts around 180M, but climbs well over 1GB by the time I'm forced to cycle the session. If I log out, restart the X server and log in again it's back to normal.

Over the past week I have tried quite literally every bit of advice found on this and other forums. I've twiddled Nvidia hardware parms, experimented with xorg.conf, switched between OpenGL and Xrender, disabled this, that and everything else... Nothing cures the problem.

It really irks me to have a state-of-the-art box that I have to log out/in from every day just to keep it usable. Can anyone suggest a reasonable approach to mitigating the problem?

-what is

Code: Select all

 glxinfo | grep render

if it's "software rasterizer" that's probably your problem

-are you using the "blur" desktop effect? if so try disabling it

-what graphics card?

-why 12.04 ? why not 13.04?

-if it possible to upgrade your Nvidia drivers? 304 is a bit old, 325.15 is current

google01103 wrote:-what is

Code: Select all

 glxinfo | grep render

if it's "software rasterizer" that's probably your problem

-are you using the "blur" desktop effect? if so try disabling it

-what graphics card?

-why 12.04 ? why not 13.04?

-if it possible to upgrade your Nvidia drivers? 304 is a bit old, 325.15 is current

- glxinfo says:

direct rendering: Yes
OpenGL renderer string: GeForce GTX 650/PCIe/SSE2
GL_NV_complex_primitives, GL_NV_conditional_render,
GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
GL_NVX_conditional_render, GL_NVX_gpu_memory_info,
GL_OES_depth_texture, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,

- I have blur disabled

- Graphics card and other info:

[1035574.599] (**) NVIDIA(0): Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefaultAC=0x0"
[1035574.599] (**) NVIDIA(0): Enabling 2D acceleration
[1035574.924] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (DFP-0)) does not support NVIDIA
[1035574.924] (II) NVIDIA(GPU-0): 3D Vision stereo.
[1035574.925] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 650 (GK107) at PCI:1:0:0 (GPU-0)
[1035574.925] (--) NVIDIA(0): Memory: 1048576 kBytes
[1035574.925] (--) NVIDIA(0): VideoBIOS: 80.07.35.00.0b
[1035574.925] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[1035574.925] (--) NVIDIA(0): Interlaced video modes are supported on this GPU
[1035574.926] (--) NVIDIA(0): Valid display device(s) on GeForce GTX 650 at PCI:1:0:0
[1035574.926] (--) NVIDIA(0): CRT-0
[1035574.926] (--) NVIDIA(0): Samsung SyncMaster (DFP-0) (connected)
[1035574.926] (--) NVIDIA(0): DFP-1
[1035574.926] (--) NVIDIA(0): CRT-0: 400.0 MHz maximum pixel clock
[1035574.926] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): 330.0 MHz maximum pixel clock
[1035574.926] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): Internal Dual Link TMDS
[1035574.926] (--) NVIDIA(0): DFP-1: 165.0 MHz maximum pixel clock
[1035574.926] (--) NVIDIA(0): DFP-1: Internal Single Link TMDS
[1035574.926] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[1035574.926] (**) NVIDIA(0): device Samsung SyncMaster (DFP-0) (Using EDID frequencies
[1035574.926] (**) NVIDIA(0): has been enabled on all display devices.)
[1035574.927] (==) NVIDIA(0):
[1035574.927] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"
[1035574.927] (==) NVIDIA(0): will be used as the requested mode.
[1035574.927] (==) NVIDIA(0):
[1035574.927] (II) NVIDIA(0): Validated MetaModes:
[1035574.927] (II) NVIDIA(0): "DFP-0:nvidia-auto-select"
[1035574.927] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1200
[1035574.954] (--) NVIDIA(0): DPI set to (93, 95); computed from "UseEdidDpi" X config
[1035574.954] (--) NVIDIA(0): option
[1035574.954] (--) Depth 24 pixmap format is 32 bpp
[1035574.954] (II) NVIDIA: Using 3072.00 MB of virtual memory for indirect memory
[1035574.954] (II) NVIDIA: access.
[1035574.957] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[1035574.986] (II) Loading extension NV-GLX
[1035574.998] (==) NVIDIA(0): Disabling shared memory pixmaps
[1035574.998] (==) NVIDIA(0): Backing store disabled
[1035574.998] (==) NVIDIA(0): Silken mouse enabled
[1035574.998] (**) NVIDIA(0): DPMS enabled

- I prefer not to chase versions every six months, so I generally stick with the LTS releases.

- The latest driver offered from the Ubuntu repos was 319 - it made no difference at all. I'm a bit hesitant to do a manual install unless it can be accomplished without hosing the DKMS hooks and making a retreat into a mess.

if you restart the pc and disable compositing (alt+shift+F12) or disable in systemsettings -> desktop effects -> general then restart does the problem still occur

this is a new hw setup? if you moved your ~/.kde to a new machine try renaming ~/.kde.share/config/kwinrc and restarting the pc

run "xrestop" to see what causes memory load on the X11 server.
It is normal that the cpu usage raises notably while xrestop is running, so only use it for inspection (quit with "q")

Sorry to go quiet, but it took a number of days to try each suggestion (things don't generally go south until the desktop session has been up for 2-3 days. I can report that deleting kwinrc and letting it create a new one made no difference at all. Then, since that reenabled the blur effect, I tried turning that off. No improvement, things still ground towards a halt after 2 days.

I'm currently running with compositing turned off (in addition to the above). Will keep my fingers crossed.

BTW: xrestop showed only one difference between a newly established session and one starting to bog down. Something called 'Library' began appearing at the top of the memory consumption list.

Thanks again for the suggestions - I'll keep plugging at it.

check the PID field next to the "Library" entry - if it's not "?" you can inspect the process in /proc/<pid>, eg "cat /proc/<pid>/cmdline" or "ll /proc/<pid>/exe" might be informative

Well, turning off desktop effects (compositing) delayed the onset of creeping slowness a bit, but it got there eventually. Xorg starts off at about 150MB of memory in 'top', but by this morning had creeped up over 380 - and still climbing. In comparison, my KDE 4 box at work (running RedHat EL6.4 - nvidia display and two screens) sits at about 150MB for months on end.

Xrestop shows this as heavy hitters:

xrestop - Display: :0
Monitoring 50 clients. XErrors: 0
Pixmaps: 39952K total, Other: 4246K total, All: 44198K total

res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
2000000 90 4 0 204 364 27478K 10K 27489K 12382 kwin
4e00000 36 47 1 442 845 5503K 22K 5526K 10379 Library
2400000 35 35 0 26 171951 312K 4031K 4343K 12390 plasma-desktop
5400000 54 47 1 554 1046 3908K 27K 3936K 12721 Inbox - IMAP Local - Mozilla Thunderbird
2e00000 7 4 0 66 109 896K 2K 899K 12418 krunner
2200000 47 56 1 1349 3170 811K 77K 888K 13070 WinXP Pro - VMware Workstation

There's not much more I can disable. Any ideas where to go next, or should I resign myself to windows-like restarts every couple of days?

if you're using an Oxygen theme try changing it, might be (though old) https://bugreports.qt-project.org/browse/QTBUG-11245

> Pixmaps: 39952K total, Other: 4246K total, All: 44198K total
43MB in resources is not much and the output is typical (though i've no idea what "Library" is)
KWin requires ~27MB (redirected windows) and plasma-desktop ~4MB (the wallpaper)

That's not ideal but required for X11 compositing.

-> The memory leak will be in the server or one of the drivers, ie. in the X11 server itself.
I'd first try either upgrading the nvidia blob or replacing it by the nouveau driver and check whether the leak still occurs.

You don't btw. have to reboot - restarting X11 will be sufficient (log out, then in doubt press ctrl+alt+backspace and log in)

I was using "restart" figuratively - after all, this ain't Windows .

Evidence is starting to point at the Nvidia display driver being the culprit. I took the plunge and updated to version 325. The good news is that the Ubuntu 'xorg-edgers' team makes newer drivers available in deb packages. The bad news is that the documentation for same is confusing and incomplete. Omitting a number of false starts, the procedure is simply:

$ sudo add-apt-repository ppa:xorg-edgers/ppa
$ sudo apt-get update
$ sudo apt-get install nvidia-325

This will properly replace the official package (v 319 in the case of Kubuntu 12.04) with 325 and update the DKMS hooks to survive subsequent kernel updates.

When done, disconnect the ppa:

$ sudo mv /etc/apt/sources.list.d/xorg-edgers-ppa-precise.list /etc/apt/sources.list.d/xorg-edgers-ppa-precise.list.save
$ sudo apt-get update

There are probably more elegant ways to deactivate the new ppa source, but I was running out of patience at that point and just cut to the chase. Despite what the xorg-edgers web page says, I advise strongly against doing a blind "apt-get upgrade". It tries to bring in dozens of replacement packages, which amusingly enough does NOT include the nvidia driver! Looks like a good recipe for a broken system.

When you then exit the desktop, things will fail and throw you back to a text screen. This is because the update logic is not smart enough to set a hook that unloads the old driver. At the command line:

$ sudo rmmod nvidia
$ sudo service kdm (or gdm) restart

and you should be set.

I've been running the new driver for about two days and memory use by xorg has stabilized at 265M virt, 145M res - give or take 2/3 M. This has never happened before. Generally it would be north of 350M and heading to 1G as things grind to a halt. I have not seen any sign of slowness. Another good indicator is xrestop. With the older driver, I was seeing ~27M of pixmap use by kwin. Now it's hovering around ~19M.

I'm not ready to declare victory yet, but am keeping my fingers crossed. Will follow up after a few more days.

I wanted to update this thread. Since the last posting I switched to an older Nvidia GeForce 8600 adapter and reverted to the Nouveau driver (the Ubuntu 12.04 nouveau doesn't support the GTX650). I also stopped using Firefox in favor of Chrome. Everything else stayed the same: OpenGL, no blur or any other fancy effects. Same symptoms. Over the course of about 5 days, xorg memory use climbed from an initial 55 MB to over 360 MB and the desktop slowed to a crawl with scrolling on both thunderbird and chrome "catching" and "jerking". Xorg CPU use spiked to 40-50% frequently, etc, etc.

This time, I tried shutting down Vmware Workstation (9.02) before anything else and noticed the CPU usage dropped immediately. After a bit of digging, I believe I'm the victim of KDE Bug 314919. I've just restarted the desktop session and disabled both Dropbox and the Vmware tray icon. Will let you know if this appears to help.

If this turns out to be the issue, can anyone advise if/when the underlying bug became fixed and at what version of KDE?

I think the results can be claimed as official: After turning off the Vmware tray icon and stopping Dropbox, xorg memory use has stayed absolutely flat (at 89MB) for over three days. No slowdowns, no CPU spikes. In fact, it's tough to read memory use on xorg because it uses so little CPU that it almost never appears in top!

It looks like there are KDE bug reports open on this issue already (plasma-desktop --> task manager). I also see mention of open bug reports on the Arch Linux, SuSE, Kubuntu, Ubuntu and a few other forums. Clearly it's a real defect that is affecting a number of users.

So, may I ask: Has this been acknowledged as a KDE bug? Has it been fixed? If so, at what release level?

Thanks for any guidance you are able to provide.

shirsch wrote:In fact, it's tough to read memory use on xorg because it uses so little CPU that it almost never appears in top!

Press Shift+"M" and the list is sorted by memory usage...

If it only occurs with the nouveau driver and the "leak" is not recorded in xrestop, it's most likely a bug in the nouveau driver - beyond bug #314919
Also ensure that it's not because you're running XRender compositing beause of nouveau, resp. that this has no impact.