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 Bartlettwhich would still be useful. Just a sampling of>> gdb -p <PID> >> bt fullwould confirm where the server was spending its time. If `bt full` looks too revealing, you could use `bt` instead. Douglas
hi,> It is possible to tell Samba to index 'member'.How i can do this? dbindex:member = yes in smb.conf ?? I will try to do the analysis as Andrew suggested. regards, heinz Am Mittwoch, dem 20.11.2024 um 11:04 +1300 schrieb Douglas Bagnall:> [Sie erhalten nicht h?ufig E-Mails von > douglas.bagnall at catalyst.net.nz. Weitere Informationen, warum dies > wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification?] > > 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 >
Hi, here the output of ? gdb -p <PID> bt full i hope this hepls Heinz Am Mittwoch, dem 20.11.2024 um 11:04 +1300 schrieb Douglas Bagnall:> [Sie erhalten nicht h?ufig E-Mails von > douglas.bagnall at catalyst.net.nz. Weitere Informationen, warum dies > wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification?] > > 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 >