Hello,
any ideas why my system is using nearly the whole amount of RAM (8GB) ?
I'm runnig ubuntu 7.10,
my system hw:2x Xeon 2.2 GHz, 8GB RAM ...
I running only MySQL.
Today morning I was checking it and it was using about 2.5 GB RAM, then I copied one file cca 200GB from another system to linux share and now it's using nearly all RAM.
Is there a way to release it or clean it?
Thanks.

Radek

It's normal. Linux aggressively allocates RAM to disk cache and there is no good reason to freeing it up again until it is needed by some other process. As other processes need RAM, the balance between disk cache and process allocation will be managed.

In short, don't worry.

Thanks Matthew,
so I'll just keep an eye on it.
Radek

If the machine is a server, knowing a few command line monitoring tools is a good thing (command line so you can just ssh into your machine and check out what is going on).

For getting a system overview I like htop. It's not usually installed by default, but I think the extra features over it's more traditional cousin top are worth it.

Yes,
I'm using htop, it's ok....that's why I was quite suprised that system is using nearly 8GB if I didn't see any process in htop which would use it...
Radek

Run 'free' in a terminal. It'll give you something like:
The real free memory is the 880724 under '-/+ buffers/cache'. This is the important value. Don't worry about the others, as said before, cached memory is freed on demand by the kernel ... it's done this way to make your system more responsive. Trust Linus T., he knows what he's doing

here it is:

Hi I got permission denied even i run on Root User
if changed the permission on this file to be able to execute, is it kind of dangerous ?


-su: /proc/sys/vm/drop_caches: Permission denied

Why would you want to do this ? This will only slow your computer down.

here is why, I got 32GB of RAM
but the cached memory is like 98%!

pache:~# free -t -m
total used free shared buffers cached
Mem: 28429 27780 648 0 21 27277
-/+ buffers/cache: 481 27947
Swap: 7632 0 7632
Total: 36061 27780 8281


top - 16:59:05 up 90 days, 9:10, 2 users, load average: 5.57, 3.26, 4.70
Tasks: 142 total, 1 running, 141 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.5%us, 1.3%sy, 0.0%ni, 96.3%id, 1.8%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.5%us, 1.3%sy, 0.0%ni, 96.3%id, 1.8%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.4%us, 1.1%sy, 0.0%ni, 96.7%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.4%us, 1.0%sy, 0.0%ni, 96.9%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.7%us, 1.5%sy, 0.0%ni, 96.2%id, 1.6%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.7%us, 1.5%sy, 0.0%ni, 96.2%id, 1.6%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.7%us, 1.6%sy, 0.0%ni, 96.1%id, 1.6%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.7%us, 1.5%sy, 0.0%ni, 96.1%id, 1.6%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 29111732k total, 28514000k used, 597732k free, 24696k buffers
Swap: 7815580k total, 96k used, 7815484k free, 28124280k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29275 mysql 20 0 203m 78m 6072 S 16 0.3 50:06.64 mysqld
374 root 15 -5 0 0 0 S 1 0.0 160:02.59 kswapd0
24857 www-data 20 0 38192 11m 5256 S 1 0.0 0:00.10 apache2
25360 www-data 20 0 46856 19m 4820 S 1 0.1 0:00.06 apache2
108 root 15 -5 0 0 0 S 0 0.0 0:45.88 kblockd/1
556 root 39 19 0 0 0 S 0 0.0 288:06.14 kipmi0
1 root 20 0 2096 720 620 S 0 0.0 0:29.49 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:03.74 migration/0
4 root 15 -5 0 0 0 S 0 0.0 1:37.47 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:04.62 migration/1
6 root 15 -5 0 0 0 S 0 0.0 2:24.71 ksoftirqd/1
7 root RT -5 0 0 0 S 0 0.0 0:04.68 migration/2
8 root 15 -5 0 0 0 S 0 0.0 5:52.96 ksoftirqd/2
9 root RT -5 0 0 0 S 0 0.0 0:05.20 migration/3
10 root 15 -5 0 0 0 S 0 0.0 2:36.13 ksoftirqd/3
11 root RT -5 0 0 0 S 0 0.0 0:05.62 migration/4
12 root 15 -5 0 0 0 S 0 0.0 1:42.19 ksoftirqd/4
13 root RT -5 0 0 0 S 0 0.0 0:07.10 migration/5
14 root 15 -5 0 0 0 S 0 0.0 2:32.61 ksoftirqd/5
15 root RT -5 0 0 0 S 0 0.0 0:07.64 migration/6
16 root 15 -5 0 0 0 S 0 0.0 7:36.53 ksoftirqd/6
17 root RT -5 0 0 0 S 0 0.0 0:04.62 migration/7
18 root 15 -5 0 0 0 S 0 0.0 2:22.17 ksoftirqd/7
19 root 15 -5 0 0 0 S 0 0.0 1:28.39 events/0
20 root 15 -5 0 0 0 S 0 0.0 1:42.71 events/1
21 root 15 -5 0 0 0 S 0 0.0 1:40.86 events/2
22 root 15 -5 0 0 0 S 0 0.0 1:38.15 events/3
23 root 15 -5 0 0 0 S 0 0.0 1:31.69 events/4
24 root 15 -5 0 0 0 S 0 0.0 1:47.40 events/5
25 root 15 -5 0 0 0 S 0 0.0 2:05.61 events/6
26 root 15 -5 0 0 0 S 0 0.0 1:45.27 events/7
27 root 15 -5 0 0 0 S 0 0.0 0:00.00 khelper
107 root 15 -5 0 0 0 S 0 0.0 0:42.51 kblockd/0
109 root 15 -5 0 0 0 S 0 0.0 0:45.26 kblockd/2
110 root 15 -5 0 0 0 S 0 0.0 0:49.85 kblockd/3
111 root 15 -5 0 0 0 S 0 0.0 0:38.88 kblockd/4
112 root 15 -5 0 0 0 S 0 0.0 0:49.23 kblockd/5




Please help !?

thanks,
Seth

So 0.02*32 = 0.64, so processes are using about 1/2 a gig of ram. That sounds reasonable.

And the unused ram is caching files from disk. Are you saying that you would rather have that ram doing nothing instead of caching? You would rather you machine have to reread from disk instead of from that nice big whack of RAM you have?

Evo2.

1 members found this post helpful.

cached memory is freed as needed, there's no need to worry about it.

Howabout you read this thread.

I would beg to differ. It is supposed to free memory but it does not always do this. Doing free -m does show cache memory as available but when memory gets down to 100k the system goes to crap even though it says I should have 7gb available to programs.

The entire machine starts lagging. We mainly have long running java processes, apache and mysql running and are using Cent OS 5 x64 with 12gb of ram. We've had this issue on 3 different machines all with different specs.

Once the disk cache eats all the memory apache starts timing out and lagging to like 10 seconds for a response and the entire machine feels like a p4 even though it's a dual quadcore. We've had mysql table's corrupted and it has even crashed our java processes.

Clearing the cache immediately puts everything back to peppy normal operation. Instant page loads etc.

It always seems to be worse when running apache but I think that's just because it causes more data to be cached because of high usage of vbulletin so the disk cache eats mem more quickly.

If anyone has any ideas?

Clearing the cache works perfectly though and we've never had an issue from using: sync; echo 3 > /proc/sys/vm/drop_caches

I not normally a fan of resurrecting dead threads, but you're destroying potential evidence doing that. Try echo-ing "1" and see if it has the same effect.
What is you swappiness value ?.