We're seeing problems with applications allocating memory, and never releasing it. On small machines, like LTSP thin clients, with 32mb or 64mb of ram. If you leave an app like Firefox running for more than a couple of days, the Xserver will consume all available ram, and eventually, the kernel will kill it. I realize this is something that should be fixed in the application, but i'm getting reports of lots of apps that are doing this, such as gpdf. If there were a way to limit the amount of ram that the Xserver can allocate, either specified as a number of megabytes, or a percentage of system ram, it would prevent the Xserver from being killed, which takes the user session with it. Instead, it could return an error to the application, which would then either handle it gracefully, or die a horrible death. Either way, it's better than losing the user session.
I'll second this. Just limiting the amount of RAM that the Xserver will use is a good start. Even better would be a way for it to push old and large pixmaps out as needed. Firefox isn't the only offender here; there seem to be a lot of apps lately that don't clean up after themselves. Is there anything in the X protocol that would allow the Xserver to "age out" pixmaps?
The best I can think of that we can do and not violate the protocol is to keep track of the total amount of pixmap data allocated by each client, and when a particular client tries to go over that limit, start returning BadAlloc for any more CreatePixmap requests - which will cause most clients to exit, since they don't handle XErrors. The per-client limit would of course need to be configurable and probably optional, but I don't think it would be that hard to implement.
Trying to set memory requirements on a client-by-client basis will be a nice fine-grained control, but will create the problem that to control clients effectively, will require quite a bit of thought (i.e. Firefox I want to limit to X megs, gpdf I want to limit to Y megs, etc.), and could require a large configuration section. If you're simply going to set a single "no client can consume more than Y megs" parameter, you'll have to set it so high that it won't end up being a useful metric. Better (at least from our point of view), would be to set a "total amount of pixmap memory available" parameter. When the pool gets close to the limit set, the BadAlloc result is returned. That way, the user doesn't need to worry about per-client config. Ideally, it'd be nice to have and and/or on both per-client and total-pool settings, but for thin clients, at least, a total-pool setting is better.
*** Bug 2524 has been marked as a duplicate of this bug. ***
One refinement of this idea would be to add pixmap pageout to the server directly.
I would rather like to see a separate memory pool per client where all allocations for a given client are satisfied from (except, perhaps for data shared by several clients). That way when a client exits (or killed due to memory abuse) the virtual size of the xorg process is reduced too. I reckon per-client memory pool would be a good solution to memory fragmentation in xorg.
I use Debian Etch with Xorg 7.0.22. Please decide upon a solution! Try the most simple (global cache size limit for Xorg) first, and then we will see if our PCs become usable again. Too many people end up like me after hours, days, or weeks, depending on the power (memory and CPU) of their PC: Xorg has put so much stuff in cache that the computer becomes 10 times slower, and I am not exagerating! My duron@1750Mhz with 1Gbytes and matrox G400 really feels much slower than my old Celeron 400. This is incredible, horrible, and an emergency. My computer becomes totally unusable after 2 weeks, but before that it became unusable several times because of amule, which after days increases the memory and CPU consumption of Xorg a lot (30% CPU usage for X, ten times more than normal) and I have to kill amule, and the same could have been said of Mozilla if it did not crash regularly, freeing some memory. I admit I leave many programs open, and some of them like Mozilla and Firefox have terrible memory consumption, but what am I supposed to do: turn off my PC regularly like at the nightmarish time of Windows 98, or kill programs regularly? What kind of a computer experience is that? Don't worry: I wrote to the Mozilla and amule developpers a long time before writing to you! Exemples of people experiencing huge memory usage by X and very slow computer: http://ubuntuforums.org/showthread.php?t=92844 http://ubuntuforums.org/showthread.php?t=85869 And I found many many more desperate people while googling for a solution. Keep up your important work for all of us, and please save us! And contribute to decrease the energy usage of computers and the memory consumption! It is important for planet Earth! Every time we are forced to buy more memory the computer industry releases more horrible toxic pollutants into Nature. Top: top - 18:04:10 up 17 days, 16:57, 3 users, load average: 6.28, 6.43, 6.23 Tasks: 158 total, 9 running, 149 sleeping, 0 stopped, 0 zombie Cpu(s): 79.1% us, 12.3% sy, 1.7% ni, 0.0% id, 0.0% wa, 0.7% hi, 6.3% si Mem: 1036752k total, 1027564k used, 9188k free, 5024k buffers Swap: 3028244k total, 2440072k used, 588172k free, 131608k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27590 rich 16 0 803m 413m 16m R 36.9 40.9 477:46.95 mozilla-bin 23481 rich 25 0 158m 80m 6968 R 18.9 7.9 150:11.98 amule 21549 rich 16 0 32548 7780 5948 S 14.3 0.8 879:22.57 ksysguard 6859 gkrellmd 16 0 11768 888 716 S 6.3 0.1 2079:52 gkrellmd 7520 rich 16 0 104m 10m 6292 S 6.3 1.0 187:47.60 kicker 25683 rich 15 0 304m 39m 34m R 6.0 3.9 620:50.09 qemu 7271 root 16 0 1396m 52m 4720 R 5.0 5.1 1720:59 Xorg 21556 rich 15 0 3052 884 708 S 3.3 0.1 133:53.03 ksysguardd 6514 rich 16 1 262m 124m 13m R 1.7 12.3 153:13.94 firefox-bin 7516 rich 15 0 42280 6720 4620 S 0.3 0.6 10:11.28 kwin 7532 rich 15 0 35504 6828 4900 R 0.3 0.7 0:15.88 konsole 7582 rich 15 0 38796 4512 3384 S 0.3 0.4 124:48.41 gkrellm 7810 rich 15 0 58644 1812 1548 R 0.3 0.2 28:46.51 xmms 8545 rich 15 0 26720 2588 2520 R 0.3 0.2 16:33.10 gksu 24100 debian-t 15 0 11088 8528 1608 S 0.3 0.8 4:14.98 tor 19865 root 15 0 34896 920 856 S 0.3 0.1 0:49.01 apt-listbugs 7705 rich 15 0 2388 1164 840 R 0.3 0.1 0:00.10 top After killing Mozilla: top - 18:27:11 up 17 days, 17:20, 3 users, load average: 2.87, 3.81, 4.78 Tasks: 158 total, 2 running, 155 sleeping, 1 stopped, 0 zombie Cpu(s): 28.8% us, 8.3% sy, 0.3% ni, 50.7% id, 4.6% wa, 1.0% hi, 6.3% si Mem: 1036752k total, 684076k used, 352676k free, 4524k buffers Swap: 3028244k total, 1259400k used, 1768844k free, 134752k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23481 rich 15 0 158m 80m 6812 S 9.6 8.0 153:04.12 amule 21549 rich 16 0 32548 8072 6140 S 7.6 0.8 882:03.19 ksysguard 6859 gkrellmd 15 0 11768 888 716 S 6.6 0.1 2081:23 gkrellmd 7520 rich 16 0 104m 10m 6352 S 6.0 1.0 189:31.68 kicker 7271 root 15 0 540m 80m 3112 S 5.6 8.0 1723:03 Xorg 25683 rich 15 0 304m 43m 37m S 4.0 4.3 621:40.59 qemu 7534 rich 17 0 29100 5772 4936 S 1.7 0.6 21:42.72 kdf 21556 rich 15 0 3052 884 708 S 1.0 0.1 134:32.27 ksysguardd 31635 rich 15 0 45604 8124 3280 S 0.7 0.8 1:29.10 btdownloadgui 7810 rich 15 0 58644 1812 1548 S 0.3 0.2 28:48.73 xmms 6514 rich 16 1 262m 114m 12m S 0.3 11.3 153:27.03 firefox-bin 8545 rich 15 0 26720 2588 2520 S 0.3 0.2 16:36.00 gksu 8294 rich 15 0 174m 8648 7768 S 0.3 0.8 5:09.21 kaffeine
After closing almost every other software, one hour after having closed Mozilla: top - 20:03:46 up 17 days, 18:56, 1 user, load average: 0.60, 1.94, 2.78 Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie Cpu(s): 11.3% us, 1.3% sy, 0.0% ni, 86.3% id, 0.0% wa, 0.0% hi, 1.0% si Mem: 1036752k total, 983776k used, 52976k free, 42988k buffers Swap: 3028244k total, 653616k used, 2374628k free, 558504k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21549 rich 16 0 32548 8832 6720 S 7.6 0.9 892:58.52 ksysguard 7271 root 15 0 453m 211m 2404 S 2.7 20.9 1729:14 Xorg 21556 rich 16 0 3052 884 708 S 1.7 0.1 136:11.99 ksysguardd 6859 gkrellmd 15 0 11768 892 720 S 1.0 0.1 2087:02 gkrellmd 7532 rich 15 0 35504 8464 6096 S 0.3 0.8 0:17.54 konsole 14372 rich 16 0 2264 1132 840 R 0.3 0.1 0:00.03 top 1 root 16 0 1956 508 476 S 0.0 0.0 0:03.69 init After a reboot (same software as at last top): top - 20:16:16 up 9 min, 1 user, load average: 0.32, 0.31, 0.16 Tasks: 98 total, 2 running, 96 sleeping, 0 stopped, 0 zombie Cpu(s): 6.6% us, 0.3% sy, 0.0% ni, 91.4% id, 0.0% wa, 0.0% hi, 1.7% si Mem: 1036752k total, 302252k used, 734500k free, 15596k buffers Swap: 3028244k total, 0k used, 3028244k free, 161340k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7630 rich 16 0 32312 17m 12m S 3.7 1.7 0:07.50 ksysguard 7318 root 15 0 53648 15m 3628 S 2.3 1.5 0:11.30 Xorg 6883 gkrellmd 15 0 10740 1144 852 S 1.3 0.1 0:09.12 gkrellmd 7639 rich 15 0 2924 1460 924 S 0.3 0.1 0:00.94 ksysguardd 7684 rich 16 0 34712 15m 11m R 0.3 1.6 0:00.49 konsole 1 root 16 0 1956 656 560 S 0.0 0.1 0:01.03 init Xorg goes from 453m 211m to 53m 15m. Can you do something about that? Please!
Welcome to Unix. In general, memory that is freed by an application like Xorg is returned to the free list for that application, but the application size does not shrink.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I guess this report covers my problem: https://bugzilla.novell.com/show_bug.cgi?id=434561 However from what I see everybody complains about "after hours/days of working" when my problem is quite simpler -- with low memory (because there is little RAM or there is plenty of it but a lot of apps are already running) just after launching new app X server crashes/restarts. This of course means that all apps running in X are also crashed. My only guess is the app asks X to get handle to new window and... at this point is confusing: a) if X is too gullible and tries to allocate memory, it does not get it and operates on it -- ok, X bug, it is fair to kill X b) if there was memory allocated, and then the app allocates some more (but for internal purposes) why X is killed -- this app should be killed, right? Anyway, it would be good to create a error dialog about not allocated memory just after starting X, and if any app is requesting memory in low-mem conditions, the allocation should be refused and the error dialog should be shown (this is because it is not sure if the app can handle it, it may crash as well -- so there is at least some info for the user). In other words my point is -- if some app within X misbehaves it and only it should be killed, not X with all apps running. This disturbs me most because bugs will haunt us for long, so memory, no-memory, but no matter what X should be protected from not its faults.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.