topic Re: cpview(mem) vs free in Firewall and Security Management

cpview(mem) vs free

Andrew25 — Fri, 15 Dec 2017 09:48:29 GMT

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?

Re: cpview(mem) vs free

Tom_Cripps — Fri, 15 Dec 2017 13:15:41 GMT

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.

Re: cpview(mem) vs free

Timothy_Hall — Fri, 15 Dec 2017 13:37:44 GMT

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

Re: cpview(mem) vs free

Andrew25 — Fri, 15 Dec 2017 13:52:18 GMT

Thanks for the help and explanation.

Re: cpview(mem) vs free

Onur_Akok — Wed, 04 Sep 2019 06:09:17 GMT

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

Re: cpview(mem) vs free

genisis__ — Tue, 20 Jan 2026 13:24:21 GMT

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)

Re: cpview(mem) vs free

Don_Paterson — Tue, 20 Jan 2026 14:15:37 GMT

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.

Re: cpview(mem) vs free

genisis__ — Tue, 20 Jan 2026 14:19:37 GMT

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.

Re: cpview(mem) vs free

Bob_Zimmerman — Tue, 20 Jan 2026 15:03:43 GMT

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.

Re: cpview(mem) vs free

Don_Paterson — Tue, 20 Jan 2026 15:11:21 GMT

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?

Re: cpview(mem) vs free

genisis__ — Tue, 20 Jan 2026 21:49:55 GMT

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.

Re: cpview(mem) vs free

Bob_Zimmerman — Tue, 20 Jan 2026 22:34:07 GMT

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.

Re: cpview(mem) vs free

Don_Paterson — Wed, 21 Jan 2026 07:25:45 GMT

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.

Re: cpview(mem) vs free

Bob_Zimmerman — Wed, 21 Jan 2026 16:44:15 GMT

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.

Re: cpview(mem) vs free

Don_Paterson — Wed, 21 Jan 2026 16:55:46 GMT

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