Netdata mem.available / system.ram: regular warnings

Help
,
1

Suggested template:

Problem/Question

Netdata triggers a mem.available & system.ram warning regularly on one of my servers running a normal LEMP stack for a Wordpress instance.

Relevant docs you followed/actions you took to solve the issue

I already checked many metrics on the local and cloud dashboard to diagnose the cause of this warning, and it seems like in that split-second of low RAM free / very high RAM usage, 2000 new processes get spawned for that one second only and then get killed again.

RAM usage:

image
image934×344 35.7 KB

Process counter:

image
image776×339 13.4 KB

How do I diagnose further with Netdata what causes this spike in processes?

I see that Netdata, in that specific second and for one second after that, consumes increased resources for DB writing and page rendering (?). Does it do that because it has a bug and Netdata is at fault or does it consume these additional resources to log the incident another package is causing?

Environment/Browser/Agent’s version etc

Netdata agent v1.38.0-345-nightly

Ubuntu 22.04.2 LTS; Linux 5.15.0-53-generic #59~20.04.1-Ubuntu SMP Thu Oct 20 15:10:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

This is an LXC container rented as a standalone server instance from a VPS provider.

2

Hi, @epskps. No, Netdata doesn’t spawn thousands of processes. Check Applications/User charts.

3

I checked all the mentioned charts and haven’t found anything conclusive that triggers these 2000 processes.

I only noticed that Netdata stands out in that timeframe with increased CPU, RAM and Threads usage.

No other process or process tree changes its values for CPU, RAM and Threads in the charts.

4

Netdata’s increase CPU usage is expected because:

  • more processes =>
  • more entries in proc/ =>
  • more work for Netdata/ =>
  • Netdata periodically reads /proc/* to collect per-process groups metrics.

Can you export a snapshot within that timeframe and send it to ilya@netdata.cloud?

5

Of course, I exported 05:01 to 05:03 UTC+2, since the incident happened at 05:02:43.

The mail should arrive soon.

6

Were you able to extract anything useful from the snapshot I sent you?