Amnesia FreeBSD

I never understood how memory allocation works in FreeBSD. Of the variety of documentation useful remembered only

This is not a true hilarion, but it was not true. It was keeping track of what was going on.

Well, better than Linux, and so be it. I'm not against. But worse than the most incomprehensible process of memory allocation, I was killed by Inactive memory. What is it and is it possible to use “it” painlessly? Is this memory available for use by the application?

Under the cut'om more questions than answers.

The FreeBSD FAQ reports that

16.2.
')
Why doesn’t it show very little free running memory even when I have very few programs running?

The simplest answer. Any memory that has been used for the FreeBSD kernel as disk cache. The values ​​are shown by top, (1) labeled as Inact, Cache, and Buf It has been recently received, it has recently been received. In general, it is shown that it is not very low.

Well, let it be some level cache, but why not put this Inact memory in Cache ? Maybe because it is available for use (as claimed by numerous members of the forum) and even if not immediately, but can be allocated on request?

Let's try to figure it out in a practical way. We have:

# top -b 0 last pid: 1019; load averages: 0.21, 0.45, 0.24 up 0+00:03:33 14:26:30 28 processes: 1 running, 27 sleeping Mem: 18M Active, 17M Inact, 130M Wired, 24M Buf, 3756M Free Swap: 3852M Total, 3852M Free 

That is, almost all memory is Free and the swap is completely free.
Now, to use the available memory, create a tmpfs partition.

 # mkdir /tmp/gb # mount -t tmpfs -o mode=01777,size=3221225472 tmpfs /tmp/gb # df -h | egrep "(Filesystem|tmpfs)" Filesystem Size Used Avail Capacity Mounted on tmpfs 3.0G 4.0K 3.0G 0% /tmp/gb 

Wherein

 # top -b 0 last pid: 1028; load averages: 0.09, 0.19, 0.17 up 0+00:09:30 14:32:27 28 processes: 1 running, 27 sleeping Mem: 18M Active, 17M Inact, 130M Wired, 24M Buf, 3756M Free Swap: 3852M Total, 3852M Free 

I agree, since the section is simply created / mounted, but free, there is no need to allocate memory to it.
Put the file in it.

 # dd if=/dev/urandom of=/tmp/gb/file.txt bs=1M count=3k 3072+0 records in 3071+0 records out 3220176896 bytes transferred in 53.334672 secs (60376801 bytes/sec) # df -h | egrep "(Filesystem|tmpfs)" Filesystem Size Used Avail Capacity Mounted on tmpfs 3.0G 3.0G 1.0M 100% /tmp/gb 

3 gigabytes of memory is busy, but at the same time

  # top -b 0 last pid: 1040; load averages: 0.19, 0.26, 0.20 up 0+00:16:40 14:39:37 28 processes: 1 running, 27 sleeping Mem: 18M Active, 3088M Inact, 137M Wired, 24M Buf, 677M Free Swap: 3852M Total, 3852M Free 

for some reason they are considered Inact . But since it is not Active, then we will try to set it up. Sketch a small “Hello, world!” To allocate memory and then free it:

 #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> int main (int argc, char *argv[]) { int i; char *buffer[64]; long lSize = 1024*1024*1024; int iMB = argc < 2 ? 1 : atoi(argv[1]); printf("iMB:\t%d\n", iMB); for(i=0; i < iMB; i++) { buffer[i] = (char*) malloc (lSize); if(buffer[i] != NULL) { printf("Alloc: %d\n", i); memset(buffer[i], 127, lSize); } else printf("Error!\n"); sleep(1); } sleep(10); for(i=0; i < iMB; i++) { printf("Free: %d\n", i); free (buffer[i]); } return 0; } 

 # time ./a.out 3 iMB: 3 Alloc: 0 Alloc: 1 Alloc: 2 Free: 0 Free: 1 Free: 2 0.915u 1.475s 1:00.16 3.9% 5+168k 0+0io 0pf+0w 

Why so long? Probably our tmpfs, supposedly in Inactive, were being squeezed into a swap.

Indeed, when allocating memory (the moment “sleep (10);” in the code) we see:

 # top -b 0 last pid: 1128; load averages: 0.02, 0.11, 0.14 up 0+00:28:34 14:51:31 37 processes: 1 running, 36 sleeping Mem: 3106M Active, 621M Inact, 155M Wired, 26M Cache, 27M Buf, 14M Free Swap: 3852M Total, 2502M Used, 1350M Free, 64% Inuse 

But worse is another. After freeing the memory by the application:

 # top -b 0 last pid: 1129; load averages: 0.09, 0.12, 0.15 up 0+00:28:48 14:51:45 36 processes: 1 running, 35 sleeping Mem: 33M Active, 621M Inact, 145M Wired, 26M Cache, 27M Buf, 3095M Free Swap: 3852M Total, 2502M Used, 1350M Free, 64% Inuse 

swap remained involved.
File accesses are back to Inact

 # time dd of=/dev/zero if=/tmp/gb/file.txt bs=1M count=3k 3071+0 records in 3071+0 records out 3220176896 bytes transferred in 40.265654 secs (79973292 bytes/sec) 0.008u 3.796s 0:40.26 9.4% 22+154k 0+0io 0pf+0w # time dd of=/dev/zero if=/tmp/gb/file.txt bs=1M count=3k 3071+0 records in 3071+0 records out 3220176896 bytes transferred in 1.242623 secs (2591434941 bytes/sec) 0.000u 1.241s 0:01.24 100.0% 25+173k 0+0io 0pf+0w # top -b 0 last pid: 1144; load averages: 0.09, 0.12, 0.14 up 0+00:36:22 14:59:19 36 processes: 1 running, 35 sleeping Mem: 29M Active, 3077M Inact, 146M Wired, 4K Cache, 27M Buf, 669M Free Swap: 3852M Total, 2502M Used, 1350M Free, 64% Inuse 

At the same time, it is not clear why there was Swap: 2502M Used

But, let's say, this is normal and, if there is a free swap, you can consider this involved memory as inactive and mark it as Inact . What happens if we don't have a swap? Hopefully now the memory involved will now be Active .
We remove the swap, similarly mount the 3Gb tmpfs section and fill it.

 # top -b 0 last pid: 1013; load averages: 0.58, 0.53, 0.29 up 0+00:05:03 15:11:46 34 processes: 1 running, 33 sleeping Mem: 21M Active, 3089M Inact, 138M Wired, 24M Buf, 673M Free Swap: 

To clear your conscience, make sure that top doesn't lie:

 # expr `sysctl -n vm.stats.vm.v_inactive_count` \* `sysctl -n vm.stats.vm.v_page_size` 3239620608 

And, despite the lack of a swap, our busy memory is still not quite active ... Since it is not active, we will try to reuse it with our application.

 # ./a.out 3 iMB: 3 Alloc: 0 Killed 

PM and finally:

 # top -b 0 last pid: 1026; load averages: 0.15, 0.22, 0.21 up 0+00:11:37 15:18:20 34 processes: 1 running, 33 sleeping Mem: 3102M Active, 1524K Inact, 138M Wired, 200K Cache, 24M Buf, 679M Free Swap: # expr `sysctl -n vm.stats.vm.v_inactive_count` \* `sysctl -n vm.stats.vm.v_page_size` 1720320 

There must be some conclusion, but it is not ...