Description of problem:
Immediately after starting X11 on Fedora 11 alpha, the Xorg server starts taking up more and more memory. With a few applications running (I have gnome-terminal, firefox, evolution and eclipse open), after about 30 minutes of work Xorg takes up 520MB RES and 1.7GB VIRT (interestingly - top reports 510MB SHR), at which points the interface is not as snappy as it initially is, dialog redraws are easily seen by the user and opening a menu takes as much as 1 second.
After several hours of work Xorg may take up to 5Gb VIRT and 900MB RES (on my machine with 4GB memory and 6GB swap), the interface slows to a crawl (opening a menu may take up to a minute) and whole system becomes unusable.
For comparison - on a system running Ubuntu 8.10 with a similar work load, even after several days Xorg uses 50MB RES, 13MB SHR and 440MB VIRT.
Version-Release number of selected component (if applicable):
Initially I though that there is something wrong with my user account, which was from before upgrading the Fedora 11 alpha, but it also happens with a new user account that I created for the purpose of getting something done and on which I only run the above mentioned applications.
I found that simply scrolling up and down a page (like the eclipse editor or page in firefox) can cause MBs increase in Xorg's RES size in mere seconds.
As a final example, in the time it took me to write up this report, Xorg RES size grew by more then 70 MB with only slight provocation on my side (scrolling as mentioned above).
My hardware is an intel board with what Display Settings reports as an 82Q35 Express Integrated Graphics Controller.
I'd be more then happy to provide any additional information that may be required and even provide access to my workstation if someone is interested in looking at the problem directly.
Oh, and I forgot to mention that I'm not using desktop effects of any kind (haven't even tried yet).
I just upgraded to the most recent rawhide, with Xorg 1.6 and kernel 2.6.29 rc6, and all the problems listed above still happens.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 333520 [details]
Log from Xorg 1.6.0
I do not have an xorg.conf file - its the first thing that went away once I started having problems. I can send the old configuration file (the one from Fedora 10) if you want - the problem was happening with or without it.
Created attachment 333522 [details]
Second log from Xorg 1.6.0
I'm not sure what the whole thing with the ".old" is - I haven't done it, and its newer then Xorg.1.log
Created attachment 333523 [details]
Log from Xorg 1.5.99
Also here is the log from the previous pre-release version of 1.6.0 (from before yesterday's upgrade). It also had the same problem
BTW - an interesting thing I noted, not sure how it relates to anything, but as the X server becomes slower and its VIRT size becomes larger - less and less of the system's memory remains allocated to programs and more and more of it is allocated for caches (I use htop which shows color coded memory consumption by type of usage - very nifty :-) ).
It looks like the X server forces the memory cache to grow so much that it doesn't let the application have enough memory and the system starts thrashing - I can see kswapd blocking on IO most of the time.
I just install F11 alpha on a new computer, featuring an Intel 82G31/G33 Express IGC (as per system-display-config), where I was unable to reproduce the issue.
Some more info - on the new computer I, where I installed F11 from scratch, X.org does not take huge amounts of memory, but it does take more then I would have expected: with Just Firefox, Evolution and a terminal running for a couple of hours, X.org is over 100MB RES and 300MB VIRT (for comparison, a Fedora 10 workstation with a session running for several days with many applications running including browsers, eclipse, image viewers, etc' Xorg is currently about 80MB RES and 300 VIRT).
In addition, the display on the new machine feels very sluggish - sometimes windows have their decoration drawn half a second or more after the content is appears (GNOME run application dialog), the window content takes a couple of second to be drawn (system monitor), a closed window takes a while to be removed from the screen (almost any window over a certain size) and workspace switching is noticeably slow.
This is without xorg.conf (apparently the default way F11 installs).
The Xorg server has a clear memory leak in relatively recent rawhide. I've learned to keep an eye on it; otherwise it sends my system (3.5G RAM) into OOM thrash hell.
Will attach log.
Created attachment 336898 [details]
Xorg.0.log; this is a session I shut down once my system started to get thrashy.
Created attachment 336899 [details]
My xorg.conf file. Nothing special here; I've made no direct changes.
This still happens to me on the current Fedora 11 - After about two weeks of uptime, Xorg is at 900MB RES and 3GB VIRT. With everything else my computer is running (basically a full KDE 4 desktop with Firefox and Evolution), it doesn't leave much room in the computer's 2GB memory.
I think Xorg does a lot of paging as performance of simple things getting a history list in Firefox's location bars takes about half a minute and navigating in it is very slow. Other things suffer as well, such as typing text in a console.
I'm using an intel 945 chipset if it makes any difference.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Does this still happen?
I can't really tell - I got back to the office after two weeks of not using the computer, and the first think I did was upgrade to current rawhide (which I've been running for a while) and reboot. So right now I'm on a fresh session where X is consuming a very reasonable 35MB RES.
I'll have to update you on the status in a couple of days.
(In reply to comment #16)
> I'll have to update you on the status in a couple of days.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command
yum upgrade --enablerepo='*-updates-testing'
Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
I cannot reproduce at this point and I'm no longer using that hardware so it will be hard to address the request.