>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am
18.03.2020 um 19:57 in
Nachricht
<30206_1584557842_5E726F12_30206_1570_1_20200318195706.1d992aa0(a)pink.fritz.box>:
Am Wed, 18 Mar 2020 17:16:53 +0000
schrieb <Markus.Storm(a)t-systems.com>:
> Dear all,
>
> we're currently testing performance of OpenLDAP on Oracle/RedHat
> Linux and quite unexpected actually hit systemd-journald to be a
> bottleneck. While OpenLDAP happily makes use of all available CPUs,
> that one is single threaded, braking everything. The only way around
> I have found is to set olcLoglevel to 0, speeding up my test run by a
> factor of 6(!). That now of course is not an option to use in
> production. I'd happily directly write to a file as I did in the old
> days but I cannot get olcLogfile to work. And even if I was able to
> get there, how do I stop OpenLDAP from logging to syslogd (which is
> inevitably forwarding everything to system-journald ....) ? Can
> anyone give advice how to handle this ? Any hint appreciated (short
> of "get a decent OS" - that is not an option).
I support Qanah's advice!
Beside this, consider a logging strategy based on required information
and neglected information, as well as min. and max. server load.
Based on my experience I would disable logging as default, but enable
logging for a short given time, just a modify operation on atribute
olcLogLevel.
With regard to journald I advice to define filters, see man
journalctl(1).
If syslog is a requirement, change to rsyslog. Don't make use of
logstash!
Can't openLDAP simply log to a different port than the default syslog port?
If so, just set up some alternate local syslog server.
Or, in case an external syslog server is supported, just use one that isn't
using systemd-journald.
Sorry, I neved had the need to use a different syslog mechanism...
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E