Hi all,
I just wanted to say, that the high i/o rates where gone more or less
spontaneously. Probably they where related to multimaster replication
and writing data to changelogdb. But we could not trigger down the
reason. After one restart the high i/o rates of one of the three
suppliers in a mul
On Wed, 2018-08-15 at 11:03 -0600, Rich Megginson wrote:
> On 08/15/2018 10:56 AM, David Boreham wrote:
> >
> >
> > On 8/15/2018 10:36 AM, Rich Megginson wrote:
> > >
> > > Updating the csn generator and the uuid generator will cause a
> > > lot of
> > > churn in dse.ldif. There are other hous
On 08/15/2018 10:56 AM, David Boreham wrote:
On 8/15/2018 10:36 AM, Rich Megginson wrote:
Updating the csn generator and the uuid generator will cause a lot of
churn in dse.ldif. There are other housekeeping tasks which will
write dse.ldif
But if those things were being done so frequentl
On 8/15/2018 10:36 AM, Rich Megginson wrote:
Updating the csn generator and the uuid generator will cause a lot of
churn in dse.ldif. There are other housekeeping tasks which will
write dse.ldif
But if those things were being done so frequently that the resulting
filesystem I/O showed up
On 08/15/2018 10:13 AM, David Boreham wrote:
in strace.log:
[pid 8088] 12:55:39.739539 poll([{fd=435, events=POLLOUT}], 1, 180
[pid 8058] 12:55:39.739573 <... write resumed> ) = 1 <0.87>
[pid 8088] 12:55:39.739723 <... poll resumed> ) = 1 ([{fd=435,
revents=POLLOUT}]) <0.000168>
[p
in strace.log:
[pid 8088] 12:55:39.739539 poll([{fd=435, events=POLLOUT}], 1, 180
[pid 8058] 12:55:39.739573 <... write resumed> ) = 1 <0.87>
[pid 8088] 12:55:39.739723 <... poll resumed> ) = 1 ([{fd=435,
revents=POLLOUT}]) <0.000168>
[pid 8058] 12:55:39.739754 write(426, "dn: cn=n
Hi all, thanks for answering,
it took some time until I came again to this problem.
Am 09.08.2018 um 10:44 schrieb Ludwig Krispenz:
>
> On 08/09/2018 01:53 AM, William Brown wrote:
>> Sadly this doesn't tell us much :(
> we could get a pstack along with iotop to see which threads do teh IO,
un
On 8/9/2018 2:44 AM, Ludwig Krispenz wrote:
Sadly this doesn't tell us much :(
we could get a pstack along with iotop to see which threads do teh IO,
regular mods or the BDB regulars like trickle, checkpointing
Also : strace
___
389-users mail
On 08/09/2018 01:53 AM, William Brown wrote:
In the audit-log there is nothing what would explain this. But in
iotop
I see a lot of threads like:
The audit log itself (and search log) will generate IO themself :)
1621 be/4 dirsrv 0.00 B/s3.95 K/s 0.00 % 0.46 % ns-slapd
-D
/etc/di
>
> In the audit-log there is nothing what would explain this. But in
> iotop
> I see a lot of threads like:
The audit log itself (and search log) will generate IO themself :)
>
> 1621 be/4 dirsrv 0.00 B/s3.95 K/s 0.00 % 0.46 % ns-slapd
> -D
> /etc/dirsrv/slapd-ldap0 -i /var/run/d
10 matches
Mail list logo
