[SOLVED] Existeth a way to 'clear out' all the old/cached crap from RAM/SWAP to free up space?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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.
Existeth a way to 'clear out' all the old/cached crap from RAM/SWAP to free up space?
Closest analogy I can compare what I want to, is like the `sync` command, which writes out all stuff in the disk buffers, freeing the buffers.
Instead of disk buffers, I want to 'clean out' my RAM and SWAP of any/all junk that's accumulated in there over the time my PC has been up. I've long wondered about this, but never asked, though I recall searching around several times..
When I first boot it cold and log in, the memory usage bar on my desktop is near zero, and the swap is empty. But after a week or 2 or 3 or more of uptime, and with Firefox always running with a dozen tabs or so at any given time, I end up with all the memory full or 'filled with cached stuff', and the swap space is filled to capacity.
Curiousity: I blame Firefox for leaking memory, but even if that's still the case today (historically it was) can this all be blamed on Firefox? Or what-all causes this, besides Firefox- just..Everything?
So, 3.8 of 4 Gib of RAM is occupied, and the 1 Gib swap space is jammed full 100%. This must slow things down to some degree, yes? I mean, the kernel does have to keep track of this, right?
Of course closing all the applications doesn't make a difference (not an appreciable one anyhow) and the only way I have found to start fresh is to reboot.
Isn't there another way?
Thanks for your interest.
Last edited by GrapefruiTgirl; 07-22-2010 at 01:08 PM.
I think what you are looking for is "drop_caches". Won't buy you a lot in this case.
Swap like that smells of a leak. I would try a ps reverse sorted on rss, and start at the top. For swap, have a look at /proc/<pid>/smaps.
For in-depth analysis, try collectl (cue Marks entry from stage left ... )
Thanks for this, syg00 - I'll hafta have a look into this tomorrow (bed time now). The `ps` I can figure out (looking at that now though not sure what I'm seeing ) but I'll have to dig around about the collectl and drop_caches; no idea what they're about!
I end up with all the memory full or 'filled with cached stuff', and the swap space is filled to capacity.
'filled with cached stuff' would be pretty normal and harmless. But that doesn't fit what you posted. It looks like a serious memory leak.
Quote:
closing all the applications doesn't make a difference
That is very surprising. Ordinary memory leaked by an application is recovered when the application is closed.
You suspected firefox. Did you close firefox?
Is this a 64-bit system? (So it would be possible for the kernel to leak this much memory).
If the kernel is leaking memory, you should be able to gather info about that with
Code:
cat /proc/slabinfo
I don't know enough about how things like inode caches work. That kind of memory use is reported inside /proc/slabinfo and I'm pretty sure is not included in the "cache" memory reported by free.
I don't know how (or even whether) caches that are kept in slab memory respond to overall system memory pressure. If they respond well, then what you're seeing might not be a memory leak. It might be just another form of memory being better used by caches than left unused. Even some swap use is plausible in that theory. But I think you have too much swap use, and too little ordinary cache. So even if the actual use is by something like an inode cache, I think it is functioning as a memory leak.
The key is to find out (with the highest rss values in top or ps and with /proc/slabinfo) what exactly is holding onto the memory. Then you can dig deeper to find out whether it is a memory leak and/or what to fix.
Your system is probably demonstrating healthy behavior by making use of all available RAM for caching files and programs for faster use later on. Disk cache stuff will get pushed out of memory if your apps need it.
Flushing your disk cache would actually slow things down and all that extra memory you have would go to waste until the cache is refilled.
Your system is demonstrating healthy behavior, by making use of all available RAM for caching files and programs for faster use later on.
That is the usual answer for the commonly posted question that looks superficially like GrapefruiTgirl's question. But this time it's the wrong answer. Look more carefully at the output from free that GrapefruiTgirl posted.
Even though I don't (yet) know what this "RSS" (I'll look it up) is, if it's something that means those numbers will shrink or disappear when I close 'applications', it would appear that I stand to recover the most by killing X, which I will test shortly. (Maybe the nVidia driver contributes to that? Or maybe just X all by itself..)
And following X, of course, is Firefox, followed by my window manager, i3, followed by a bunch of KDE stuff; although the only KDE item I ever use is Kwrite (EDIT: and Kmix), it/they evidently starts up a load of KDE daemons/processes after being started, and they never subsequently go away unless forcefully stopped..
FWIW, to date the only thing I have ever had in my sysctl.conf that relates to memory (AFAIK), is vm.swappiness=50. Here's the file:
Code:
root@reactor: cat /etc/sysctl.conf
# proc/sys things which can be adjusted/tuned using sysctl.
# Default swappiness in general is apparently 60.
# Lower number (10) should make desktop more responsive.
vm.swappiness=50
kernel.core_pattern=core.%e.%p
root@reactor:
I'll post again after researching the 'collectl' and 'drop_caches' to see if there's anything to be played with in that regard, and eventually try logging out (to kill X and see what effect that has).
Thanks for the input so far you guys.
Last edited by GrapefruiTgirl; 07-22-2010 at 10:16 AM.
#!/bin/dash
for pids in $(ps -eo pid,user,rss,comm --sort=-rss --no-headers | head -n 10 | awk '{print $1}'); do
files=/proc/$pids/smaps
echo
echo "###### File: $files ( Process: $(ps -p $(echo "$files" | cut -f3 -d/) -o comm= 2>/dev/null) ) ######"
echo
cat /proc/$pids/smaps | grep -- '-\|Rss\|Swap' | sed '/^.* 0 kB/d'
echo
done | less
To scan the top 10 /proc/<pid>/smaps files of the processes outputted by that `ps --sort rss` command, and print the parent process-name, subprocesses/libraries, and Rss/Swap values. I've sedded out any 0kB lines just to reduce the total lines output. The results are some 4100+ lines just for these top 10 processes, but here's a sample of a process (Xorg) with some particularly large values (of course - X was the first process outputted by `ps`):
So, I dunno if this really proves anything we don't already know by looking at the `ps` output in Post#10 above, except to break down the Xorg process and see "what about X" is consuming the most resources (and keep me occupied for a while).
Note that a lot of the sub-processes don't even show what they are by name, only by that "7f15c6a9a000-7f15d8216000 rw-p 00000000 00:00 0" identifier, whatever that is..
This is all I've done since post#10, so still hafta look into that other sysctl stuff. More later.
Last edited by GrapefruiTgirl; 07-22-2010 at 11:27 AM.
So per that page, I did a `sync` and then echoed "3" into /proc/sys/vm/drop_caches and the result on RAM was similar to as if I had closed Firefox (tiny bit of RAM freed), and swap remains unchanged:
Next I'll be logging out & back in (and/or if necessary, going to init1 and back again) and following that, rebooting if RAM is still full. Then later on, I'll look up `collectl`
As an intermediate step, how about simply restarting Xorg?
Yup, that's why I'll be logging out, since X can't much be restarted while I'm logged into it.
Will post the `free` after I do that - first gotta look around and see what I've got running on some other desktops so I know what was going on before I log out, so I can get them going again after logging back in.
Yup, that's why I'll be logging out, since X can't much be restarted while I'm logged into it.
If you haven't logged out yet it might be interesting to copy /proc/slabinfo to some file before restarting X and to a different file after restarting X and see how those two files compare.
The info you have posted makes it look like Xorg is most of the problem, but not all of the problem. So I'm wondering whether the rest of the problem is some kernel memory use that Xorg causes. Hopefully kernel memory uses associated with Xorg would go away when Xorg does.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Existeth a way to 'clear out' all the old/cached crap from RAM/SWAP to free up space?
) but I'll have to dig around about the collectl and drop_caches; no idea what they're about!
