Database locking during kprops, MIT 1.8
Dominic Hargreaves
dominic.hargreaves at oucs.ox.ac.uk
Fri Oct 8 07:42:32 EDT 2010
On Fri, Oct 08, 2010 at 09:47:50AM +1100, Jeremy Hunt wrote:
>
> Hi Dominic,
>
> I would recommend having a look at iprop. The update mechanism has less impact than yours.
>
> It checks the log timestamps and when it notices a difference between two sysatme it propagates only differences in the logs rather than the whole database. This should be a lot less than 12 secs for you, so your timeout problem should disappear.
Yup. I think we have a quick workaround now and upgrading our slaves
is already on our todo list :)
> The provisos I see are:
> 1. profile changes do not appear to be logged and propagated via iprop.
> 2. occasionally iprop gets lost and decides to do a full propagation, for that scenario you will get your timeouts, but it will be a lot less frequent than what you are currently getting.
> 3. it is documented as losing connectivity occasionally and so may need to be restarted.
>
> I am currently in the process of putting this into production and my testing has had pleasing results. I have only been able to force full propagation by generating much heavier loads than we see in our environment. I have not seen 3 at all and 1 is not really an issue for us, it is just something I noticed in testing.
>
> You could probably mitigate 1 and 2 by a full propagation independently at a quiet time once a night, week or whatever.
>
> You could mitigate 3 by monitoring the logs and restarting occasionally, probably with a script using the new utility kproplog.
This sounds like useful information for planning such an upgrade;
thanks! Out of interest have you filed bugs for these issues (1 and 3
anyway; 2 is as designed and there probably isn't any way round that,
although increasing the size of the iprop buffer may, AIUI, help).
Dominic.
--
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20101008/96af5bdf/attachment.bin
More information about the Kerberos
mailing list