Today at 10:01am, Mark Cairney wrote:
My present /etc/systemd/journald.conf contains the following- these
are the defaults from our config management system and I haven't found
a need to adjust them yet (although they do look a bit looser than the
For day-to-day operations I'm not noticing any limiting kicking in.
During operations that generate a lot of logs e.g. re-syncing a replica,
SLAMD benchmarking logs do indeed get lost but this is preferable to the
alternative where the logger becomes the bottleneck and slapd is
essentially sitting there waiting for logs to be written before continuing.
Thanks! That's similar to one of the configs I had tried (though I did
not make the journald log persistent). I'll try again.
RE: bringing up a replica I'd avoid using syncrepl from scratch- I find
building the slave from a dump of the master is far quicker and more
reliable. I tend to do (as a brief/trivial example):
Importing this with slapadd takes me about 5 mins for a 1.5G ldif
using mdb- it took about 15-20 mins when I was using bdb. With any luck
the replica will then pick up any changes that have been made to the
master since the dump when you start slapd.
The usual disclaimer that this is just what's working for me and not a
definitive "this is how it should be done"
Yeah, I do the same in production. In my test environment, firing up an
empty replica is a good way to generate a lot of traffic that needs to
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)