i leave my pc on overnight and when i wake up and look this is the results from top
Mem:256376K total, 230208K used, 26168K free, 39948K buffers

that with nothing running except regular stuff, even when i leave X its pretty much the same. when i went to sleep there was practically nothing being used memory wise....it happens every day and thru the day it slowy goes back to normal. why does it do that?? -thanks

It's normal

Linux uses your memory as best it can. So a process that is running will get all your RAM to complete the process. If you aren't doing anything, you still have cron jobs and things like that running that are getting used. As long as you don't experience a lot of lag, don't worry about it. Linux utilizes Ram alot better than 'other' OS's.

Cool

What services are using all this memory? When you run the top command type 'M' to sort by memory usage. You'll see who is the culprit of this memory usage. You can also do 'P' to sort by processor consumption.

just my opinion..
top/free doesn't seem to report exact ram usage..
it's always close to full.
when i ran this
for(;{new a = int [10] }
linux slowed down (almost stop)
and when the code exited with error, memory looked like being cleaned out(a lot of free space) according to top..
so what does that mean?
i don't know

Linux normally 'uses' memory for buffers and cache. That is a different kind of 'uses' than when you're in a microsoft enviroment. It just makes better use of available physical memory. For eg, let your applications stay in memory, just so that in case you decide to use them again, the disk i/o required to do so can be avoided. As a result your app will run faster. That doesn't mean Linux will hold on to those cached locations forever though; it will make way other applications as and when they're loaded.

What you just did asked for a ton of memory so the OS probably cleaned its buffers and cache to satisfy the needs of your app. Your app exceeded the allowable limit, generated the appropriate exception and was TERMinated. All the 'ints' you created were deallocated. So what does that leave you with? A whole lot of free memory that you just snarfed from the heap that was previously used for caching, probably. Which is not a bad thing to do at all, when you _need_ to do it.

That doesnt mean it will stay that way forever. The apps will be cached as soon as you use them, which means your top output will return to what you started with sooner or later. I'd leave the kernel alone when it comes to memory management unless you have a thorough understanding of what's going on behind it.. in which case you are welcome to hack it and make it work the way you want it. If not, whenever something has been done a certain way, it was done was a reason that us mere l'users' weren't smart enough to see. The guys who wrote it know what they were doing.

Watch out for the +/- Buffers/Cache listing on the top header, that is your _real_ memory usage.

13:34:17 up 17:30, 1 user, load average: 0.00, 0.00, 0.00
64 processes: 61 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 3.0% user, 1.6% system, 0.0% nice, 95.4% idle
Mem: 256376K total, 229700K used, 26676K free, 41892K buffers
Swap: 257032K total, 1436K used, 255596K free, 56244K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
12302 brian 12 0 26048 24M 14824 S 1.3 9.7 0:05 mozilla-bin
12304 brian 9 0 26048 24M 14824 S 0.0 9.7 0:00 mozilla-bin
12305 brian 9 0 26048 24M 14824 S 0.0 9.7 0:00 mozilla-bin
12306 brian 9 0 26048 24M 14824 S 0.0 9.7 0:00 mozilla-bin
12307 brian 9 0 26048 24M 14824 S 0.0 9.7 0:00 mozilla-bin
12308 brian 9 0 26048 24M 14824 S 0.0 9.7 0:00 mozilla-bin
12136 root 17 0 48324 14M 2284 R 2.9 5.7 0:06 X
12154 brian 9 0 44472 10M 8704 S 0.0 4.3 0:00 kppp
12165 brian 9 0 43796 10M 8564 S 0.0 4.1 0:00 kdeinit
12163 brian 9 0 7700 7692 7356 S 0.0 3.0 0:00 kdeinit
12160 brian 9 0 7332 7328 7068 S 0.0 2.8 0:00 kdeinit
12157 brian 8 0 6936 6932 6704 S 0.0 2.7 0:00 kdeinit
12155 root 9 0 5484 5472 5076 S 0.0 2.1 0:00 kppp
12143 brian 9 0 3532 3532 2836 S 0.0 1.3 0:00 gkrellm
12147 brian 6 0 3532 3532 2836 S 0.0 1.3 0:00 gkrellm
12342 brian 9 0 3532 3532 2836 S 0.0 1.3 0:00 gkrellm
12142 brian 9 0 2036 2036 1572 S 0.0 0.7 0:00 fluxbox
136 nobody 9 0 1668 1644 1492 S 0.0 0.6 0:00 httpd
137 nobody 9 0 1668 1644 1492 S 0.0 0.6 0:00 httpd
138 nobody 9 0 1668 1644 1492 S 0.0 0.6 0:00 httpd
139 nobody 9 0 1668 1644 1492 S 0.0 0.6 0:00 httpd
12260 brian 9 0 1328 1328 1000 R 0.0 0.5 0:00 aterm
97 root 8 0 1304 1188 964 S 0.0 0.4 0:00 sendmail
12049 brian 9 0 1188 1188 928 S 0.0 0.4 0:00 bash
12261 brian 9 0 1140 1140 892 S 0.0 0.4 0:00 bash
140 nobody 9 0 1380 1104 1060 S 0.0 0.4 0:00 httpd
100 smmsp 9 0 1168 1004 824 S 0.0 0.3 0:00 sendmail
12263 brian 10 0 980 980 768 R 0.1 0.3 0:00 top
12296 brian 9 0 964 964 760 S 0.0 0.3 0:00 run-mozilla.sh
3778 nobody 9 0 944 944 744 S 0.0 0.3 0:00 in.identd
3783 nobody 8 0 944 944 744 S 0.0 0.3 0:00 in.identd
3784 nobody 9 0 944 944 744 S 0.0 0.3 0:00 in.identd
3785 nobody 9 0 944 944 744 S 0.0 0.3 0:00 in.identd



Ok, by memory, the thing is that the little memory marker in gkrellm will grow over night...for instance
before i go to sleep [--|-------]
wake up [-----|-----]
I dont feel any slow down or anything, was just seeing if this was normal. -thanks

Your top listing is perfectly normal.

I would suggest using 'free' if you want to find out how much of your memory is actually being used as opposed to being allocated. Here's what it says for me
total used free shared buffers cached
Mem: 256500 243332 13168 0 113220 22208
-/+ buffers/cache: 107904 148596
Swap: 2048720 2124 2046596

I have 13 megs ( as in million bytes ) of memory 'not being used'. As you can see, the -/+ buffers/cache entry in the listing indicates that I have 148 megs 'free for use when required'.

I have a very similar problem.
I have come to terms with Linux's Over Approach to memory allocation, I belive that that in theory it makes sense.
My problem is that the lovely linux doesn't seem to know when to stop allocating memory.
Specifically I have a system who's cache just rises and rises until eventually there is no room for the kernel to operate and the system crashes.
OOM Killer doesn't work because it's not a process that own's the bulk of the memory.
I find that my cache jumps when a large file is open, say a log file or a 130 minute mp3 file.
This happens on Red Hat 7.2 boxes, on Red Hat 7.3, with all sorts of redhat kernel sub revisions ( basically 2.4.18 ).
Anyone want to point me at some docs or otherwise shed some light?

Anyone else got large files open?

I have seen this happen with Installed memory is from 256 megs to 3 GB. When I say large files I mean 500 megs to 1.2 GB.

As far as I can tell the more and larger files I have open the sooner my system will crash.

help.

my roommate has simmilar problem

if i run something like(we didn't run this, just a program that creates a lot memory)
for(;{
char a = new char[100];
}

my system slows down and the program dies

on the other hand
my roommate's comp halts and he has to reboot.

we have same memory/ he has little bit more swap than i do
his kernel is 2.4.18 on mand8.2

(i didn't have the problem even when i had the same 2.4.18 on mand 8.2)

only difference is kernel options maybe..

we are still wondering what causes the difference.

Whenever I've asked about memory on unix my hidden question are always... are my programs using too much... do I have enough for my system... what is using up all the memory.

Until someone show's me a really good doc on how it all works, what the numbers mean and how to interperate them... I've given up trying to understand it.

However a unix admin here where I work once showed me how you can tell if you need more memory.

run "vmstat 15 > /tmp/vmstat.out" over for a day. Check the si and so (page swaping to disk) if these numbers stay below 300 during heavy usage... your ok for memory. if your idle and they are above 300 you system is starved for memory.

That's my two cents.

For what it's worth:

http://www.oreilly.com/catalog/spt2/chapter/ch04.html