Re: logging through systemd-journald is bottleneck

[Dieter Klünter]

Am Wed, 18 Mar 2020 17:16:53 +
schrieb :

> 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!

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

Re: logging through systemd-journald is bottleneck

[Quanah Gibson-Mount]

--On Wednesday, March 18, 2020 6:16 PM + markus.st...@t-systems.com 
wrote:




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).


Hi Markus,

We always advise our customers to disable the abominable syslog<->journald 
integration that RedHat has pushed onto their customers with complete 
disregard to the consequences of this short-sighted action.  Not only does 
it destroy performance, it can also cause the system to completely deadlock.


If you need instructions on how to do this, let me know.

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

logging through systemd-journald is bottleneck

[Markus.Storm]

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).

Thanks,
Markus

write ACL

[Thomas Elsäßer]

Hi ACL Gurus

i would like following ACL , but i'm to stupid.

cn=app1,ou=application,dc=company,dc=de -> groupOfNames


Our Customer Admins are here

cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de  -> groupOfNames
cn=GroupLdapAdmin,o=customer2,ou=customer,dc=company,dc=de ->
groupOfNames  member is the admin of this tree example

member=cn=customer2.admin,ou=user,o=customer2,ou=customer,dc=company,dc=de


  I have 600 Customerx

How can i write one ACL for all customer to access to
cn=app1,ou=application,dc=company,dc=de to write access for
groupLDAPAdmin for every company?

This work for one customer

access to dn.regex="cn=([^,]),ou=application,dc=company,dc=de" by by
set.expand="(user) &
([cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de])/member" write

How can write this for all without write 600 ACL?

Thanx and stays healthy
Thomas