Memory leak after upgrade from 4.1 to 4.4?

Hi all!

After upgrading a DC Backup serving as a mail server from 4.1 to 4.4 I noticed an ever increasing memory usage, already after 4.2 has been reached.

Beyond that you can find lots of messages like this:

Jun 3 11:29:10 myhost slapd[1250]: <= mdb_equality_candidates: (member) not indexed

in syslog. I have no idea, whether there is a connection between these two, but of course I suspect there is. I have read this KB article but still don’t understand why it is necessary to amend the LDAP indexes specifically on this machine. I haven’t seen this on a lot of other machines running with different releases within 4.2-4.3. Unfortunately the only remedy at the moment is restarting the machine.

Best regards

BTW: What’s that “member” attribute? I cannot find any object in the LDAP database containing this attribute.



I observed a massive increase in memory consumption as well since the 4.4 release was applied.


top -o %MEM gives me:


Maybe I’m wrong, but for me clamav looks suspicious.
Any hint what I should check next?

Thx and best regards

@vmayer When the growth happens, please post the output of the following commands:

  1. ps auxw --sort=rss
  2. ps auxw --sort=vsz
  3. df -k /dev/shm
  4. ipcs -m

It doesn’t have to be when the usage is at its peak; as soon as swap starts to get used for real suffices.

Beyond that you can find lots of messages like this:

Those messages have nothing to do with memory usage, even less with its growth. They’re just a note by the LDAP server that a search query could be sped up if there was an index for the attribute looked up.

This attribute (member) is not a real attribute used by the OpenLDAP schema (and therefore slapd). It is used in the Active Directory schema, though (and therefore the LDAP server provided by Samba). My guess is that there’s at least one application targeting the LDAP server that uses a filter which includes the member attribute.

As the OpenLDAP scheme doesn’t normally use said attribute, it isn’t indexed by default. You can add an index for it, which will silence the warning and increase search speed very, very slightly. It might be better to figure out which application sends such a search filter, though (e.g. by increasing the LDAP log level to log all search queries and going from there). Follow the steps in the article you linked to.

Or you can just ignore the warning. It doesn’t really hurt.

@tpfann Your problem does not look like the original poster’s problem. For vmayer the issue is that the memory usage keeps growing and growing until he has to reboot the server. That doesn’t seem to happen to you. Please open a separate topic for your issue — discussing most likely unrelated things in the same topic leads to a lot of confusion. Thanks.

Eventually I upgraded the machine, which I was talking of some months ago in this thread. With the upgrade to 4.4-1 Errata 325 came a new kernel package, and what happened? The problem is gone. Since more than 36 hours memory usage is constant which before started increasing at the latest after 2 hours.

I have no idea why but my initial impression that the problems had to do with some kernel issue seemingly proved to be true. So, anybody @Univention: Have there really been no other installations with similar problems? In case anybody is interested I am willing to share more details. One thing of importance I have not yet mentioned: The machine is running as a HVM-DomU on top of a Xen Host based on Debian Jessie.


I think your problem was caused by pam_systemd:

I’m not so sure, bug #49910 has anything to do with my problem. I started off with UCS 4.1 (no memory leak) and already had the problem with UCS 4.2. The bug report you are citing states only UCS 4.4 as affected by this bug.