[Freeipa-users] ns-slapd high cpu usage
Andrew E. Bruno
aebruno2 at buffalo.edu
Sat Jul 18 01:23:44 UTC 2015
On Thu, Jul 16, 2015 at 10:32:59AM +0200, Ludwig Krispenz wrote:
> Thank you for the data, I think I understand now what is going on.
>
> In the error logs we see only message like (from my test env):
>
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): replay_update: modifys operation (dn="dc=example,dc=com"
> csn=55a82a29000100640000) not sent - empty
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): replay_update: Consumer successfully sent operation with
> csn 55a82a29000100640000
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): Skipping update operation with no message_id (uniqueid
> 7507cb26-e8ac11e2-b2898005-8430f734, CSN 55a82a29000100640000):
>
> This happens if fractional replication is configured as IPA does and the
> changes affect only attributes which will NOT be replicated. So teh local
> RUV will be updated, but since no change is really sent, the consumer RUV is
> not updated and replciation will always set off from an very old starting
> csn. It is a rare scenario where a server receives only mods which are not
> replicated.
>
> I have opened a ticket for this: https://fedorahosted.org/389/ticket/48225
>
> As a workaround can you try to apply a mod on m14-26 which will not be
> stripped, either create a dummy user or add a description attribute to an
> existing object. Repliciation will once again iterate thru all the changes
> (which can take a while), but then should replay this latest change and
> define a new offset
>
Excellent. I can confirm your workaround fixed the issue. I updated a
users email address (on m14-26) and the load came down back to normal
within a few minutes.
Thanks very much for all your help debugging this.
Best,
--Andrew
> Regards,
> Ludwig
>
>
More information about the Freeipa-users
mailing list