accesslog purge starves kerberos kdc authentications

[Paul B. Henson]

Content preview: We're running MIT kerberos with the ldap backend, specifically
3 openldap servers doing delta syncrepl. We started having a problem a while
back where once a day the kdc would time out authentication requests, and
finally tracked it down to openldap purging the accesslog. We currently have
the accesslog overlay configured to delete entries over 7 days old once a
day, and it seems that while openldap is processing the purge the kdc is
starved out and unable to process authentications in a timely fashion. We
do (thanks to our ISO) have account lockout enabled, so every authentication
involves not only a read but a write. [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.23 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0007]

We're running MIT kerberos with the ldap backend, specifically 3
openldap servers doing delta syncrepl. We started having a problem a
while back where once a day the kdc would time out authentication
requests, and finally tracked it down to openldap purging the accesslog.
We currently have the accesslog overlay configured to delete entries
over 7 days old once a day, and it seems that while openldap is
processing the purge the kdc is starved out and unable to process
authentications in a timely fashion. We do (thanks to our ISO) have
account lockout enabled, so every authentication involves not only a
read but a write.

Is it expected for the accesslog purge to be so disruptive? Is there any
way to tune it so it doesn't overwhelm the system to the point of being
unresponsive?

Would it be better to purge the accesslog more frequently as to amortize
the work across multiple intervals rather than being concentrated once a
day?

Thanks for any suggestions...

[Michael Ströder]

Post by Paul B. Henson
We're running MIT kerberos with the ldap backend, specifically 3
openldap servers doing delta syncrepl. We started having a problem a
while back where once a day the kdc would time out authentication
requests, and finally tracked it down to openldap purging the accesslog.
We currently have the accesslog overlay configured to delete entries
over 7 days old once a day, and it seems that while openldap is
processing the purge the kdc is starved out and unable to process
authentications in a timely fashion. We do (thanks to our ISO) have
account lockout enabled, so every authentication involves not only a
read but a write.
Is it expected for the accesslog purge to be so disruptive? Is there any
way to tune it so it doesn't overwhelm the system to the point of being
unresponsive?
Would it be better to purge the accesslog more frequently as to amortize
the work across multiple intervals rather than being concentrated once a
day?

Do you have an eq-index on the reqStart attribute as recommended
in slapo-accesslog(5)?

Note that adding the index later needs re-indexing of the DB.

Ciao, Michael.

[Paul B. Henson]

Content preview: On Wed, Nov 04, 2015 at 07:46:47AM +0100, Michael Ströder
wrote: > Do you have an eq-index on the reqStart attribute as recommended

in slapo-accesslog(5)? Yes: [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.25 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0080]
0.0 T_HDRS_LCASE Odd capitalization of message header
0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers
Cc: openldap-***@openldap.org
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: On Wed, Nov 04, 2015 at 07:46:47AM +0100, Michael Ströder
wrote: > Do you have an eq-index on the reqStart attribute as recommended

in slapo-accesslog(5)? Yes: [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.25 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Do you have an eq-index on the reqStart attribute as recommended
in slapo-accesslog(5)?

Yes:

index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart

[Quanah Gibson-Mount]

Content preview: --On Wednesday, November 04, 2015 6:27 PM -0800 "Paul B. Henson"
<***@acm.org> wrote: > On Wed, Nov 04, 2015 at 07:46:47AM +0100, Michael
Ströder wrote: > >> Do you have an eq-index on the reqStart attribute as
recommended >> in slapo-accesslog(5)? > > Yes: > > index default eq > index
entryCSN,objectClass,reqEnd,reqResult,reqStart [...]

Content analysis details: (-4.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[162.209.122.184 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: acm.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
Cc: openldap-***@openldap.org
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -4.3 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: --On Wednesday, November 04, 2015 6:27 PM -0800 "Paul B. Henson"
<***@acm.org> wrote: > On Wed, Nov 04, 2015 at 07:46:47AM +0100, Michael
Ströder wrote: > >> Do you have an eq-index on the reqStart attribute as
recommended >> in slapo-accesslog(5)? > > Yes: > > index default eq > index
entryCSN,objectClass,reqEnd,reqResult,reqStart [...]

Content analysis details: (-4.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[162.209.122.184 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: zimbra.com]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

--On Wednesday, November 04, 2015 6:27 PM -0800 "Paul B. Henson"

Post by Paul B. Henson

Post by Michael Ströder
Do you have an eq-index on the reqStart attribute as recommended
in slapo-accesslog(5)?

index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart

I set up my accesslog to do the purges every 4 hours by default, rather
than once a day, to get around this. You may want to do it more frequently
than that. I would say once a day clearly isn't often enough for the
amount of write traffic you have.

You also don't note what slapd backend you're using (bdb, hdb, mdb). bdb &
hdb in particular are much slower, write wise, than mdb. And you don't
note your OpenLDAP version, either...

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Paul B. Henson]

Content preview: > From: Quanah Gibson-Mount > Sent: Wednesday, November 04,
2015 6:34 PM > > I set up my accesslog to do the purges every 4 hours by
default, rather > than once a day, to get around this. You may want to do
it more frequently > than that. I would say once a day clearly isn't often
enough for the > amount of write traffic you have. [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.19 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

From: Quanah Gibson-Mount
Sent: Wednesday, November 04, 2015 6:34 PM
I set up my accesslog to do the purges every 4 hours by default, rather
than once a day, to get around this. You may want to do it more frequently
than that. I would say once a day clearly isn't often enough for the
amount of write traffic you have.

I wasn't sure if doing it more frequently would amortize the load to the point where it did not impact production, or simply break production more often :). I guess I'll have to give it a try and see.

You also don't note what slapd backend you're using (bdb, hdb, mdb). bdb &
hdb in particular are much slower, write wise, than mdb. And you don't
note your OpenLDAP version, either...

Sorry, we are running the latest and greatest 2.4.41 with the latest and greatest mdb backend :).

Thanks…

[Ulrich Windl]

Content preview: >>> "Paul B. Henson" <***@acm.org> schrieb am 05.11.2015
um 03:27 in Nachricht <***@bender.unx.cpp.edu>: > On Wed,
Nov 04, 2015 at 07:46:47AM +0100, Michael Ströder wrote: > >> Do you have
an eq-index on the reqStart attribute as recommended >> in slapo-accesslog(5)?

Post by Paul B. Henson

Yes: > > index default eq > index entryCSN,objectClass,reqEnd,reqResult,reqStart

[...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.94.155.52 listed in list.dnswl.org]
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: acm.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Mailman-Approved-At: Thu, 05 Nov 2015 11:39:25 +0000
Cc: openldap-***@openldap.org
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -4.2 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: >>> "Paul B. Henson" <***@acm.org> schrieb am 05.11.2015
um 03:27 in Nachricht <***@bender.unx.cpp.edu>: > On Wed,
Nov 04, 2015 at 07:46:47AM +0100, Michael Ströder wrote: > >> Do you have
an eq-index on the reqStart attribute as recommended >> in slapo-accesslog(5)?

Post by Paul B. Henson

Yes: > > index default eq > index entryCSN,objectClass,reqEnd,reqResult,reqStart

[...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.94.155.52 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: acm.org]
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
Nachricht

Post by Paul B. Henson

Do you have an eq-index on the reqStart attribute as recommended
in slapo-accesslog(5)?

index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart

I use the following additional indexes, but I run some specific queries on the
database (my database is hdb):
olcDbIndex: entryUUID eq
olcDbIndex: reqResult eq
olcDbIndex: reqDN eq
olcDbIndex: reqMod sub
olcDbIndex: reqType eq
olcDbIndex: reqAuthzID eq

And I do not have an index on entryCSN.

Maybe you have an I/O bottleneck? Could you try (for a test) to put the
accesslog into a RAM disk? What filesystem are you using? Special mount
options?

Regards,
Ulrich

[Paul B. Henson]

Content preview: > From: Ulrich Windl > Sent: Wednesday, November 04, 2015
11:26 PM > > Maybe you have an I/O bottleneck? Could you try (for a test)
to put the > accesslog into a RAM disk? What filesystem are you using? Special
mount > options? [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.21 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0017]

From: Ulrich Windl
Sent: Wednesday, November 04, 2015 11:26 PM
Maybe you have an I/O bottleneck? Could you try (for a test) to put the
accesslog into a RAM disk? What filesystem are you using? Special mount
options?

Yes, I'm pretty sure it is an I/O issue. The problem only occurs on the physical servers, the virtual machines (which are on a SAN with much better performance than local disks) don't exhibit this issue. While it is thrashing iotop shows the write load at about 2MB/s. It's on a linux system using ext4, the only special mount option is relatime.

[Ulrich Windl]

Content preview: What type of indexes do you have for your accesslog? Any warning

We're running MIT kerberos with the ldap backend, specifically 3 > openldap

servers doing delta syncrepl. We started having a problem a > while back
where once a day the kdc would time out authentication > requests, and finally
tracked it down to openldap purging the accesslog. > We currently have the
accesslog overlay configured to delete entries > over 7 days old once a day,
and it seems that while openldap is > processing the purge the kdc is starved
out and unable to process > authentications in a timely fashion. We do (thanks
to our ISO) have > account lockout enabled, so every authentication involves
not only a > read but a write. > > Is it expected for the accesslog purge
to be so disruptive? Is there any > way to tune it so it doesn't overwhelm
the system to the point of being > unresponsive? > > Would it be better to
purge the accesslog more frequently as to amortize > the work across multiple
intervals rather than being concentrated once a > day? > > Thanks for any
suggestions... [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.94.155.52 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: acm.org]
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

What type of indexes do you have for your accesslog? Any warning about missing index in syslog?

We're running MIT kerberos with the ldap backend, specifically 3
openldap servers doing delta syncrepl. We started having a problem a
while back where once a day the kdc would time out authentication
requests, and finally tracked it down to openldap purging the accesslog.
We currently have the accesslog overlay configured to delete entries
over 7 days old once a day, and it seems that while openldap is
processing the purge the kdc is starved out and unable to process
authentications in a timely fashion. We do (thanks to our ISO) have
account lockout enabled, so every authentication involves not only a
read but a write.
Is it expected for the accesslog purge to be so disruptive? Is there any
way to tune it so it doesn't overwhelm the system to the point of being
unresponsive?
Would it be better to purge the accesslog more frequently as to amortize
the work across multiple intervals rather than being concentrated once a
day?
Thanks for any suggestions...

[Paul B. Henson]

Post by Ulrich Windl
What type of indexes do you have for your accesslog? Any warning about
missing index in syslog? The overall accesslog config is: database mdb directory

/var/lib/openldap-data/accesslog maxsize 2147483648 suffix cn=accesslog rootdn
cn=accesslog [...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.19 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Ulrich Windl
What type of indexes do you have for your accesslog? Any warning about
missing index in syslog?

The overall accesslog config is:

database mdb
directory /var/lib/openldap-data/accesslog
maxsize 2147483648
suffix cn=accesslog
rootdn cn=accesslog

index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart


overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 07+00:00 01+00:00

I haven't seen any errors or warnings in the openldap logs; the only
reason we noticed was the degraded kerberos performance.

Thanks...

[Dameon Wagner]

Content preview: On Wed, Nov 04 2015 at 18:32:50 -0800, Paul B. Henson scribbled
in "Re: Antw: accesslog purge starves kerberos kdc authentications": > On
Wed, Nov 04, 2015 at 09:08:47AM +0100, Ulrich Windl wrote: > > What type
of indexes do you have for your accesslog? Any warning about > > missing index
in syslog? > > The overall accesslog config is: > > database mdb > directory
/var/lib/openldap-data/accesslog > maxsize 2147483648 > suffix cn=accesslog

rootdn cn=accesslog <SNIP> > I haven't seen any errors or warnings in the

openldap logs; the only > reason we noticed was the degraded kerberos performance.

Thanks... [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[129.67.1.166 listed in list.dnswl.org]
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

On Wed, Nov 04 2015 at 18:32:50 -0800, Paul B. Henson scribbled

What type of indexes do you have for your accesslog? Any warning about
missing index in syslog?

database mdb
directory /var/lib/openldap-data/accesslog
maxsize 2147483648
suffix cn=accesslog
rootdn cn=accesslog

<SNIP>

I haven't seen any errors or warnings in the openldap logs; the only
reason we noticed was the degraded kerberos performance.
Thanks...

Just a simple question, is /var/lib/openldap-data/accesslog on the
same physical disk as the rest of your directory storage? I note from
your initial thread on the kerberos list that there's small io spike
at the same time, so it may be beneficial to have the accesslog on
different spindles if possible.

Cheers.

Dameon.

[Paul B. Henson]

Content preview: > From: Dameon Wagner > Sent: Thursday, November 05, 2015
3:01 AM > > Just a simple question, is /var/lib/openldap-data/accesslog on
the > same physical disk as the rest of your directory storage? I note from

your initial thread on the kerberos list that there's small io spike >

at the same time, so it may be beneficial to have the accesslog on > different
spindles if possible. [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[206.46.173.25 listed in list.dnswl.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20%
[score: 0.0843]

From: Dameon Wagner
Sent: Thursday, November 05, 2015 3:01 AM
Just a simple question, is /var/lib/openldap-data/accesslog on the
same physical disk as the rest of your directory storage? I note from
your initial thread on the kerberos list that there's small io spike
at the same time, so it may be beneficial to have the accesslog on
different spindles if possible.

Yes, it is. The system is a basic 1U server with a hardware RAID card and
mirrored disks. I don't have any other spindles 8-/. One of my colleagues is
giving me the big "I told you so", as he advocated upgrading to the hardware
RAID card with a battery backed write cache which might have prevented this
issue. The rest of us didn't think the extra expenditure was worth it for a
Kerberos server which typically doesn't have very high performance
requirements <sigh>. I guess I'm going to try purging the accesslog more
frequently and seeing if that reduces the individual purge load to a low
enough level that it doesn't impact service response.

Thanks.