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? Here's current stats: Code:
sasha@reactor: uptime 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. |
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 :p ) but I'll have to dig around about the collectl and drop_caches; no idea what they're about!
|
Quote:
Quote:
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 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. |
Here's an anomaly for you
On my PC, Ksysguard reports ~778MB used out of 3GB while free reports ~3GB used out of 3.1GB Code:
[david@archangel macros.d]$ free 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. http://dl.dropbox.com/u/8825098/kinfocenter-mem.jpg |
Quote:
|
Good call. I wasnt reading so closely but now that you mention it...
Code:
-/+ buffers/cache: 3486832 571164 |
drop_caches is a sysctl - have a look in "man proc". collectl is a stand-alone tool - very handy.
For something simple try this Code:
ps -eo pid,user,rss,comm --sort=-rss | head -n 10 |
Quote:
Quote:
Quote:
|
Quote:
Code:
root@reactor: 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 Thanks for the input so far you guys. |
I've used the following:
Code:
#!/bin/dash Code:
####### File: /proc/818/smaps ( Process: X ) ####### 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. |
Next thing tried:
Looked up vm.drop_caches via Google and got this: http://www.linuxinsight.com/proc_sys...op_caches.html 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: Code:
root@reactor: echo 3 > /proc/sys/vm/drop_caches |
As an intermediate step, how about simply restarting Xorg?
|
Quote:
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. |
Quote:
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. |
All times are GMT -5. The time now is 02:50 AM. |