How much memory is this machine using?

Z

zg123

When I tally up the size and res columns, I arrive at the results in the last row:
Code: 
last pid: 26368;  load averages:  0.19,  0.20,  0.19                                                                                                        up 0+13:05:33  09:02:03
24 processes:  1 running, 23 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 7208K Active, 54M Inact, 757M Wired, 139M Free
ARC: 454M Total, 24M MFU, 361M MRU, 6832K Header, 61M Other
     338M Compressed, 754M Uncompressed, 2.23:1 Ratio
Swap: 256M Total, 256M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
26368 root          1  20    0    15M  3592K CPU1     1   0:00   0.03% top
22137 use0          1  20    0    23M    11M select   0   0:00   0.01% sshd
53701 ntpd          1  20    0    20M  7760K select   0   0:03   0.01% ntpd
83097 _pflogd       1  20    0    14M  3052K bpf      0   0:02   0.00% pflogd
33669 root          1  20    0    14M  2808K select   1   0:01   0.00% syslogd
72469 root          1  20    0    15M  3836K select   0   0:03   0.00% devd
60256 root          1  20    0    14M  2568K nanslp   0   0:00   0.00% cron
40344 bind          8  20    0    61M    20M kqread   1   0:00   0.00% named
21953 root          1  21    0    23M    10M select   0   0:00   0.00% sshd
22626 use0          1  24    0    15M  3908K pause    0   0:00   0.00% csh
24724 use0          1  20    0    14M  2920K wait     0   0:00   0.00% su
25237 root          1  20    0    14M  3324K wait     0   0:00   0.00% sh
68308 root          1  20    0    23M    10M select   1   0:00   0.00% sshd
55622 root          1  68    0    13M  2352K select   0   0:00   0.00% hv_kvp_daemon
82291 root          1  68    0    14M  3056K sbwait   1   0:00   0.00% pflogd
89447 root          1  20    0    14M  2304K ttyin    1   0:00   0.00% getty
78550 root          1  68    0    14M  2304K ttyin    0   0:00   0.00% getty
77028 root          1  68    0    14M  2300K ttyin    0   0:00   0.00% getty
76828 root          1  68    0    14M  2300K ttyin    1   0:00   0.00% getty
76175 root          1  68    0    14M  2312K ttyin    0   0:00   0.00% getty
75329 root          1  68    0    14M  2300K ttyin    1   0:00   0.00% getty
77482 root          1  68    0    14M  2300K ttyin    1   0:00   0.00% getty
78396 root          1  68    0    14M  2304K ttyin    0   0:00   0.00% getty
56476 root          1  68    0    13M  2232K select   0   0:00   0.00% hv_vss_daemon
                                 417M  110M
The actual memory size is 1G. Which field of the top output tells me how much RAM is used and how much is free?
 
You only need the RES value.

The display of free memory is not really useful since the OS will look for fluffy things to do with RAM so that it doesn't go unused. That doesn't mean the worlload needs that memory.

The most useful value is the sum of RES. But keep in mind some or much of it might be shared.

Another useful one is how much swap you are using. That is a good indicator of memory pressure.
 
cracauer@ said:
The display of free memory is not really useful since the OS will look for fluffy things to do with RAM so that it doesn't go unused. That doesn't mean the worlload needs that memory.
Click to expand...
Free memory is one of those things that can create 12 arguments among 3 people. Some think "you should always leave 50% free" others "you should always use up all your RAM".

As you noted, swap usage is probably the key indicator one needs more RAM.

Things like ZFS can confuse the issue because under certain workloads full RAM improves performance (ZFS specifically if it's a read mostly workload of the same stuff because ARC/L2ARC is quicker than reading from device).

I think how quickly RAM gets reclaimed is an important parameter; spikes in workload usually need RAM (which is why some say leave 50% free) but if memory can be reclaimed quickly (ARC flush) then use all free RAM.
 
I do wonder what Free actually means these days. Back in the day, top had a field labeled Cache, which was a stock of clean pages ready for instantaneous reallocation; since almost all allocations could made from this stock, FreeBSD could run with around 1% free. Around the time that the laundry queue was implemented, the Cache field disappeared from top and the amount of free memory shown rose very substantially. The free memory sysctl always contained the sum of cache and free, my guess is that top now does the same.

If this is correct, then top's Free might be free memory on ZFS systems that have never run short of memory, but on systems with a enough UFS churn it's likely to be predominately disk cache.
 
fyi,

x@myfreebsd:~/Conf $ ./mymem
Code: 
   Wired:6015M
  Active:20229M
 Laundry:3631M
Inactive:0545M
   Cache:0000M
    Free:1277M
     Gap:0000M
--------------
   Total:31734M

x@myfreebsd:~/Conf $ cat mymem
sh: 
#!/usr/local/bin/zsh

W=`sysctl vm.stats.vm.v_wire_count    | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
A=`sysctl vm.stats.vm.v_active_count  | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
L=`sysctl vm.stats.vm.v_laundry_count | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
I=`sysctl vm.stats.vm.v_inactive_count| gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
C=`sysctl vm.stats.vm.v_cache_count   | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
F=`sysctl vm.stats.vm.v_free_count    | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
T=`sysctl vm.stats.vm.v_page_count    | gawk '{$2=$2*4096/1024/1024;printf("%04.0f\n",$2);}'`
T2="$(( $W + $A + $L + $I + $C + $F))"
G=`echo "$(( $T -$T2))"               | gawk '{$1=$1*4096/1024/1024;printf("%04.0f\n",$1);}'`
echo "   Wired:"$W"M"
echo "  Active:"$A"M"
echo " Laundry:"$L"M"
echo "Inactive:"$I"M"
echo "   Cache:"$C"M"
echo "    Free:"$F"M"
echo "     Gap:"$G"M"
echo "--------------"
echo "   Total:"$T"M"


A.I. :
Free : In FreeBSD, Free memory means purely empty, unallocated memory pages that contain no data at all. It is completely untouched and immediately ready to be assigned to any process or kernel task that requests it. When it's 0 , the system starts swapping.
 
but

sysctl -d vm.stats.vm.v_cache_count
vm.stats.vm.v_cache_count: Dummy for compatibility
Click to expand...
It's likely that the cache queue is entirely gone.

FWIW it's hard to take AI's opinion seriously when it includes something so obviously wrong as: "When it's 0 , the system starts swapping.", it's clearly been trained on some very naive internet content. You place too much faith in AI.
 
AI :

ZFS is designed to listen to kernel memory pressure notifications.

&

Which Pools Can Be Dynamically Reduced?
  • I (Inactive) & L (Laundry): Highly Reducible.
    • I (Inactive): These are clean pages that contain valid data but haven't been used recently. The kernel can instantly wipe them and move them to F (Free) without writing anything to disk.
    • L (Laundry): These are dirty pages (modified data) that haven't been used recently. The laundry thread dynamically cleans these pages by writing them to swap/disk so they can be moved to the I pool and eventually freed.
  • A (Active): Moderately Reducible.
    • These pages are currently in active use. If the system stays under heavy memory pressure, the page daemon will gradually demote the least-recently-used active pages down to the I or L queues so they can eventually be freed.
 
Alain De Vos said:
AI :

ZFS is designed to listen to kernel memory pressure notifications.

&

Which Pools Can Be Dynamically Reduced?
  • I (Inactive) & L (Laundry): Highly Reducible.
    • I (Inactive): These are clean pages that contain valid data but haven't been used recently. The kernel can instantly wipe them and move them to F (Free) without writing anything to disk.
    • L (Laundry): These are dirty pages (modified data) that haven't been used recently. The laundry thread dynamically cleans these pages by writing them to swap/disk so they can be moved to the I pool and eventually freed.
  • A (Active): Moderately Reducible.
    • These pages are currently in active use. If the system stays under heavy memory pressure, the page daemon will gradually demote the least-recently-used active pages down to the I or L queues so they can eventually be freed.
Click to expand...
Again, it's hard to take this seriously when it contains things like "the page daemon will gradually demote the least-recently-used active pages down to the I or L queue" that's true for Linux, but not for FreeBSD.
 
You must log in or register to reply here.
Back
Top