🚀 go-pugleaf

In news.software.b, article <1gli95INNid5@cat.cis.Brown.EDU>,
  JIM@brownvm.brown.edu (James Mathiesen) writes:
> You may have the same gottcha we found last week.  (We run INN 1.2 on Ultrix
> 4.2 with two RZ58 drives, so we have pretty similar systems)
> 
Ah. We switched from that to a SPARCish server with nice, big, fast SCSI
drives a few weeks ago.

> Our symptoms were a machine that froze at random intervals for
> up to 20 seconds with innd in disk-wait.
> 
> In our case the problem was the interaction between dbz and innd.
> innd calls dbzincore() to keep the history.pag index in memory.
> After every 10 updates of the .pag file, innd calls dbzsync() to
> update the .pag on disk.  The problem is that dbzsync simply
> writes the entire 6 meg .pag file out -- about 100 times an hour.
> No wonder the disk was busy all the time...
> 
The 10-updates stuff seems to me slightly excessive. I have changed the
number to 500 (ICD_SYNC_COUNT in config/config.data) on our systems.
(If there's a crash, we run expire -ln before restarting innd.)

> A more elegent solution is to let dbz() have a write-through cache,
> this lets .pag be kept in memory, but updates are written to disk
> as they occur.  I'm enclosing patches below to dbz.c, dbz.h and
> his.c that add and use dbzwritethough().
> 
Thanks.

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/