Issue 8907 - Memory leak on mass adding users to ldap
Summary: Memory leak on mass adding users to ldap
Status: VERIFIED INVALID
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.44
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-24 11:02 UTC by nowhereman@nowhereman.ru
Modified: 2020-03-23 20:44 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description nowhereman@nowhereman.ru 2018-08-24 11:02:30 UTC
Full_Name: Alexey Karpov
Version: 2.4.44
OS: RHEL 7.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.245.195.105)


We have two OpenLDAP servers version 2.4.44, running on RHEL 7.5, replicated in
mirror mode and working as active-standby. OpenLDAP works as userstore for WSO2
Identity Server. Servers configured with tls security and valid certificates.
All requests come to first server (ldap1), second server (ldap2) working as
reserve.

When we start batch adding users (about 3-5 inserts per second, mixed with
queries and changing values), we observe a memory leak on server ldap1,
load-dependent, up to gigabyte per minute, and the lag in sync between servers.
If we stop server ldap2, leaking stops and server ldap1 working properly. Memory
is not freeing until server is restarted.

Also we try this setup with version 2.4.44 on Centos 7 and custom builded
version 2.4.46 on Centos 7. Results are the same - on batch adding users,
server, receiving requests has memory leak and leaking stops when second server
stopped.
Comment 1 Quanah Gibson-Mount 2018-11-16 20:18:46 UTC
Hi Alexey,

If you are using standard syncrepl (rather than delta-syncrepl), I'm not 
sure what you're reporting is out of the ordinary and is not indicative of 
a memory link.  This is also why the issue "resolves" when ldap2 is 
stopped.  I.e., the issue is related to how syncrepl functions and what it 
stores in memory while the lagging consumer is pulling down the database. 
I suggest switching to using delta-syncrepl and seeing if you see the same 
issue.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


Comment 2 OpenLDAP project 2018-11-16 20:21:09 UTC
Expected behavior with lagging consumer?
Comment 3 Quanah Gibson-Mount 2018-11-16 20:21:09 UTC
changed notes