[Samba] High cpu load on LDAP

[Douglas Bagnall]

On 19/11/24 02:29, Heinz Hölzl via samba wrote:
> hi,
> 
> I have to activate the thread again ...
> 
> we keep having preformance problems on the DC, especially on Monday
> morning when the PCs are switched on and the users log in.
> 
> some ldap-searches take a very long time, sometimes even over 15
> seconds
> 
> e.g:
> 
> ldapsrv_SearchRequest: LDAP Query: Duration was 15.74s, SearchRequest
> by S-1-5-21-xxxxxxxxxx-xxxxxxxxxxxxxx-8585 from
> ipv4:192.168.35.117:49240 filter: [(objectClass=user)] basedn:
> [DC=example,DC=net] scope: [SUB] result: Success
> 
> 
> The load of the ldap processes reaches 100% of a CPU. The ldapserver is
> then no longer responsive.
> 
> It seems that the ldapsearches are blocking each other.
> 
> The result is very long response times for login and other
> authentications.
> 
> we have 6 DC, approx. 10,000 active users and approx. 5000 PC, 10 samba
> fileservers, all with current samba version
> 
> 
> is there a way to increase the performance here?
> 

It would not hurt to delete about 6000 old machine accounts.

But it probably comes down to member searches on big groups, as 
discussed in this other thread:

https://lists.samba.org/archive/samba/2024-October/249848.html

The underlying problem is that linked attributes (like member) are not 
indexed.

Why are linked attributes not indexed? because that is what the 
Microsoft AD schema says.

Why does the AD schema say that? Perhaps because backlinks (like 
memberOf) are effectively an index, so an additional index seemed 
redundant. Perhaps Microsoft AD actually uses the backlinks as an index 
in linked attribute searches. Or perhaps Samba AD is used in different 
ways (e.g. with OpenLDAP slurping up all the memberships), so Microsoft 
does not often hit this problem.

It is possible to tell Samba to index 'member'. That would probably make 
this problem vanish, and there's a reasonable chance there would be no 
ill effects. I don't know if anyone has actually tried that.

I would like to solve this as a development problem, but that depends on 
time and funding and won't help you now.

BTW, that last thread ended with:

> Am Freitag, dem 30.09.2022 um 09:14 +1300 schrieb Andrew Bartlett:
>> [Sie erhalten nicht häufig E-Mails von abartlet at samba.org. Weitere
>> Informationen, warum dies wichtig ist, finden Sie unter
>> https://aka.ms/LearnAboutSenderIdentification ]

>>
>> Work out which PIDs are high CPU use:
>>
>> netstat -avp | grep <PID>
>>
>> gdb -p <PID>
>> bt full
>>
>> strace -p <PID>
>>
>> as well as a FlameGraph:
>> https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html#Instructions
>>
>> I would love to get to the bottom of this.
>> Andrew Bartlett

which would still be useful. Just a sampling of

>> gdb -p <PID>
>> bt full

would confirm where the server was spending its time. If `bt full` looks 
too revealing, you could use `bt` instead.

Douglas