plenty of memory, but system us intensively swapping

Eugene M. Zheganin eugene at zhegan.in
Tue Nov 20 11:38:54 UTC 2018


Hello,

On 20.11.2018 16:22, Trond Endrestøl wrote:
>
> I know others have created a daemon that observe the ARC and the
> amount of wired and free memory, and when these values exceed some
> threshold, the daemon will allocate a number of gigabytes, writing
> zero to the first byte or word of every page, and then freeing the
> allocated memory before going back to sleep.
>
> The ARC will release most of its allocations and the kernel will also
> release some but not all of its wired memory, and some user pages are
> likely to be thrown onto the swap device, turning the user experience
> to a mild nightmare while waiting for applications to be paged back
> into memory.
>
> ZFS seems to be the common factor in most, if not all, of these cases.
>
> I created my own and not so sophisticated C program that I run every
> now and then:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> int main(int argc, char **argv)
> {
>    const size_t pagesize = (size_t)getpagesize();
>    const size_t gigabyte = 1024ULL * 1024ULL * 1024ULL;
>
>    size_t amount, n = 1ULL;
>    char *p, *offset;
>
>    if (argc > 1) {
>      sscanf(argv[1], "%zu", &n);
>    }
>
>    amount = n * gigabyte;
>
>    if (amount > 0ULL) {
>      if ( (p = malloc(amount)) != NULL) {
>        for (offset = p; offset < p + amount; offset += pagesize) {
>          *offset = '\0';
>        }
>
>        free(p);
>      }
>      else {
>        fprintf(stderr,
>                "%s:%s:%d: unable to allocate %zu gigabyte%s\n",
>                argv[0], __FILE__, __LINE__,
>                n, (n == 1ULL) ? "" : "s");
>        return 2;
>      }
>    }
>    else {
>      return 1;
>    }
>
>    return 0;
> } // main()
>
> // allocate_gigabytes.c
>
Jeez, thanks a lot, this stuff is working. Now the system has 8 Gigs of 
free memory and stopped swapping.

Well, the next question is addressed to the core team which I suppose 
reads this ML eventually - why we don't have something similar as a 
watchdog in the base system ? I understand that this solution is 
architecturally ugly, but it's now worse not to have any, and it still 
works. At least I'm about to run this periodically.

Trond, thanks again.

Eugene.



More information about the freebsd-stable mailing list