cpview(mem) vs free

[Andrew25]

Why do free and cpview give different results for loading memory?

for example:

cpview

                     total     used      Free

Physical     31 914   19 969   11 900

free

total used free shared buffers cached
Mem: 32680404 32012872 667532 0 360916 11096040

Whom to believe? and because of what is happening?

[Tom_Cripps]

It's because CPView is displaying in MB where free on it's own will use KB, you can use free -m for Megabytes or even free -g for Gigabytes.

Hope this helps.

[Timothy_Hall · Accepted solution]

The various Check Point tools like cpview, when reporting the value for "free", do not distinguish between memory allocated for code execution vs. memory allocated for buffering/caching.  Memory allocated for the latter can be swiped at any time for code execution if needed.  So the free value reported by cpview reveals the amount of memory not being used for anything at all. 

If you look at the full output for free -m like this:

                                   total       used       free     shared    buffers     cached
Mem:                          7843       7678      165          0         28            2122
-/+ buffers/cache:                      5527       2316
Swap:                          8189          0       8189

Looking at the "Mem" line you might panic because it looks like there is very little free memory (165MB).  The line you want to look at to see how much memory is actually available for code execution if needed is "-/+ buffers/cache".    As we can see 5527MB is actually being used for code execution with 2316MB used for caching & buffering and unused (28+2122+165 from line 1).  So if more memory is needed for code execution 2316MB is available, not 165MB as reported on the first line (and by the various Check Point tools).

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[Andrew25]

Thanks for the help and explanation.

[Onur_Akok]

Same issue - The different memory shown between free -m command and Cpview - we see on our Smartcenter.
Thanks for explanation
[Expert@sisefw:0]# free -m
total used free shared buffers cached
Mem: 32053 31627 426 0 120 22346
-/+ buffers/cache: 9160 22892
Swap: 17422 0 17421
[Expert@sisefw:0]#

----------------------------------------------------------------------------------------------------------------------------------------------------------|
| CPU: |
| |
| Num of CPUs: 8 |
| |
| CPU Used |
| 2 50% |
| 3 37% |
| 5 33% |
| --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Memory: |
| |
| Total MB Used MB Free MB |
| Physical 32,053 9,163 22,889 |
| Swap 17,422 0 17,421

[genisis__]

Tim,

I've noted that the fields have changed slightly on R82 (to be fair, I've not noticed it even in R81).

# free -h

                            total        used        free      shared  buff/cache   available

Mem:                 61G         47G        1.5G        1.8G         13G         11G

Swap:                31G        1.8G         30G

So in this case I think the actually memory available for code execution is 1.5+13+11= 25.5GB, have I got that correct?  If so, then I would have about 40% of memory that can still be used.

Our issue is a third-part NMS monitoring for actual free memory before flagging an issue.

Current Checkpoint's answer is use Skyline - which is not really the answer I was expecting (CPU usage monitoring on VSX, as everything is pretty much in UPPAK now)

[Don_Paterson]

Are you livening this old thread up? Just curious. I've been looking into this and swap more closely.

I think that the newer Linux version is reporting it differently now.

I believe free is completely unused RAM and immediately available.

available (11 GB) is the amount of memory the Linux kernel estimates it can allocate to new processes right now without reclaim pressure or swapping.

buff/cache (13 GB) is kernel cache; much of it is reclaimable if needed, and most of the 11 GB available comes from this cache, with a portion withheld for kernel safety.

[genisis__]

Hey Don,

All stems from out NMS no longer reporting correctly since moving to R82,  I have opened a TAC case as well, hence was not impressed on the response from TAC.

So I though I would just double check what I thought was correct.
So basically free + buff/cache+available = what the system can use without hit swap.

[Bob_Zimmerman]

No, "avail" is the value you want. Don't add anything to it. It's already the free memory plus the immediately purgeable buffers/cache.

[Don_Paterson]

I think it is the available that is key - as Bob just said.

Is the NSM using the wrong reading/s? Same for cpview...

I guess the questions are:

In modern Linux it seems like free is supposed to be small and the system efficiently uses RAM (used) for caching and other optimisations?

Should it be based on available instead?

[genisis__]

I think the issue here is Checkpoint, to my knowledge, has not given us any clear guidance to adjust SNMP monitoring via an SK and if there are now updated OIDs we should be using.

I think this would be very helpful to us all.  The current guidance, I've had through TAC is use Skyline..umm not really helpful or practical to large organisation who have invested allot of funds in enterprise level tooling.

[Bob_Zimmerman]

You should get telemetry from your firewalls in the same way you get it from other Linux servers. Prometheus and Grafana are two of the biggest tools for collecting and analyzing Linux telemetry in the last 20 years. That is the enterprise-level option. Unfortunately, Skyline is still pretty flaky in my environment (various processes keep stopping, but without leaving core dumps).

SNMP is okay, but I have never seen an SNMP system which worked well out of the box for server telemetry. They're all focused on legacy routers, so they start by monitoring metrics which are either irrelevant or actively misleading, like free memory.

For memory saturation, the best signal to monitor is swap use. If the system isn't swapping, you're good. If it starts swapping, you should look for memory leaks and/or get more RAM.

[Don_Paterson]

Can a bit of swap space being used be acceptable, with the theory that modern Linux is efficiently storing some of what's unused (cold) in swap space and making space available?

I've got an 8G RAM R82 SMS in the lab that uses swap space and it seems to have no affect on the performance of the SMS. 

It isn't doing very much. 3 Gateways and two policy packages and running Compliance 

The R81.20 didn't seem to swap and so that is why I've been looking into this. 

[Bob_Zimmerman]

If performance is acceptable, then it ultimately doesn't matter if swap is used or not. Swap use is just the signal that memory saturation may cause performance to become unacceptable in the future.

With how the LLM bubble has wrecked RAM prices, I wouldn't necessarily object to some swap use as long as it's stable.

[Don_Paterson]

Makes sense. Thanks.

I've opened a new thread to talk swap. Although I am selfishly looking to understand it in a specific lab scenario.

https://community.checkpoint.com/t5/Management/R82-using-more-swap-than-R81-20/m-p/268064