Jump to content

Gnome or X overloading my system?


ianw1974
 Share

Recommended Posts

My current icon theme is glass icons. My metacity/gtk2 is "brushed", and my wallpaper is just a basic gnome one.

 

Quite like the icons on my desktop though ;)

 

See show your desktop this month, my screenie is in there, so unsure if I'm using anything svg based or not.

 

Unfortunately, can't change my nvidia card as it's a laptop, so I'm kinda stuck with it. Works perfect at home with this exact setup on my nvidia geforce 4 ti4400, which of course, is by far better with 128M ram on it.

 

I'm running a test this morning, as I said I would. Login Manager is kdm, and I've logged into Gnome to see what happens.

Link to comment
Share on other sites

  • Replies 31
  • Created
  • Last Reply

Top Posters In This Topic

Well, my test so far for running the system for 45 minutes has lasted far longer than before.

 

As I mentioned, login manager is kdm and using Gnome. These are the results:

 

[root@europa ian]# ps aux | grep X11
root	  3371  4.2 13.7  76296 71000 tty7	 Rs+  07:26   3:04 /etc/X11/X -deferglyphs 16 :0 -auth /var/run/xauth/A:0-wJ0XWs
root	  6332  0.0  0.1   2028   648 pts/0	R+   08:38   0:00 grep X11

 

[root@europa ian]# free
		 total	   used	   free	 shared	buffers	 cached
Mem:		515304	 477740	  37564		  0	  18488	 266828
-/+ buffers/cache:	 192424	 322880
Swap:	   996020	   2552	 993468

 

Which kind of makes me thinks it has something to do with gdm and not gnome itself. So, I've done the following:

 

fc-cache -v

 

to see if it could have been font-related, and am going to do a reboot in a second with using gdm as the login manager, and see if we get the system overload like before.

Link to comment
Share on other sites

OK, further testing seems that I cannot resolve the problem. The fc-cache didn't help, although wasn't expecting it to. I remember a gdm problem when using arch and this, so figured it can't harm it.

 

Anyway, tried the vesa driver instead of "nv" and it dies even quicker in terms of the memory leak, or whatever is happening. At least when using the "nv" driver it doesn't happen as quick.

 

The cause for the problem is GDM. If I use KDM I don't have the problem.

 

The only way I've managed to actually ensure my system stability is in one of two solutions:

 

First Stability Method

 

Use KDM as the login manager. Gnome and KDE work perfectly fine. The only problem when using KDM is that Gnome doesn't get shutdown/reboot options. This means, you either have to use a console window and issue halt/reboot or to logout of Gnome and then use shutdown/reboot from the KDM login manager screen.

 

Second Stability Method

 

Unsure of how successful this one is at present, as I'm currently in the process of testing this one out. First off, I've disabled swap by commenting out the line in my /etc/fstab as follows:

 

# /dev/hda3 swap swap defaults 0 0

 

so now I have no swap, and the only memory the system can allocate is physical ram. The problem was that when swap was getting utilised, it was killing my system because it was hammering the hard disk all the time, until eventually it had used the full swap of 1GB.

 

So far my system has been up 8 minutes with this config, and has pretty reasonable memory usage for the time being. However, I usually find that the memory leak or whatever it is starts from about 15 minutes and upwards.

 

Summary

 

Seems that I've found a bug that's causing this. System is fully up-to-date, so there's no fix for it at present.

Link to comment
Share on other sites

My current icon theme is glass icons. My metacity/gtk2 is "brushed", and my wallpaper is just a basic gnome one.

 

Quite like the icons on my desktop though ;)

 

See show your desktop this month, my screenie is in there, so unsure if I'm using anything svg based or not.

 

Unfortunately, can't change my nvidia card as it's a laptop, so I'm kinda stuck with it. Works perfect at home with this exact setup on my nvidia geforce 4 ti4400, which of course, is by far better with 128M ram on it.

 

I'm running a test this morning, as I said I would. Login Manager is kdm, and I've logged into Gnome to see what happens.

gdm has been known to do that....

I had a mem problem long ago....ML9.1? and never found the problem, so I went cooker :P

 

-the glass icons are svg but svg alone won't cause this

-video card alone will not cause this

-the gtk theme uses a bg pixmap and that is very slow

...I was just mentioning a few speed up tips

 

I didn't use a dm for years, but started using gdm recently because it was the only way I could get other users to be able to login....would not work from init 3 :o

Edited by bvc
Link to comment
Share on other sites

Hi bvc,

 

Really appreciate the tips for speeding up Gnome. Hopefully if I get the gdm thing sorted, I should be OK. Shall see if the bug report yields anything.

 

As I soon realised after posting, it wasn't Gnome that was the problem but more X and GDM causing a bizarre memory problem. And also weird it doesn't affect all my systems.

Link to comment
Share on other sites

I have a similar problem with evolution running under KDE. Evo is a gnome app as we all know:-). Anyway, sometimes for no reason it starts eating up swap memory which brings the system down to its knees.

 

I use evo & Firefox for meany years by now, and they have always been memory hogs from day one. Filing bug reports makes sense if you use `the latest and the greatest' version, but Mandriva is way behind the Gnome development cycle. I still use Evo 2.0, and there is no way to update it to the latest version. Besides, there is no guarantee, this new version is any better.

Link to comment
Share on other sites

IIRC, the memory consumtion was optimized in the new releases by the evo-developers themselves.

With all respect, this answer is of no use to me - installing the current version cannot be done without updating the whole Gnome suit, and this will most likely break the system (Mandrake 10.1).

Link to comment
Share on other sites

Sorry, I guess my answer was a bit too short this time. :)

 

You cannot use the current version of evolution on an older system like Mdv 10.1 as evolution 2.0+ depends on a newer gtk version and was built with a different (newer) compiler than the ones available on 10.1. Thus, the only way to use a less ram eating version of evolution is to upgrade the whole system. Forcing an update of evo alone will surely break your box.

Link to comment
Share on other sites

Sorry, I guess my answer was a bit too short this time. :)

 

You cannot use the current version of evolution on an older system like Mdv 10.1 as evolution 2.0+ depends on a newer gtk version and was built with a different (newer) compiler than the ones available on 10.1. Thus, the only way to use a less ram eating version of evolution is to upgrade the whole system. Forcing an update of evo alone will surely break your box.

Thanks, stuffing up the working system is what I fear most.

 

Unfortunately, upgrading the whole system is now seen as a tool to fix bugs, and it should not be. I am affraid, the curiosity of the Linux community towards new versions is often mistaken as a commitment to monthly upgrades. Untill this attitude changes, Linux will remain a domain for geeks to play.

Link to comment
Share on other sites

Well, here you go. The official response, and bug closed. Nice eh:

 

Then your X server is buggy.

 

the only different between gdm and kdm is that kdm is restarting X server while

gdm is not.

 

Just set AlwaysRestartServer=true in /etc/X11/gdm/gdm.conf

 

I don't see how that will solve it. For example, I rebooted my system, so it was shut down completely. X would have started from scratch. I checked ps aux straight after, and the system had loads of memory free, so was perfectly fine. Yet later, it's increased it's memory usage.

 

And it only happens with X/GDM combination. So go figure?

 

So, if the X server is buggy, go fix it then instead of giving a cop-out response.

 

I sometimes wonder if actually logging bug reports is actually worth my time and effort. Probably will be my first and last if that's the attitude you get!

 

Anyway, my reply:

 

Then if the X server is buggy, shouldn't this need to be looked at? I'm using

the xorg with Mandriva 2006 and it's completely up-to-date.

 

but I guess it will be closed again after I re-opened it, and they'll tell me I should log a different bug report.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • Create New...