On a sunny day (Fri, 24 Jan 2020 14:48:41 -0000 (UTC)) it happened Martin
Gregorie  wrote in :

>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.

OK, understood,
I will keep monitoring the system
free -h is nice too.

--- SoupGate-Win32 v1.05