OPNSense Memory Reporting in Lobby (Outdated?)

[tmanok]

Hey Everyone,

Today I was startled by one of my routers indicating 90% memory usage, but after running vmstat -m (too noisy), top, and htop for good measure. While htop considered my usage (denoted in green) to be just 1.16GB (16%), top was rather more informative:

• 6441M Wired
• 472M Free
• ARC: 5328M

Ok so what I understood, is that ZFS is the primary cache hog, while other file system or process caches make up the rest. In this particular case, I agree that the OPNSense web interface reporting was somewhat accurate, or possibly on par. However, even ARC cache can be dropped, so maybe the web interface should be updated to ignore ARC caches, now that ZFS is being officially supported by OPNSense in the installer.

Cheers, please feel free to let me know your thoughts.


Tmanok

[Patrick M. Hausen]

What's the problem with a reported 90% usage? All modern operating systems try to use all available memory for cache. Free memory is wasted memory.

[tmanok]

Hi Paul,

I believe that, you have misread what I have written:
"maybe the web interface should be updated to ignore ARC caches, now that ZFS is being officially supported by OPNSense in the installer." As you can see, I'm not asking for the system to use memory differently, I'm asking for reporting to match newly supported features. In this case, to ignore ZFS ARC caches, like any OS would not call disk buffers or caches to be application memory. Perhaps because of the importance of ARC caches, the community may disagree (fair, they are much less likely to be dropped for other processes).

Additionally, you seem to have assumed my my position on something unrelated to my question. I don't care that the memory is cached or buffered, because cached memory will "move out of the way" for application memory. My concern is how the Dashboard reports memory usage. There is a big difference between 90% memory usage when it is actively in use by say ClamAV or routing algorithms, than when there is a file buffer temporarily residing in memory. The former could lead to a kernel panic, while the latter gives me a performance increase. My question to the community is whether we should treat ARC cache like ordinary file system buffers. If they are going to be kept however, perhaps there should be a more specific indication of what portion is used by applications vs ARC.

Cheers,


Tmanok

[cookiemonster]

I don't believe htop has historically reported ARC use so top was the accurate of the two.
But used ARC is used memory, so the UI is reporting correctly.
I fail to follow the thinking that because ZFS is supported, the usage of the ARC should not be reported in the UI.

[tmanok]

Hi CookieMonster,

As I said, caches can be dropped, so reporting them as memory usage is "dangerous", for example in htop they are highlighted in yellow for caches, in TrueNAS they are designated a separate colour from real memory usage as well. Clearly, mature systems that have integrated ZFS have decided to differentiate the reporting of ARC cache.
Cheers,


Tmanok

[franco]

What's our goal post for "mature ZFS integration in FreeBSD"? Is that some sort of Linux-y way of inferring non-Linux doesn't do it (yet) or just a matter of where this information is found in FreeBSD to be able to display it? We can get past of a lot of discussion by pointing to the command that does what you expect within FreeBSD base (which isn't htop).


Cheers,
Franco

[tmanok]

Hi Franco,

Thanks for your reply. FreeBSD is very mature with ZFS, it has had it since well before Linux ever did if I understand correctly. For example FreeNAS (TrueNAS) and NAS4Free (XigmasNAS) have had it for a long time.

I think the point here is to say that OPNSense has not had it for very long and that there are some features to be added such as pool management, scrub tasks, dataset manipulation, pool status, and more granular memory monitoring (to name a few) to be featured in the the GUI.

Thanks,


Tmanok