[32782] in Kerberos
Re: Database locking during kprops, MIT 1.8
daemon@ATHENA.MIT.EDU (Dominic Hargreaves)
Fri Oct 8 08:48:03 2010
Date: Fri, 8 Oct 2010 12:42:32 +0100
From: Dominic Hargreaves <dominic.hargreaves@oucs.ox.ac.uk>
To: Jeremy Hunt <jeremyh@optimation.com.au>
Message-ID: <20101008114232.GC3946@gunboat-diplomat.oucs.ox.ac.uk>
MIME-Version: 1.0
In-Reply-To: <24178284.1286491715298.JavaMail.root@safetgram>
Cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============1555104959=="
Errors-To: kerberos-bounces@mit.edu
--===============1555104959==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl"
Content-Disposition: inline
--0vzXIDBeUiKkjNJl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 i=
mpact 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 d=
atabase. This should be a lot less than 12 secs for you, so your timeout pr=
oblem 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 freque=
nt 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 test=
ing has had pleasing results. I have only been able to force full propagati=
on 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.
--=20
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
--0vzXIDBeUiKkjNJl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkyvA58ACgkQJoBKzwmMf2Z5VwCfYuaTsuJfqxncQn+kCAu/tr3I
WlcAn02BcOBGejEmjOqIsrgR3FlxqtDy
=+0XK
-----END PGP SIGNATURE-----
--0vzXIDBeUiKkjNJl--
--===============1555104959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1555104959==--
