#48950 Change example in /etc/sysconfig/dirsrv to use tcmalloc
Closed: wontfix None Opened 7 years ago by nhosoi.

tail -n 5 /etc/sysconfig/dirsrv
# jemalloc is a general purpose malloc implementation that emphasizes
# fragmentation avoidance and scalable concurrency support.  jemalloc
# has been shown to have a significant positive impact on the Directory
# Server's process size/growth.
#LD_PRELOAD=/usr/lib64/dirsrv/libjemalloc.so.1 ; export LD_PRELOAD

This should be changed to tcmalloc.
Change is required by https://bugzilla.redhat.com/show_bug.cgi?id=1301224

Is this good enough?

LD_PRELOAD=/usr/lib64/dirsrv/libtcmalloc.so.4 ; export LD_PRELOAD

Replying to [comment:1 nhosoi]:

Is this good enough?

LD_PRELOAD=/usr/lib64/dirsrv/libtcmalloc.so.4 ; export LD_PRELOAD

I don't believe this is the correct path. We need to use the path for where tcmalloc is installed via the RPM that includes it (which may vary per platform, though I haven't checked Fedora vs. CentOS/RHEL).

Replying to [comment:1 nhosoi]:

Is this good enough?

LD_PRELOAD=/usr/lib64/dirsrv/libtcmalloc.so.4 ; export LD_PRELOAD

This is definitely wrong. The previous line was from when we bundled jemalloc in DS (which was later removed). On fedora and rhel its /usr/lib64/libtcmalloc.so.4

We can always add a comment saying this is just an example and it could be different per OS platform.

Thanks for your comments, Nathan and Mark!

I did not spend any time on this... I just expected it could be just one line fix... :p

Mark, could you please take care of this? Thanks!!

Replying to [comment:4 nhosoi]:

Thanks for your comments, Nathan and Mark!

I did not spend any time on this... I just expected it could be just one line fix... :p

Mark, could you please take care of this? Thanks!!

No problem

43de686..06a4adb master -> master
commit 06a4adb
Author: Mark Reynolds mreynolds@redhat.com
Date: Thu Aug 11 10:50:02 2016 -0400

Sadly, systemd does not like "; export LD_PRELOAD"...
{{{
LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 ; export LD_PRELOAD
^^^^^^^^^^^^^^^^^^^
This part confuses systemd. Error are logged in journalctl on dirsrv startup:

Aug 22 20:13:51 rhel7ds.brq.redhat.com ds_systemd_ask_password_acl[4891]: ERROR: ld.so: object ';' from LD_PRELOAD cannot be preloaded: ignored.
}}}

Hi Mark, just nitpicking, but now there are the lines:

if using systemd, omit the "; export VARNAME" at the end

but no more export to omit, wouldn't this work

PID_TIME=600 #; export PID_TIME

on systemd uncomment the line, on non-systemd also uncomment the export part

Hi,

According to the patch the text will include ::
"tcmalloc is available on RHEL/Fedora in the gperftools package (this could be different on other platforms)."

Today I tried to install gperftools rpm on my RHEL73 machine and it says "No package gperftools available." I have installed gperftools-libs which was available.

Would it be good to add the statement that "do yum install gperftools-libs" which is actually available on RHEL and will also do the needful.

I avoided the export statement because of systemd and uncommented "LD_PRELOAD=/usr/lib64/libtcmalloc.so.4 and restarted the dirsrv.

Now to check the tcmalloc, I did ::

ps -aef | grep slapd

dirsrv 23661 1 0 18:19 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-

pldd 23661 | grep tcmalloc

/usr/lib64/libtcmalloc.so.4

So it works.

And is this document "http://www.port389.org/docs/389ds/FAQ/jemalloc-testing.html" also qualifies the testing for tcmalloc?

Thanks,
Amita

New patch is attached...

2fb3c27..1e44c1f master -> master
commit 1e44c1f
Author: Mark Reynolds mreynolds@redhat.com
Date: Thu Aug 25 13:39:25 2016 -0400

Replying to [comment:12 amsharma]:

And is this document "http://www.port389.org/docs/389ds/FAQ/jemalloc-testing.html" also qualifies the testing for tcmalloc?

It does not. I only ran a few tests with tcmalloc, and it gave almost the same results as jemalloc.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.5.13

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2009

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata