Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
However I do think you have a problem since you're using almost 2GB of swap. Run vmstat 10 and watch the 'so' and 'si' columns - if there are a lot above 0 then you're actively swapping and you definitely have a problem.
I did a google search for +xorg +"memory leak" and of course there are a ton of hits and I don't know how to evaluate which are relevant. The one that looked most relevant was
Hello I am running a linux maching on a PC which has 2 GB of RAM Installed.
It would take a lot more investigation to find out whether something is really wrong (such as a memory leak) or whether you just are using more memory than you have.
Those stats seem to indicate MATLAB, java, konqueror, plasma-desktop and maybe others are tying down a lot of memory while relatively idle. The swap partition is nearly full, so the kernel is forced to leave anonymous pages of idle tasks in physical ram while either dropping pages of active .so's or even calling the "out of memory killer".
So if those stats indicate all valid use of memory (not leaks) then you need a larger swap partition. Even with that, you would have terrible performance each time you switch to a previously idled task and even worse if too many of those tasks are trying to be active at once. You might also need more physical ram.
If it is a memory leak, the most likely problem is Xorg. But I don't have good advice on how to figure out whether there is a memory leak in Xorg.
Quote:
Originally Posted by H_TeXMeX_H
That's a good site, I will link to it, because a lot of people ask this question.
It's a great site, because lots of people ask the question answered by that site. But this time it is a distraction. This thread is not the usual "linux ate my ram" question at all. This time, something definitely is using too much anonymous memory for healthy operation with just 2GB of ram plus 2GB of swap.
So the answer is not the usual "everything is OK, you just misunderstood the stats". The answer is one of:
1) There is a memory leak that should be found and fixed.
2) You need more swap space
3) You need both more swap space and more physical ram.
To find out if Xorg is leaking, leave it on alone (close firefox and the rest) for a while and check top once in a while to see if RAM usage goes up. If it keeps going up, it is a leak.
I don't see any reason to suspect a leak in Xorg, it could be just a lot of memory intensive processes running, close them all and see if it reduces back to normal.
To find out if Xorg is leaking, leave it on alone (close firefox and the rest) for a while and check top once in a while to see if RAM usage goes up. If it keeps going up, it is a leak.
That would be wasted effort. A leak in Xorg would mean it leaks memory when some specific kind of activity occurs (of course we start with no clue what specific kind of activity). So if you test it with no activity and nothing leaks, you proved nothing. Anyway without a better measure of "RAM usage" you wouldn't know how to interpret the results even if you had some of whatever activity makes Xorg leak.
Quote:
I don't see any reason to suspect a leak in Xorg
So xorg's VIRT size of 1684m and RES size of 467m don't make you suspect a leak? What do you think caused that?
I don't know enough about Xorg. I don't know enough about all the other idle windows in the OP's system (that weren't mentioned in top). So I'm not trying to say those values indicate a leak, just that they make one suspect a leak.
Memory leaks are hard to diagnose and hard to fix, so if you know a better way, say so. Otherwise, I would close all processes except for Xorg and see if the usage goes down, if it does, then it was just those processes. You can also try using a program that you know doesn't leak but uses Xorg.
When I was running Xfce I had exactly that happen, and no matter what I did the RAM usage went up with time (characteristic of a leak). It didn't matter if I left it alone or did something, the leak was still there.
Last edited by H_TeXMeX_H; 05-20-2010 at 01:11 PM.
top - 15:28:52 up 3 days, 7:22, 9 users, load average: 4.73, 5.60, 6.36
Tasks: 230 total, 4 running, 225 sleeping, 0 stopped, 1 zombie
Cpu(s): 26.5%us, 69.4%sy, 0.0%ni, 4.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1959936k total, 1885700k used, 74236k free, 9392k buffers
Swap: 2112508k total, 1999344k used, 113164k free, 338672k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1428 root 20 0 1684m 467m 2872 S 2 24.4 73:19.45 Xorg
18537 apa 20 0 883m 281m 35m S 8 14.7 45:02.24 firefox
3233 apa 20 0 876m 62m 13m S 0 3.3 4:08.47 thunderbird-bin
32635 apa 20 0 207m 57m 15m S 7 3.0 0:18.99 npviewer.bin
19068 apa 20 0 926m 55m 3508 S 0 2.9 0:23.85 MATLAB
32713 apa 20 0 782m 54m 13m S 0 2.9 0:04.60 java
3398 apa 20 0 671m 51m 4532 S 0 2.7 0:53.15 konqueror
3052 apa 20 0 604m 35m 10m S 0 1.8 3:10.46 plasma-desktop
Could you please help me try understand the stats above?
Perhaps then I could be able to blame something that consumes my memory.
Best REgards
Alex
<attitude>
You are running some version of KDE 4? Well, that'll probably be the problem then.
</attitude>
Looking at your numbers, there are several noteworthy features:
you have a zombie process; that is doing you no good, but it is probably not doing you appreciable harm.
your load average numbers are on the high side; this probably means that your computer is running slowly and is somewhat unresponsive; is this the basic problem, or are you propelled by the intellectual satisfaction of understanding this problem?
the big consumers of memory appear to be Xorg and FF; the other stuff that you can see is mostly 'small change'
for ff, that level of memory consumption is probably reasonable if you lots of tabs open, if you only have one or two it isn't
Xorgs' high level of consumption could be a 'bug' in Xorg itself, or, more likely, something is asking Xorg for services that legitimately cause Xorg to consume lots of memory; my bet is that the latter, is probably more likely and is the only thing that you could do something about easily
does this happen soon after a clean boot, or is it only after the PC has been running without a re-boot/logout for a while?
You are probably running the version of KDE that came with SUSE out of the box; if so, ensure that you do not have random repositories enabled and try an upgrade to factory if you dare. If you have any conflicting repos enabled currently, sort that problem out and see where that gets you.
(Hmm, that last link seems to be a thread started by someone called, on that forum, alaios; that repo list looks a bit longer than desirable, but with nothing crazy in it - not the full 'I've used one click install a lot' madness).
Alternatively, try a different GUI; do you still have the same problem?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
