Hi all,

I have 64 bit Debian-Squeeze running with 16 GB RAM and 25 GB Swap. Normally up to 5 GB RAM is in use, no Swap.

But this morning I have seen 58 KB swap used. Swapiness is 60. So either the RAM has grow up this night or .. I dont know.

top
Mem: 16473264k total, 1069824k used, 15403440k free, 189292k buffers
Swap: 25149432k total, 58260k used, 25091172k free, 411852k cached

Also, the Swap-Cached in top is growing ervery time. So I have panic, that the system will have problems in a few days or weeks.

Is there any tool to monitore the RAM usage? Or to see whitch application has used the Swap-Partition?

Beacuse I want to see and know whats going on on my server :-)

Thanks

if you have a process eating up the memory you can see it with top.
(that is 58M, not 58 KB)

That is totally normal. The Linux kernel swaps out memory pages that weren't used for a long time to use that memory for caching. No problems on your machine.

1 members found this post helpful.

I agree with TobiSGD's answer.

Some extra detail:

Apparently cache use grew. It tends to gradually do that as a system with excess ram (compared to workload) stays up.

If you saw a big change over night, that tends to mean some scheduled task does a lot of file I/O, which is probably normal.

Any anonymous memory of processes that had been idle for a long while before that burst of file I/O will be swapped out. When you resume using those processes again, there will be a moment of poor responsiveness as those pages come back in. So far as I know, there isn't a good way to tune that sub optimal behavior out (but people try a lot of bad ways, doing more harm than good). It generally is NOT a big enough problem to care about.

Generally some anonymous pages of some services are stale data (typically left over from the service startup). Once cache usage has been high enough (whether gradually or due to a big burst of file I/O) those pages stay in swap, because nothing ever needs them in ram.

Some of the 58MB you see is stale data with no reason to come back into ram. Maybe some of it belongs to some service that hadn't been touched again after whatever file I/O kicked. 58MB is small enough that the delay to bring it back will be trivial if whatever service owns that data resumes work.

1 members found this post helpful.