[389-users] performance tuning

2017-11-16 Thread Sergei Gerasenko
Hi, I’ve been trying to estimate how optimal our settings are. I’ve read about the cn=monitor section and I see that there are several paths that have cn=monitor: dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config dn:

[389-users] Performance tuning OS side

2012-02-01 Thread Marco Pizzoli
Hi *, I'm exploring 389 after few years with OpenLDAP and I'm curious to know if some perfomance tuning tricks on Linux are valid with this product too. - having a db directory located in a dedicated filesystem mounted with the noatime option - LD_PRELOAD=tcmalloc Any other hints? Thanks in

Re: [389-users] Performance tuning OS side

2012-02-01 Thread Mark Reynolds
Hi Marco, This is isn't linux specific, but disabling the logs(access error) can help. If you need the logs, move them to a dedicated FS. I don't know if Linux has a FS cache, but on Solaris I've seen it is sometimes more efficient to turn the DS cache settings all the way down, and allow

Re: [389-users] Performance tuning OS side

2012-02-01 Thread Marc Sauton
Disk I/O can be the most common bottleneck, make sure you have enough physical memory to fit id2entry may be one. There are also a few recommendations at http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#system-memory You can move the

Re: [389-users] Performance tuning - where to begin?

2011-02-04 Thread Daniel Fenert
: Re: [389-users] Performance tuning - where to begin? On 2/3/2011 9:29 AM, Daniel Fenert wrote: There are plenty of configuration options, where should I look first? My first guess would be that you've saturated one core. The server probably still processes new connections in a single thread