I recently noticed that if I log in to my xfce GUI straight after powering up my computer it takes an inordinately long time. Like it takes four or five minutes from when I enter my name and password to when the desktop appears completely.
After suspecting that there was something awry with my X startup (such that it was doing something odd the first time it was run) I realised that it was simply that the system was very heavily loaded by something during/after boot. Watching the load average during the X startup it went over 8 whereas if I login to X after the system has been running for some hours the load average reaches the giddy heights of 0.14.
With a load average of 8 things almost grind to a halt, some processes retry starting (I get more than one xfdesktop for example) and update-notifier times out trying to access repositories which it has no problems at all with if I log in later.
Another symptom is that some nfs mounts haven't completed before the terminal windows appear on the desktop so when I run mutt (mail program) which uses one of the NFS mounts it fails to see its mail directories. That's seriously wierd.
I've tried to analyse what's going on by running top (and 'w' and ps) in a console window while the system starts up but I really can't see anything obvious that's hogging any resource. One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
Can anyone suggest further ways of trying to diagnose this?
Hi,
2010/1/15 Chris G cl@isbd.net:
I've tried to analyse what's going on by running top (and 'w' and ps) in a console window while the system starts up but I really can't see anything obvious that's hogging any resource. One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
ps auxwH | sort -k 6 -n
Take out H if you dont want to see all user mode threads.
Run this a few times to check for rapidly increasing PIDs.
HTH, Srdjan
On Fri, Jan 15, 2010 at 05:05:38PM +0000, Srdjan Todorovic wrote:
Hi,
2010/1/15 Chris G cl@isbd.net:
I've tried to analyse what's going on by running top (and 'w' and ps) in a console window while the system starts up but I really can't see anything obvious that's hogging any resource. One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
ps auxwH | sort -k 6 -n
Take out H if you dont want to see all user mode threads.
Run this a few times to check for rapidly increasing PIDs.
Thanks, I'll try it out.
Chris G wrote:
One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
This may be simply down to the kernel using unallocated memory for disk cache etc, cat /proc/meminfo would probably tell you more info in this respect and you will most likely see that the vast proportion of memory is "cached" which means it is being used as a filesystem cache as there is nothing else for it to do.
top only uses the first two values so from there it looks like you are almost out of memory.
On Fri, Jan 15, 2010 at 07:01:19PM +0000, Wayne Stallwood wrote:
Chris G wrote:
One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
This may be simply down to the kernel using unallocated memory for disk cache etc, cat /proc/meminfo would probably tell you more info in this respect and you will most likely see that the vast proportion of memory is "cached" which means it is being used as a filesystem cache as there is nothing else for it to do.
top only uses the first two values so from there it looks like you are almost out of memory.
Yes,I think that's probably it as it never swaps, just sits with all of real memory 'used'.
2010/1/15 Chris G cl@isbd.net:
I've tried to analyse what's going on by running top (and 'w' and ps) in a console window while the system starts up but I really can't see anything obvious that's hogging any resource. One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
Can anyone suggest further ways of trying to diagnose this?
While top is running press Shift-M to sort by memory usage. On my desktop PC firefox is using 7.3%, followed by Xorg and nautilius at 0.5% each.
Pressing Shift-T to sort by accumulated time, I see firefox at 41 hours, followed by trackerd at 7 hours, Xorg at 2 hours and compiz.real with just 23 minutes. Anything interesting show up on your system?
Tim.
On Fri, Jan 15, 2010 at 05:05:42PM +0000, Tim Green wrote:
2010/1/15 Chris G cl@isbd.net:
I've tried to analyse what's going on by running top (and 'w' and ps) in a console window while the system starts up but I really can't see anything obvious that's hogging any resource. One noticeable thing apart from the load average being so high is that my 8Gb of memory gets eaten up too, but there seem to be no particular processes using either lots of CPU or lots of memory.
Can anyone suggest further ways of trying to diagnose this?
While top is running press Shift-M to sort by memory usage. On my desktop PC firefox is using 7.3%, followed by Xorg and nautilius at 0.5% each.
Nothing serious, similar to yours except that Firefox is only 1%, mysqld is second, Xorg third. Much as expected really. I need to try closer to when it's running slowly though so I'll bear Shift-M in mind, thank you.
Pressing Shift-T to sort by accumulated time, I see firefox at 41 hours, followed by trackerd at 7 hours, Xorg at 2 hours and compiz.real with just 23 minutes. Anything interesting show up on your system?
Again nothing exciting, but as before I probaly need to try closer to the problem event.
-
Chris G -
Srdjan Todorovic -
Tim Green -
Wayne Stallwood