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.

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"

Reply via email to