AD-DC ram usage

NethServer Version: 7.7.1908 (final)
Module: AD-DC

Does somebody know how do decrease the memory usage of the samba-ad-dc process?
Does disabling the debug mode lessen the ram-usage? Or does it screw up the ad-dc?

Hi

You forget: Linux doesn’t like “unused” RAM…
It will allocate RAM for use as eg caching.

→ Don’t worry about RAM in Linux, unless you know you have big RAM users - usually big databases, no matter if MariaDB, PostgreSQL or whatever is used…

My 2 cents
Andy

2 Likes

In my NethServer the samba process uses only a few megabytes:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                         
 3449 root      20   0  594836   4624      0 S   0.0  0.1   0:00.53 samba             

Can you tell us how long does it take to reach those high numbers after a restart? Is it a sudden step or a slow increase?
May it be related to your setup or a peculiar usage pattern of the AD?
Debugging a memory leak is “hard”, you can find some hints on the net.
You should adapt instructions to the container, where many commands are unavailable.

From NethServer manual:

systemd-run -M nsdc -t /bin/bash

You could save the output of smbcontrol <pid_of_samab> pool-usage after restart and after ram usage increases.

2 Likes

I wonder if this is related.

After watching the ram for some time…

Normaly it starts with about 10%, after 1-2 days suddently ramps up to 40-50% and stays about there for 2-3 days before going down again. Sometimes it stays up for longer… Have to capture the output of the pool-usage…

After some observation: It seems netdata is the culprint…
I checked the ram-usage with htop and netdata was running amok… Checking “systemctl status netdata -l” gave me:

Sep 19 14:02:59 host.domain.tld systemd[1]: [/usr/lib/systemd/system/netdata.service:50] Failed to parse capability in bounding/ambient set, ignoring: CAP_PERFMON
Sep 19 14:02:59 host.domain.tld systemd[1]: [/usr/lib/systemd/system/netdata.service:69] Unknown lvalue 'ProtectControlGroups' in section 'Service'

After disabling stoping and disabling the netdata service, the ram usage never raised above 2gb.
All services are running more smothly, all web-ui (nethserver, sogo etc) are running more responsive, loading faster… Doing the google thing what is wrong with netdata, but i can´t figure it out with my limited knoweldge.

2 Likes

There have been reports of memory leaks in netdata in the past.
Those leaks may have been fixed in recent versions that have been installed in NethServer.
Please, continue to keep an eye on memory usage, it may confirm that the problem is fixed.

Okay, netdata wasn´t the culprint… On an irregular basis, the nsdc-container kept hogging all the memory for itself. Everything is slow until i fire up a terminal, log into the server via ssh, restart of the container, then everything works fine again.

New update: someday the vpn connections stopped working… All clients were up and running, but couldn´t get a OpenVPN connection to the root-server running nethserver. I phoned with the technicans in the datacenter, let them take a look at the clients (VPSes) and the host (root-server). They found nothing… After restarting the clients over and over again, i looged into the root server. And there we had it: The culprint was again the nsdc container, hogging all the ram for itself. This time even blocking other services from running properly. After systemctl restart nsdc everything ran smoothly again…

I wonder if i edit the systemd service file by adding

…
[Service]
…
MemoryAccounting=true
MemoryHigh=134217728
MemoryMax=268435456
so it would try to free memory if the service is using above 1gb and restarting the service when it´s using 2gb or more. Or is there a better way to restart the service based on a memory limit?

It is there an automated logger for the nsdc-container? So i could provide the logs here, as soon as i spot the problem, i restart the container, the problem is gone and i remember i lost another opportunity to provide logs for this problem…

1 Like