thr3ads.net - samba - [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ? [Mar 2017]

If this information is useful, please help other people find it:
Share via:

L.P.H. van Belle

2017-Mar-23 10:54 UTC

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

Are use using zarafaAccount=1 withing the search filters? 
I use this things like this : 

(&(objectClass=person)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 
Or for groups.
(&(objectclass=group)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s)))

That helps a lot.

! If you switch to kopano beware to change the SCHEMA and filters
zarafaAccount changed to kopanoAccount 


Greetz. 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Gaetan SLONGO
via
> samba
> Verzonden: donderdag 23 maart 2017 11:12
> Aan: samba at lists.samba.org
> Onderwerp: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
> performance tunning ?
> Urgentie: Hoog
> 
> 
> Dear users,
> 
> We are facing to a big latency issue regarding the LDAP Server (both
> encrypted & plain).
> 
> We have a Zarafa mail server which makes a lot of queries and puts a samba
> process to 100% usage. This latency makes the mail server unusable.. The
> mail server was previously on OpenLDAP and there was not performance
> issues.
> 
> A simple LDAP query can take up to 25 sec to perform !!
> 
> We have added some indexes :
> 
> [root at califix ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b
> @INDEXLIST
> # record 1
> dn: @INDEXLIST
> @IDXONE: 1
> @IDXVERSION: 2
> @IDXATTR: objectClass
> @IDXATTR: msDS-Cached-Membership-Time-Stamp
> @IDXATTR: userPrincipalName
> @IDXATTR: rpcNsInterfaceID
> @IDXATTR: fileExtPriority
> @IDXATTR: dnsRoot
> @IDXATTR: mSMQLabelEx
> @IDXATTR: dNSTombstoned
> @IDXATTR: msDS-PhoneticCompanyName
> @IDXATTR: msSFU30Domains
> @IDXATTR: dhcpType
> @IDXATTR: ou
> @IDXATTR: gidNumber
> @IDXATTR: msFVE-VolumeGuid
> @IDXATTR: msTSManagingLS2
> @IDXATTR: implementedCategories
> @IDXATTR: oMTIndxGuid
> @IDXATTR: cOMClassID
> @IDXATTR: volTableIdxGUID
> @IDXATTR: l
> @IDXATTR: mSMQDigests
> @IDXATTR: msTSExpireDate4
> @IDXATTR: flatName
> @IDXATTR: msSFU30YpServers
> @IDXATTR: packageFlags
> @IDXATTR: mSMQOwnerID
> @IDXATTR: objectCategory
> @IDXATTR: msSFU30IsValidContainer
> @IDXATTR: msTSProperty02
> @IDXATTR: mS-DS-CreatorSID
> @IDXATTR: proxyAddresses
> @IDXATTR: msPKI-Cert-Template-OID
> @IDXATTR: uNCName
> @IDXATTR: mS-SQL-Name
> @IDXATTR: fSMORoleOwner
> @IDXATTR: msSFU30NisDomain
> @IDXATTR: otherMailbox
> @IDXATTR: location
> @IDXATTR: msSFU30NetgroupHostAtDomain
> @IDXATTR: uSNChanged
> @IDXATTR: sIDHistory
> @IDXATTR: birthLocation
> @IDXATTR: msDS-SecondaryKrbTgtNumber
> @IDXATTR: msTSProperty01
> @IDXATTR: msTSManagingLS4
> @IDXATTR: msSFU30OrderNumber
> @IDXATTR: msDS-HABSeniorityIndex
> @IDXATTR: primaryGroupID
> @IDXATTR: mSMQQueueType
> @IDXATTR: msDFSR-ReplicationGroupGuid
> @IDXATTR: msDS-PhoneticDepartment
> @IDXATTR: mail
> @IDXATTR: msSFU30Name
> @IDXATTR: msSFU30NetgroupUserAtDomain
> @IDXATTR: fromServer
> @IDXATTR: displayName
> @IDXATTR: msTSLicenseVersion2
> @IDXATTR: groupType
> @IDXATTR: msTSLicenseVersion3
> @IDXATTR: msTSLicenseVersion4
> @IDXATTR: userAccountControl
> @IDXATTR: physicalLocationObject
> @IDXATTR: servicePrincipalName
> @IDXATTR: msTSExpireDate
> @IDXATTR: serviceClassName
> @IDXATTR: lDAPDisplayName
> @IDXATTR: zarafaAccount
> @IDXATTR: terminalServer
> @IDXATTR: givenName
> @IDXATTR: msTSManagingLS3
> @IDXATTR: msSFU30MaxUidNumber
> @IDXATTR: msDS-Entry-Time-To-Die
> @IDXATTR: msTSLSProperty01
> @IDXATTR: msDS-PhoneticFirstName
> @IDXATTR: trustPartner
> @IDXATTR: msTSLSProperty02
> @IDXATTR: msTSExpireDate3
> @IDXATTR: objectGUID
> @IDXATTR: showInAdvancedViewOnly
> @IDXATTR: rpcNsTransferSyntax
> @IDXATTR: sAMAccountName
> @IDXATTR: mS-SQL-Version
> @IDXATTR: msDS-Site-Affinity
> @IDXATTR: sn
> @IDXATTR: name
> @IDXATTR: nETBIOSName
> @IDXATTR: sAMAccountType
> @IDXATTR: msTSManagingLS
> @IDXATTR: msDFSR-DfsPath
> @IDXATTR: altSecurityIdentities
> @IDXATTR: USNIntersite
> @IDXATTR: msSFU30MasterServerName
> @IDXATTR: msDS-PhoneticLastName
> @IDXATTR: cn
> @IDXATTR: netbootGUID
> @IDXATTR: lastLogonTimestamp
> @IDXATTR: legacyExchangeDN
> @IDXATTR: mSMQLabel
> @IDXATTR: uSNCreated
> @IDXATTR: mS-SQL-Database
> @IDXATTR: msDS-PhoneticDisplayName
> @IDXATTR: msSFU30MaxGidNumber
> @IDXATTR: rpcNsObjectID
> @IDXATTR: timeVolChange
> @IDXATTR: msTSExpireDate2
> @IDXATTR: groupAttributes
> @IDXATTR: physicalDeliveryOfficeName
> @IDXATTR: msFVE-RecoveryGuid
> @IDXATTR: msDS-AdditionalSamAccountName
> @IDXATTR: objectSid
> @IDXATTR: keywords
> @IDXATTR: mS-SQL-Alias
> @IDXATTR: invocationId
> @IDXATTR: msTSLicenseVersion
> @IDXATTR: requiredCategories
> @IDXATTR: msDS-AzObjectGuid
> distinguishedName: @INDEXLIST
> 
> There is any way to improve LDAP responses times ? It seems there is only
> one process which is managing LDAP queries (no forks/threads?)
> 
> Thank you in advance for your help !!
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Gaetan SLONGO

2017-Mar-27 06:46 UTC

head link

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

Hi ! 

Thanks for answer. Yes we use zarafaAccount in search filter. 
There is an installer provided for Samba4 to install new schemas ? 

Thanks ! 

----- Mail original -----

De: "L.P.H. van Belle via samba" <samba at lists.samba.org> 
À: samba at lists.samba.org 
Envoyé: Jeudi 23 Mars 2017 11:54:50 
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


Are use using zarafaAccount=1 withing the search filters? 
I use this things like this : 

(&(objectClass=person)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 
Or for groups. 
(&(objectclass=group)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 

That helps a lot. 

! If you switch to kopano beware to change the SCHEMA and filters 
zarafaAccount changed to kopanoAccount 


Greetz. 

Louis 

> -----Oorspronkelijk bericht----- 
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Gaetan SLONGO
via
> samba 
> Verzonden: donderdag 23 maart 2017 11:12 
> Aan: samba at lists.samba.org 
> Onderwerp: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), 
> performance tunning ? 
> Urgentie: Hoog 
> 
> 
> Dear users, 
> 
> We are facing to a big latency issue regarding the LDAP Server (both 
> encrypted & plain). 
> 
> We have a Zarafa mail server which makes a lot of queries and puts a samba 
> process to 100% usage. This latency makes the mail server unusable.. The 
> mail server was previously on OpenLDAP and there was not performance 
> issues. 
> 
> A simple LDAP query can take up to 25 sec to perform !! 
> 
> We have added some indexes : 
> 
> [root at califix ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b
> @INDEXLIST 
> # record 1 
> dn: @INDEXLIST 
> @IDXONE: 1 
> @IDXVERSION: 2 
> @IDXATTR: objectClass 
> @IDXATTR: msDS-Cached-Membership-Time-Stamp 
> @IDXATTR: userPrincipalName 
> @IDXATTR: rpcNsInterfaceID 
> @IDXATTR: fileExtPriority 
> @IDXATTR: dnsRoot 
> @IDXATTR: mSMQLabelEx 
> @IDXATTR: dNSTombstoned 
> @IDXATTR: msDS-PhoneticCompanyName 
> @IDXATTR: msSFU30Domains 
> @IDXATTR: dhcpType 
> @IDXATTR: ou 
> @IDXATTR: gidNumber 
> @IDXATTR: msFVE-VolumeGuid 
> @IDXATTR: msTSManagingLS2 
> @IDXATTR: implementedCategories 
> @IDXATTR: oMTIndxGuid 
> @IDXATTR: cOMClassID 
> @IDXATTR: volTableIdxGUID 
> @IDXATTR: l 
> @IDXATTR: mSMQDigests 
> @IDXATTR: msTSExpireDate4 
> @IDXATTR: flatName 
> @IDXATTR: msSFU30YpServers 
> @IDXATTR: packageFlags 
> @IDXATTR: mSMQOwnerID 
> @IDXATTR: objectCategory 
> @IDXATTR: msSFU30IsValidContainer 
> @IDXATTR: msTSProperty02 
> @IDXATTR: mS-DS-CreatorSID 
> @IDXATTR: proxyAddresses 
> @IDXATTR: msPKI-Cert-Template-OID 
> @IDXATTR: uNCName 
> @IDXATTR: mS-SQL-Name 
> @IDXATTR: fSMORoleOwner 
> @IDXATTR: msSFU30NisDomain 
> @IDXATTR: otherMailbox 
> @IDXATTR: location 
> @IDXATTR: msSFU30NetgroupHostAtDomain 
> @IDXATTR: uSNChanged 
> @IDXATTR: sIDHistory 
> @IDXATTR: birthLocation 
> @IDXATTR: msDS-SecondaryKrbTgtNumber 
> @IDXATTR: msTSProperty01 
> @IDXATTR: msTSManagingLS4 
> @IDXATTR: msSFU30OrderNumber 
> @IDXATTR: msDS-HABSeniorityIndex 
> @IDXATTR: primaryGroupID 
> @IDXATTR: mSMQQueueType 
> @IDXATTR: msDFSR-ReplicationGroupGuid 
> @IDXATTR: msDS-PhoneticDepartment 
> @IDXATTR: mail 
> @IDXATTR: msSFU30Name 
> @IDXATTR: msSFU30NetgroupUserAtDomain 
> @IDXATTR: fromServer 
> @IDXATTR: displayName 
> @IDXATTR: msTSLicenseVersion2 
> @IDXATTR: groupType 
> @IDXATTR: msTSLicenseVersion3 
> @IDXATTR: msTSLicenseVersion4 
> @IDXATTR: userAccountControl 
> @IDXATTR: physicalLocationObject 
> @IDXATTR: servicePrincipalName 
> @IDXATTR: msTSExpireDate 
> @IDXATTR: serviceClassName 
> @IDXATTR: lDAPDisplayName 
> @IDXATTR: zarafaAccount 
> @IDXATTR: terminalServer 
> @IDXATTR: givenName 
> @IDXATTR: msTSManagingLS3 
> @IDXATTR: msSFU30MaxUidNumber 
> @IDXATTR: msDS-Entry-Time-To-Die 
> @IDXATTR: msTSLSProperty01 
> @IDXATTR: msDS-PhoneticFirstName 
> @IDXATTR: trustPartner 
> @IDXATTR: msTSLSProperty02 
> @IDXATTR: msTSExpireDate3 
> @IDXATTR: objectGUID 
> @IDXATTR: showInAdvancedViewOnly 
> @IDXATTR: rpcNsTransferSyntax 
> @IDXATTR: sAMAccountName 
> @IDXATTR: mS-SQL-Version 
> @IDXATTR: msDS-Site-Affinity 
> @IDXATTR: sn 
> @IDXATTR: name 
> @IDXATTR: nETBIOSName 
> @IDXATTR: sAMAccountType 
> @IDXATTR: msTSManagingLS 
> @IDXATTR: msDFSR-DfsPath 
> @IDXATTR: altSecurityIdentities 
> @IDXATTR: USNIntersite 
> @IDXATTR: msSFU30MasterServerName 
> @IDXATTR: msDS-PhoneticLastName 
> @IDXATTR: cn 
> @IDXATTR: netbootGUID 
> @IDXATTR: lastLogonTimestamp 
> @IDXATTR: legacyExchangeDN 
> @IDXATTR: mSMQLabel 
> @IDXATTR: uSNCreated 
> @IDXATTR: mS-SQL-Database 
> @IDXATTR: msDS-PhoneticDisplayName 
> @IDXATTR: msSFU30MaxGidNumber 
> @IDXATTR: rpcNsObjectID 
> @IDXATTR: timeVolChange 
> @IDXATTR: msTSExpireDate2 
> @IDXATTR: groupAttributes 
> @IDXATTR: physicalDeliveryOfficeName 
> @IDXATTR: msFVE-RecoveryGuid 
> @IDXATTR: msDS-AdditionalSamAccountName 
> @IDXATTR: objectSid 
> @IDXATTR: keywords 
> @IDXATTR: mS-SQL-Alias 
> @IDXATTR: invocationId 
> @IDXATTR: msTSLicenseVersion 
> @IDXATTR: requiredCategories 
> @IDXATTR: msDS-AzObjectGuid 
> distinguishedName: @INDEXLIST 
> 
> There is any way to improve LDAP responses times ? It seems there is only 
> one process which is managing LDAP queries (no forks/threads?) 
> 
> Thank you in advance for your help !! 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the 
> instructions: https://lists.samba.org/mailman/options/samba 


-- 
To unsubscribe from this list go to the following URL and read the 
instructions: https://lists.samba.org/mailman/options/samba 



-- 




www.it-optics.com 
	
Gaëtan SLONGO | Head of Infrastructure Department 
Boulevard Initialis, 28 - 7000 Mons, BELGIUM 
Company : 	+32 (0)65 84 23 85 
Direct : 	+32 (0)65 32 85 88 
Fax : 	+32 (0)65 84 66 76 
Skype ID : 	gslongo.pro 
GPG Key : 	gslongo-gpg_key.asc 
	

- Please consider your environmental responsibility before printing this e-mail
-

L.P.H. van Belle

2017-Mar-27 07:58 UTC

head link

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

No, you have to do that manualy, or look the the samba4 ADS script for kopano (
or zarafa )

But I mostly follow the documentation. 

 

And when i run :

time ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b @INDEXLIST 

....

real    0m0.230s

user    0m0.184s

sys     0m0.044s

 

so if yours take more that 20 sec there is something very wrong. 

I suggest check you samba AD database and samba4 ADDC setup,

i dont think this is zarafa related. 

 

 

Greetz, 

 

Louis

 

 

 

 

 


Van: Gaetan SLONGO [mailto:gslongo at it-optics.com] 
Verzonden: maandag 27 maart 2017 8:46
Aan: L.P.H. van Belle
CC: samba at lists.samba.org
Onderwerp: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


 

Hi !

Thanks for answer. Yes we use zarafaAccount in search filter.
There is an installer provided for Samba4 to install new schemas ?

Thanks !


De: "L.P.H. van Belle via samba" <samba at lists.samba.org>
À: samba at lists.samba.org
Envoyé: Jeudi 23 Mars 2017 11:54:50
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


Are use using zarafaAccount=1 withing the search filters? 
I use this things like this : 

(&(objectClass=person)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 
Or for groups.
(&(objectclass=group)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s)))

That helps a lot.

! If you switch to kopano beware to change the SCHEMA and filters
zarafaAccount changed to kopanoAccount 


Greetz. 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Gaetan SLONGO
via
> samba
> Verzonden: donderdag 23 maart 2017 11:12
> Aan: samba at lists.samba.org
> Onderwerp: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
> performance tunning ?
> Urgentie: Hoog
> 
> 
> Dear users,
> 
> We are facing to a big latency issue regarding the LDAP Server (both
> encrypted & plain).
> 
> We have a Zarafa mail server which makes a lot of queries and puts a samba
> process to 100% usage. This latency makes the mail server unusable.. The
> mail server was previously on OpenLDAP and there was not performance
> issues.
> 
> A simple LDAP query can take up to 25 sec to perform !!
> 
> We have added some indexes :
> 
> [root at califix ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b
> @INDEXLIST
> # record 1
> dn: @INDEXLIST
> @IDXONE: 1
> @IDXVERSION: 2
> @IDXATTR: objectClass
> @IDXATTR: msDS-Cached-Membership-Time-Stamp
> @IDXATTR: userPrincipalName
> @IDXATTR: rpcNsInterfaceID
> @IDXATTR: fileExtPriority
> @IDXATTR: dnsRoot
> @IDXATTR: mSMQLabelEx
> @IDXATTR: dNSTombstoned
> @IDXATTR: msDS-PhoneticCompanyName
> @IDXATTR: msSFU30Domains
> @IDXATTR: dhcpType
> @IDXATTR: ou
> @IDXATTR: gidNumber
> @IDXATTR: msFVE-VolumeGuid
> @IDXATTR: msTSManagingLS2
> @IDXATTR: implementedCategories
> @IDXATTR: oMTIndxGuid
> @IDXATTR: cOMClassID
> @IDXATTR: volTableIdxGUID
> @IDXATTR: l
> @IDXATTR: mSMQDigests
> @IDXATTR: msTSExpireDate4
> @IDXATTR: flatName
> @IDXATTR: msSFU30YpServers
> @IDXATTR: packageFlags
> @IDXATTR: mSMQOwnerID
> @IDXATTR: objectCategory
> @IDXATTR: msSFU30IsValidContainer
> @IDXATTR: msTSProperty02
> @IDXATTR: mS-DS-CreatorSID
> @IDXATTR: proxyAddresses
> @IDXATTR: msPKI-Cert-Template-OID
> @IDXATTR: uNCName
> @IDXATTR: mS-SQL-Name
> @IDXATTR: fSMORoleOwner
> @IDXATTR: msSFU30NisDomain
> @IDXATTR: otherMailbox
> @IDXATTR: location
> @IDXATTR: msSFU30NetgroupHostAtDomain
> @IDXATTR: uSNChanged
> @IDXATTR: sIDHistory
> @IDXATTR: birthLocation
> @IDXATTR: msDS-SecondaryKrbTgtNumber
> @IDXATTR: msTSProperty01
> @IDXATTR: msTSManagingLS4
> @IDXATTR: msSFU30OrderNumber
> @IDXATTR: msDS-HABSeniorityIndex
> @IDXATTR: primaryGroupID
> @IDXATTR: mSMQQueueType
> @IDXATTR: msDFSR-ReplicationGroupGuid
> @IDXATTR: msDS-PhoneticDepartment
> @IDXATTR: mail
> @IDXATTR: msSFU30Name
> @IDXATTR: msSFU30NetgroupUserAtDomain
> @IDXATTR: fromServer
> @IDXATTR: displayName
> @IDXATTR: msTSLicenseVersion2
> @IDXATTR: groupType
> @IDXATTR: msTSLicenseVersion3
> @IDXATTR: msTSLicenseVersion4
> @IDXATTR: userAccountControl
> @IDXATTR: physicalLocationObject
> @IDXATTR: servicePrincipalName
> @IDXATTR: msTSExpireDate
> @IDXATTR: serviceClassName
> @IDXATTR: lDAPDisplayName
> @IDXATTR: zarafaAccount
> @IDXATTR: terminalServer
> @IDXATTR: givenName
> @IDXATTR: msTSManagingLS3
> @IDXATTR: msSFU30MaxUidNumber
> @IDXATTR: msDS-Entry-Time-To-Die
> @IDXATTR: msTSLSProperty01
> @IDXATTR: msDS-PhoneticFirstName
> @IDXATTR: trustPartner
> @IDXATTR: msTSLSProperty02
> @IDXATTR: msTSExpireDate3
> @IDXATTR: objectGUID
> @IDXATTR: showInAdvancedViewOnly
> @IDXATTR: rpcNsTransferSyntax
> @IDXATTR: sAMAccountName
> @IDXATTR: mS-SQL-Version
> @IDXATTR: msDS-Site-Affinity
> @IDXATTR: sn
> @IDXATTR: name
> @IDXATTR: nETBIOSName
> @IDXATTR: sAMAccountType
> @IDXATTR: msTSManagingLS
> @IDXATTR: msDFSR-DfsPath
> @IDXATTR: altSecurityIdentities
> @IDXATTR: USNIntersite
> @IDXATTR: msSFU30MasterServerName
> @IDXATTR: msDS-PhoneticLastName
> @IDXATTR: cn
> @IDXATTR: netbootGUID
> @IDXATTR: lastLogonTimestamp
> @IDXATTR: legacyExchangeDN
> @IDXATTR: mSMQLabel
> @IDXATTR: uSNCreated
> @IDXATTR: mS-SQL-Database
> @IDXATTR: msDS-PhoneticDisplayName
> @IDXATTR: msSFU30MaxGidNumber
> @IDXATTR: rpcNsObjectID
> @IDXATTR: timeVolChange
> @IDXATTR: msTSExpireDate2
> @IDXATTR: groupAttributes
> @IDXATTR: physicalDeliveryOfficeName
> @IDXATTR: msFVE-RecoveryGuid
> @IDXATTR: msDS-AdditionalSamAccountName
> @IDXATTR: objectSid
> @IDXATTR: keywords
> @IDXATTR: mS-SQL-Alias
> @IDXATTR: invocationId
> @IDXATTR: msTSLicenseVersion
> @IDXATTR: requiredCategories
> @IDXATTR: msDS-AzObjectGuid
> distinguishedName: @INDEXLIST
> 
> There is any way to improve LDAP responses times ? It seems there is only
> one process which is managing LDAP queries (no forks/threads?)
> 
> Thank you in advance for your help !!
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba





-- 



www.it-optics.com 
	
Gaëtan SLONGO | Head of Infrastructure Department
Boulevard Initialis, 28 - 7000 Mons, BELGIUM

Company :
	
+32 (0)65 84 23 85

Direct :
	
+32 (0)65 32 85 88

Fax :
	
+32 (0)65 84 66 76

Skype ID :
	
gslongo.pro

GPG Key :
	
gslongo-gpg_key.asc 



	



- Please consider your environmental responsibility before printing this e-mail
-

Gaetan SLONGO

2017-Mar-27 08:11 UTC

head link

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

What we found is Zarafa makes a very big amount of queries, which makes Samba
run at 100% CPU (one process, LDAP does not seems to be multi-threaded..?)...
but we have hundreds of users...

What do you think could be wrong in the current database/setup ? We verified all
the setup and everything seems OK

----- Mail original -----

De: "L.P.H. van Belle via samba" <samba at lists.samba.org> 
À: samba at lists.samba.org 
Envoyé: Lundi 27 Mars 2017 09:58:55 
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?

No, you have to do that manualy, or look the the samba4 ADS script for kopano (
or zarafa )

But I mostly follow the documentation. 



And when i run : 

time ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b @INDEXLIST 

.... 

real 0m0.230s 

user 0m0.184s 

sys 0m0.044s 



so if yours take more that 20 sec there is something very wrong. 

I suggest check you samba AD database and samba4 ADDC setup, 

i dont think this is zarafa related. 





Greetz, 



Louis 












Van: Gaetan SLONGO [mailto:gslongo at it-optics.com] 
Verzonden: maandag 27 maart 2017 8:46 
Aan: L.P.H. van Belle 
CC: samba at lists.samba.org 
Onderwerp: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?




Hi ! 

Thanks for answer. Yes we use zarafaAccount in search filter. 
There is an installer provided for Samba4 to install new schemas ? 

Thanks ! 


De: "L.P.H. van Belle via samba" <samba at lists.samba.org> 
À: samba at lists.samba.org 
Envoyé: Jeudi 23 Mars 2017 11:54:50 
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


Are use using zarafaAccount=1 withing the search filters? 
I use this things like this : 

(&(objectClass=person)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 
Or for groups. 
(&(objectclass=group)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 

That helps a lot. 

! If you switch to kopano beware to change the SCHEMA and filters 
zarafaAccount changed to kopanoAccount 


Greetz. 

Louis 

> -----Oorspronkelijk bericht----- 
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Gaetan SLONGO
via
> samba 
> Verzonden: donderdag 23 maart 2017 11:12 
> Aan: samba at lists.samba.org 
> Onderwerp: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), 
> performance tunning ? 
> Urgentie: Hoog 
> 
> 
> Dear users, 
> 
> We are facing to a big latency issue regarding the LDAP Server (both 
> encrypted & plain). 
> 
> We have a Zarafa mail server which makes a lot of queries and puts a samba 
> process to 100% usage. This latency makes the mail server unusable.. The 
> mail server was previously on OpenLDAP and there was not performance 
> issues. 
> 
> A simple LDAP query can take up to 25 sec to perform !! 
> 
> We have added some indexes : 
> 
> [root at califix ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b
> @INDEXLIST 
> # record 1 
> dn: @INDEXLIST 
> @IDXONE: 1 
> @IDXVERSION: 2 
> @IDXATTR: objectClass 
> @IDXATTR: msDS-Cached-Membership-Time-Stamp 
> @IDXATTR: userPrincipalName 
> @IDXATTR: rpcNsInterfaceID 
> @IDXATTR: fileExtPriority 
> @IDXATTR: dnsRoot 
> @IDXATTR: mSMQLabelEx 
> @IDXATTR: dNSTombstoned 
> @IDXATTR: msDS-PhoneticCompanyName 
> @IDXATTR: msSFU30Domains 
> @IDXATTR: dhcpType 
> @IDXATTR: ou 
> @IDXATTR: gidNumber 
> @IDXATTR: msFVE-VolumeGuid 
> @IDXATTR: msTSManagingLS2 
> @IDXATTR: implementedCategories 
> @IDXATTR: oMTIndxGuid 
> @IDXATTR: cOMClassID 
> @IDXATTR: volTableIdxGUID 
> @IDXATTR: l 
> @IDXATTR: mSMQDigests 
> @IDXATTR: msTSExpireDate4 
> @IDXATTR: flatName 
> @IDXATTR: msSFU30YpServers 
> @IDXATTR: packageFlags 
> @IDXATTR: mSMQOwnerID 
> @IDXATTR: objectCategory 
> @IDXATTR: msSFU30IsValidContainer 
> @IDXATTR: msTSProperty02 
> @IDXATTR: mS-DS-CreatorSID 
> @IDXATTR: proxyAddresses 
> @IDXATTR: msPKI-Cert-Template-OID 
> @IDXATTR: uNCName 
> @IDXATTR: mS-SQL-Name 
> @IDXATTR: fSMORoleOwner 
> @IDXATTR: msSFU30NisDomain 
> @IDXATTR: otherMailbox 
> @IDXATTR: location 
> @IDXATTR: msSFU30NetgroupHostAtDomain 
> @IDXATTR: uSNChanged 
> @IDXATTR: sIDHistory 
> @IDXATTR: birthLocation 
> @IDXATTR: msDS-SecondaryKrbTgtNumber 
> @IDXATTR: msTSProperty01 
> @IDXATTR: msTSManagingLS4 
> @IDXATTR: msSFU30OrderNumber 
> @IDXATTR: msDS-HABSeniorityIndex 
> @IDXATTR: primaryGroupID 
> @IDXATTR: mSMQQueueType 
> @IDXATTR: msDFSR-ReplicationGroupGuid 
> @IDXATTR: msDS-PhoneticDepartment 
> @IDXATTR: mail 
> @IDXATTR: msSFU30Name 
> @IDXATTR: msSFU30NetgroupUserAtDomain 
> @IDXATTR: fromServer 
> @IDXATTR: displayName 
> @IDXATTR: msTSLicenseVersion2 
> @IDXATTR: groupType 
> @IDXATTR: msTSLicenseVersion3 
> @IDXATTR: msTSLicenseVersion4 
> @IDXATTR: userAccountControl 
> @IDXATTR: physicalLocationObject 
> @IDXATTR: servicePrincipalName 
> @IDXATTR: msTSExpireDate 
> @IDXATTR: serviceClassName 
> @IDXATTR: lDAPDisplayName 
> @IDXATTR: zarafaAccount 
> @IDXATTR: terminalServer 
> @IDXATTR: givenName 
> @IDXATTR: msTSManagingLS3 
> @IDXATTR: msSFU30MaxUidNumber 
> @IDXATTR: msDS-Entry-Time-To-Die 
> @IDXATTR: msTSLSProperty01 
> @IDXATTR: msDS-PhoneticFirstName 
> @IDXATTR: trustPartner 
> @IDXATTR: msTSLSProperty02 
> @IDXATTR: msTSExpireDate3 
> @IDXATTR: objectGUID 
> @IDXATTR: showInAdvancedViewOnly 
> @IDXATTR: rpcNsTransferSyntax 
> @IDXATTR: sAMAccountName 
> @IDXATTR: mS-SQL-Version 
> @IDXATTR: msDS-Site-Affinity 
> @IDXATTR: sn 
> @IDXATTR: name 
> @IDXATTR: nETBIOSName 
> @IDXATTR: sAMAccountType 
> @IDXATTR: msTSManagingLS 
> @IDXATTR: msDFSR-DfsPath 
> @IDXATTR: altSecurityIdentities 
> @IDXATTR: USNIntersite 
> @IDXATTR: msSFU30MasterServerName 
> @IDXATTR: msDS-PhoneticLastName 
> @IDXATTR: cn 
> @IDXATTR: netbootGUID 
> @IDXATTR: lastLogonTimestamp 
> @IDXATTR: legacyExchangeDN 
> @IDXATTR: mSMQLabel 
> @IDXATTR: uSNCreated 
> @IDXATTR: mS-SQL-Database 
> @IDXATTR: msDS-PhoneticDisplayName 
> @IDXATTR: msSFU30MaxGidNumber 
> @IDXATTR: rpcNsObjectID 
> @IDXATTR: timeVolChange 
> @IDXATTR: msTSExpireDate2 
> @IDXATTR: groupAttributes 
> @IDXATTR: physicalDeliveryOfficeName 
> @IDXATTR: msFVE-RecoveryGuid 
> @IDXATTR: msDS-AdditionalSamAccountName 
> @IDXATTR: objectSid 
> @IDXATTR: keywords 
> @IDXATTR: mS-SQL-Alias 
> @IDXATTR: invocationId 
> @IDXATTR: msTSLicenseVersion 
> @IDXATTR: requiredCategories 
> @IDXATTR: msDS-AzObjectGuid 
> distinguishedName: @INDEXLIST 
> 
> There is any way to improve LDAP responses times ? It seems there is only 
> one process which is managing LDAP queries (no forks/threads?) 
> 
> Thank you in advance for your help !! 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the 
> instructions: https://lists.samba.org/mailman/options/samba 


-- 
To unsubscribe from this list go to the following URL and read the 
instructions: https://lists.samba.org/mailman/options/samba 





-- 



www.it-optics.com 

Gaëtan SLONGO | Head of Infrastructure Department 
Boulevard Initialis, 28 - 7000 Mons, BELGIUM 

Company : 

+32 (0)65 84 23 85 

Direct : 

+32 (0)65 32 85 88 

Fax : 

+32 (0)65 84 66 76 

Skype ID : 

gslongo.pro 

GPG Key : 

gslongo-gpg_key.asc 







- Please consider your environmental responsibility before printing this e-mail
-



















-- 
To unsubscribe from this list go to the following URL and read the 
instructions: https://lists.samba.org/mailman/options/samba 



-- 




www.it-optics.com 
	
Gaëtan SLONGO | Head of Infrastructure Department 
Boulevard Initialis, 28 - 7000 Mons, BELGIUM 
Company : 	+32 (0)65 84 23 85 
Direct : 	+32 (0)65 32 85 88 
Fax : 	+32 (0)65 84 66 76 
Skype ID : 	gslongo.pro 
GPG Key : 	gslongo-gpg_key.asc 
	

- Please consider your environmental responsibility before printing this e-mail
-

L.P.H. van Belle

2017-Mar-27 08:26 UTC

head link

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

Can you tell more about your setup? 

Is zarafa and samba on the same server for example. 

Which MTA are you using postfix/exim?

 

My top was about 150 users, and all my printers are connected also so about 200
devices do ldap searches.

but my setup is split over 10+ servers ( 2 are AD DC ) 

 

So best is to tell what you can about your setup, anonimize if needed. 

 

Greetz, 

 

Louis

 

 

 


Van: Gaetan SLONGO [mailto:gslongo at it-optics.com] 
Verzonden: maandag 27 maart 2017 10:12
Aan: L.P.H. van Belle
CC: samba at lists.samba.org
Onderwerp: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


 

What we found is Zarafa makes a very big amount of queries, which makes Samba
run at 100% CPU (one process, LDAP does not seems to be multi-threaded..?)...
but we have hundreds of users...

What do you think could be wrong in the current database/setup ? We verified all
the setup and everything seems OK


De: "L.P.H. van Belle via samba" <samba at lists.samba.org>
À: samba at lists.samba.org
Envoyé: Lundi 27 Mars 2017 09:58:55
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?

No, you have to do that manualy, or look the the samba4 ADS script for kopano (
or zarafa )

But I mostly follow the documentation. 

 

And when i run :

time ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b @INDEXLIST 

....

real    0m0.230s

user    0m0.184s

sys     0m0.044s

 

so if yours take more that 20 sec there is something very wrong. 

I suggest check you samba AD database and samba4 ADDC setup,

i dont think this is zarafa related. 

 

 

Greetz, 

 

Louis

 

 

 

 

 


Van: Gaetan SLONGO [mailto:gslongo at it-optics.com] 
Verzonden: maandag 27 maart 2017 8:46
Aan: L.P.H. van Belle
CC: samba at lists.samba.org
Onderwerp: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


 

Hi !

Thanks for answer. Yes we use zarafaAccount in search filter.
There is an installer provided for Samba4 to install new schemas ?

Thanks !


De: "L.P.H. van Belle via samba" <samba at lists.samba.org>
À: samba at lists.samba.org
Envoyé: Jeudi 23 Mars 2017 11:54:50
Objet: Re: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
performance tunning ?


Are use using zarafaAccount=1 withing the search filters? 
I use this things like this : 

(&(objectClass=person)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s))) 
Or for groups.
(&(objectclass=group)(zarafaAccount=1)(|(mail=%s)(otherMailbox=%s)))

That helps a lot.

! If you switch to kopano beware to change the SCHEMA and filters
zarafaAccount changed to kopanoAccount 


Greetz. 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Gaetan SLONGO
via
> samba
> Verzonden: donderdag 23 maart 2017 11:12
> Aan: samba at lists.samba.org
> Onderwerp: [Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable),
> performance tunning ?
> Urgentie: Hoog
> 
> 
> Dear users,
> 
> We are facing to a big latency issue regarding the LDAP Server (both
> encrypted & plain).
> 
> We have a Zarafa mail server which makes a lot of queries and puts a samba
> process to 100% usage. This latency makes the mail server unusable.. The
> mail server was previously on OpenLDAP and there was not performance
> issues.
> 
> A simple LDAP query can take up to 25 sec to perform !!
> 
> We have added some indexes :
> 
> [root at califix ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b
> @INDEXLIST
> # record 1
> dn: @INDEXLIST
> @IDXONE: 1
> @IDXVERSION: 2
> @IDXATTR: objectClass
> @IDXATTR: msDS-Cached-Membership-Time-Stamp
> @IDXATTR: userPrincipalName
> @IDXATTR: rpcNsInterfaceID
> @IDXATTR: fileExtPriority
> @IDXATTR: dnsRoot
> @IDXATTR: mSMQLabelEx
> @IDXATTR: dNSTombstoned
> @IDXATTR: msDS-PhoneticCompanyName
> @IDXATTR: msSFU30Domains
> @IDXATTR: dhcpType
> @IDXATTR: ou
> @IDXATTR: gidNumber
> @IDXATTR: msFVE-VolumeGuid
> @IDXATTR: msTSManagingLS2
> @IDXATTR: implementedCategories
> @IDXATTR: oMTIndxGuid
> @IDXATTR: cOMClassID
> @IDXATTR: volTableIdxGUID
> @IDXATTR: l
> @IDXATTR: mSMQDigests
> @IDXATTR: msTSExpireDate4
> @IDXATTR: flatName
> @IDXATTR: msSFU30YpServers
> @IDXATTR: packageFlags
> @IDXATTR: mSMQOwnerID
> @IDXATTR: objectCategory
> @IDXATTR: msSFU30IsValidContainer
> @IDXATTR: msTSProperty02
> @IDXATTR: mS-DS-CreatorSID
> @IDXATTR: proxyAddresses
> @IDXATTR: msPKI-Cert-Template-OID
> @IDXATTR: uNCName
> @IDXATTR: mS-SQL-Name
> @IDXATTR: fSMORoleOwner
> @IDXATTR: msSFU30NisDomain
> @IDXATTR: otherMailbox
> @IDXATTR: location
> @IDXATTR: msSFU30NetgroupHostAtDomain
> @IDXATTR: uSNChanged
> @IDXATTR: sIDHistory
> @IDXATTR: birthLocation
> @IDXATTR: msDS-SecondaryKrbTgtNumber
> @IDXATTR: msTSProperty01
> @IDXATTR: msTSManagingLS4
> @IDXATTR: msSFU30OrderNumber
> @IDXATTR: msDS-HABSeniorityIndex
> @IDXATTR: primaryGroupID
> @IDXATTR: mSMQQueueType
> @IDXATTR: msDFSR-ReplicationGroupGuid
> @IDXATTR: msDS-PhoneticDepartment
> @IDXATTR: mail
> @IDXATTR: msSFU30Name
> @IDXATTR: msSFU30NetgroupUserAtDomain
> @IDXATTR: fromServer
> @IDXATTR: displayName
> @IDXATTR: msTSLicenseVersion2
> @IDXATTR: groupType
> @IDXATTR: msTSLicenseVersion3
> @IDXATTR: msTSLicenseVersion4
> @IDXATTR: userAccountControl
> @IDXATTR: physicalLocationObject
> @IDXATTR: servicePrincipalName
> @IDXATTR: msTSExpireDate
> @IDXATTR: serviceClassName
> @IDXATTR: lDAPDisplayName
> @IDXATTR: zarafaAccount
> @IDXATTR: terminalServer
> @IDXATTR: givenName
> @IDXATTR: msTSManagingLS3
> @IDXATTR: msSFU30MaxUidNumber
> @IDXATTR: msDS-Entry-Time-To-Die
> @IDXATTR: msTSLSProperty01
> @IDXATTR: msDS-PhoneticFirstName
> @IDXATTR: trustPartner
> @IDXATTR: msTSLSProperty02
> @IDXATTR: msTSExpireDate3
> @IDXATTR: objectGUID
> @IDXATTR: showInAdvancedViewOnly
> @IDXATTR: rpcNsTransferSyntax
> @IDXATTR: sAMAccountName
> @IDXATTR: mS-SQL-Version
> @IDXATTR: msDS-Site-Affinity
> @IDXATTR: sn
> @IDXATTR: name
> @IDXATTR: nETBIOSName
> @IDXATTR: sAMAccountType
> @IDXATTR: msTSManagingLS
> @IDXATTR: msDFSR-DfsPath
> @IDXATTR: altSecurityIdentities
> @IDXATTR: USNIntersite
> @IDXATTR: msSFU30MasterServerName
> @IDXATTR: msDS-PhoneticLastName
> @IDXATTR: cn
> @IDXATTR: netbootGUID
> @IDXATTR: lastLogonTimestamp
> @IDXATTR: legacyExchangeDN
> @IDXATTR: mSMQLabel
> @IDXATTR: uSNCreated
> @IDXATTR: mS-SQL-Database
> @IDXATTR: msDS-PhoneticDisplayName
> @IDXATTR: msSFU30MaxGidNumber
> @IDXATTR: rpcNsObjectID
> @IDXATTR: timeVolChange
> @IDXATTR: msTSExpireDate2
> @IDXATTR: groupAttributes
> @IDXATTR: physicalDeliveryOfficeName
> @IDXATTR: msFVE-RecoveryGuid
> @IDXATTR: msDS-AdditionalSamAccountName
> @IDXATTR: objectSid
> @IDXATTR: keywords
> @IDXATTR: mS-SQL-Alias
> @IDXATTR: invocationId
> @IDXATTR: msTSLicenseVersion
> @IDXATTR: requiredCategories
> @IDXATTR: msDS-AzObjectGuid
> distinguishedName: @INDEXLIST
> 
> There is any way to improve LDAP responses times ? It seems there is only
> one process which is managing LDAP queries (no forks/threads?)
> 
> Thank you in advance for your help !!
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba





-- 



www.it-optics.com 
        
Gaëtan SLONGO | Head of Infrastructure Department
Boulevard Initialis, 28 - 7000 Mons, BELGIUM

Company :
        
+32 (0)65 84 23 85

Direct :
        
+32 (0)65 32 85 88

Fax :
        
+32 (0)65 84 66 76

Skype ID :
        
gslongo.pro

GPG Key :
        
gslongo-gpg_key.asc 



        



- Please consider your environmental responsibility before printing this e-mail
-


 


 


 


 


 




-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba





-- 



www.it-optics.com 
	
Gaëtan SLONGO | Head of Infrastructure Department
Boulevard Initialis, 28 - 7000 Mons, BELGIUM

Company :
	
+32 (0)65 84 23 85

Direct :
	
+32 (0)65 32 85 88

Fax :
	
+32 (0)65 84 66 76

Skype ID :
	
gslongo.pro

GPG Key :
	
gslongo-gpg_key.asc 



	



- Please consider your environmental responsibility before printing this e-mail
-

Possibly Parallel Threads

Search for more seemingly similar threads

samba - Mar 2017 - [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

[Samba] [Samba 4.5] Very slow LDAP Queries (almost unusable), performance tunning ?

Possibly Parallel Threads