> On Jan 3, 2023, at 5:17 AM, Quanah Gibson-Mount <[email protected]> wrote: > > --On Friday, December 30, 2022 11:35 PM +0000 Christopher Paul > <[email protected]> wrote: > >> Using the oldie but goodie LDAP performance testing tool, SLAMD, I've >> been doing performance tests. What I found was that stats logging >> (olcLogLevel: 256) degrades performance significantly. A pity, because it >> is recommended in the manual. Also, it considered very useful by those of >> us who've been running OpenLDAP for a while. > > Yes, this is a well known, documented, and discussed issue. It makes logical > sense if you think of the massive overhead incurred with logging lots of > information vs logging nothing at all. I would note that the amount of perf > hit taken depends on the system setup. For example, if systemd is doing > logging along with syslog, which is often the case these days, then that's > your worst case scenario, followed by just direct logging to syslog being the > next worst. > > You might want to play with OpenLDAP 2.6 which allows direct logging to a > logfile on disk, completely bypassing systemd and/or syslog, this is your > best case scenario currently for when logging is necessary.
It gets worse on RHEL systems due to rate limiting, where large swaths of statements are skipped entirely. I concur with Quanah. Use the 2.6 logger. My tests w/ a log level of sync (which includes stats), showed a perf boost of approximately a factor or 2. I suppose one could achieve the same on earlier releases by disabling syslog and enabling the debug logger instead? — Shawn
