2100: constantly shows high CPU usage

netboy

Hi there , i have netgate 2100 max and the CPU usage is always very high > 90% most of the time.

I do use pfBlockerNG and do not use VPN.

Any help to troubleshoot this issue would be greatly appreciated

I did use the shell command (top -a -o cpu) and discoverd the process ntopng consumes 95% of CPU and DISABLED it.

Observered it went from "9% of your CPU is actually idle" to "51% of your CPU is actually idle"

Is it OK to disable ntopng?

SteveITS

@netboy it’s your choice? You or someone else installed it…? It’s a traffic monitoring program that happens to use a lot of resources and writes to disk a lot.

netboy

@SteveITS Thx

I have also discovered lighttpd_pfb consumes most of CPU. Can i disable this? My understanding is pfBlockerNG does not need this and the browsing experience will not change. If so , how to disable lighttpd_pfb?

SteveITS

@netboy said in 2100: constantly shows high CPU usage:

lighttpd_pfb consumes most of CPU

That's from pfBlocker. I think from the DNSBL block page. You could try setting DNSBL to one of the null block modes:

stephenw10

I'm surprised lighttpd would use much though. Unless it's being absolutely hammered by connection attempts. It's specially built to be light weight.

Gertjan

@netboy

Set all your DNSBL Logging/blocking mode to "Null block (logging)":

or, if you want no stats whatsoever, select "Null block (no logging)".

== what @SteveITS said.

Btw : this won't stop the pfBlocker's web server, but a web server serving no pages does just one thing : sleeping.

@netboy said in 2100: constantly shows high CPU usage:

Is it OK to disable ntopng?

ntopng is a 'data collector' and makes reports out of your Ethernet traffic.
ntopng isn't installed by default. It's a extra tool, and it's known for it's huge CPU appetite and huge disk space needs. ntopng, and some others, are ok to use, but the next time you select a router device, go for big iron, and big RAM, and more disk space.
Btw : pfBlockerng, and ntopng and others, does close to 'nothing' when there is no (or way less) Ethernet traffic. So, that is also a solution