On Fri, 24 Jan 2020 12:59:41 +0000, Jan Panteltje wrote:

> So it is a swap file... did not even know that.

You can run without swap. The command swapoff disables swapping and swapon
(re)enables it. It can also be permanently disabled by editing the boot
parameters / scripts/ services (depending on which Linux you're using.

> Anyways it does not explain why all programs now seem to use swap space.
> I did the following as test / solution perhaps:
>
I think you may be misreading the 'top' display. There are two lines that
show this type of information:

MiB Mem :  7647.2 total,   4483.4 free,  1206.3 used,   1957.5 buff/cache
MiB Swap: 16500.0 total,  16500.0 free,     0.0 used.   6325.5 avail Mem

The above is from this Lenovo T440, which has 8GB RAM and a 16GB swap
partition on its hard drive.

You can also see just these two lines by running 'free -h'.

The first of these lines describes how RAM is being used: 'buff/cache' is
the amount of RAM occupied by file buffering and other data that isn't
owned by any specific process.

The second line describes swap space: its used space is non-zero only
when a process has caused RAM to be oversubscribed. The kernel will first
try to free up RAM by discarding any file blocks that have only been
read. If this doesn't release enough RAM then disk blocks that are full
but not yer written out and written out and released. If more RAM is stil
needed, then excess code and heap data in the requesting process is
written to swapspace and is subsequently paged in/written out as needed.
Swap space will be released when that process terminates.

Note the order: Fast operations are always done first, followed by slower
ones of the previous operations didn't make enough RAM available to the
requesting process.

Note also, that small files (both code images and data) will tend to end
up entirely on buffer space and will stay there even after the requesting
process has ended - until something needs to use the RAM they're
occupying. You can see this happening on a system with enough memory: its
why, if you're developing a reasonably large C (or Java) application,
the first compile of the day is several times slower than the rest: for
subsequent compilations your editor, 'make', the Makefile, the C compiler
and the source files you're working on are already buffered in memory and
don't need to be re-read from disk.

> But IMO this is a basic problem in Linux.
> An ever growing swap space usage is a killer in the long run,
> be it in a file or on a disk.
>
Nope it isn't because what you thought was swap space isn't, and
I've never seen properly configured swapspace (i.e. RAM * 2) get filled.

The nearest I've seen to this is when a process exceeds its configured
maximum virtual memory size. If this happens it will be killed by the
kernel. The virtual memory size of a process is the total of RAM used
plus swap space used. This is a limit enforced by the kernel - it can
happen to any program that can grow to accommodate arbitrary amounts of
data: I've only seen this happen to a Java 1.4 application of mine
running on a 32 bit system. The cause was the garbage collector failing
to clear released heap-space as fast as the program was grabbing new heap-
space and loading more data into it. That has never been an issue since
Java 1.6 and its improved garbage collector were released.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05