It happened again today. I've managed to collect some info about it compared to a normal boot.
Attached is a file with the output of top, free -m, and a count of the number of processes in gnome-system-monitor.
Also, I think I know what's causing the statistics difference between top and system-monitor, asadjb. top counts caches and buffers while system-monitor does not. You can see this by using free -m, which shows memory usage with and without caches/buffers.
What I've concluded:
- the total memory usage (with caches and buffers) is about the same in a normal and high memory boot; during a normal boot, most of the leftover space is claimed by the caches and buffers.
- even when run under gksudo, gnome-system-monitor contains around 80 'unknown' processes: processes marked by a gear icon and who's memory usage (all types) is always N/A. Could these be taking up the rest of the memory?
- when doing an approximate summation of the memory (under the tab that just says Memory) in gnome-system-monitor, it never approaches the amount of used memory during a normal boot.
Anyone know what to make of this?
A few more answers means a lot more questions.
P.S.- thanks swizman! I've noticed a 10-20 second decrease in boot time in the one boot since I reprofiled.
I was wondering if this was possibly an once-every-xxx-boots kind of thing but it apparently isn't. After going a large number of boots between two occurrences, it happened after only 2 boots.
My guess is that some process is intermittently doing a lot of disk access that pushes used memory into swap. If you have on the order of 512M of RAM, this is very plausible. One thing you could try would be to set the swappiness lower. This will prevent a background, disk hungry application from evicting used RAM to swap and might fix your problem. Just add the following to /etc/sysctl.conf:
On subsequent reboots, hopefully the problem will no longer appear.Code:vm.swappiness = 1
Don't try to make something "fast" until you are able to quantify "slow".
Yes, I do have less than 512 MB of RAM, so this sounds plausible. I already have vm.swappiness set to 10; so far, I haven't noticed too much difference, though I haven't been able to test it much.
Note about the 'unknown' processes (with memory N/A and gear icon): these are all processes that are spawned by kthreadd (and kthreadd itself). Does anyone know why they have memory usage as N/A in all categories? Any ideas how to show their memory usage?
Make sure you turn off desktop effects. There seems to be a memory leak with some video drivers and glx.
If running glxinfo suddenly frees a bunch of memory, this might be the issue.
I will admit that I do have compiz running with a bunch of effects enabled. HOWEVER, this memory leak has been occurring since way before I discovered compiz or had any effects enabled. I'll try the glxinfo thing next time this happens, though.
I think I'm having this problem too. About half the time Ubuntu uses ~200 Mb at login and the other half of the time its ~1GB. However, it doesn't seem to grow a memory leak usually does.
I have 4GB of RAM total. It takes about 10-15 seconds to log in when the system appears to be doing nothing.
I'll try reprofiling and see if that helps. Let's get this fixed.
Oh dear, it happened again! I reprofiled a while a go, so that didn't help. Running 'glxinfo' and 'sudo glxinfo' freed no memory. Logging out, logging into another account, logging out of that and then back into my normal one didn't free up any memory except a little due to the difference in settings (e. g. compiz vs. metacity). Switching from compiz to metacity and back on my normal account didn't due much, either.
The strangest thing, though, (and this may not be related to the memory issue) is that after I logged in but before the desktop, background, and panels appeared, the screen suddenly went all white for about 10 seconds when usually I'd have seen the login background image. Any ideas?
Also, I've noticed that when running compiz at the terminal, I get messages like:
Could this be where some leaking is occurring?Code:WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! compiz (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png compiz (cube) - Warn: Failed to load slide: WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
Also, arkixml - keep us updated. Your problem sounds exactly like mine. Run some tests when this kind of thing happens and see if you can find any differences between a normal boot and a "leaky" boot.
If anyone has any suggestions about what to do next time this happens, please post them. Also if anyone requests that I attach a certain log file I will be happy to oblige.