On Mon, 8 Jul 2002, Doug Fields wrote:
> >Dunno. The CHECKPOINT would probably create a significant number of
> >disk write requests, followed by a sync() request. If that could
> >monopolize an ext3 filesystem for a long time, perhaps that would
> >explain your problem. But I haven't heard similar complaints before.
> >
> >What do you have shared_buffers set to?
>
> pexicast_lg=# show shared_buffers;
> NOTICE: shared_buffers is 65536
> SHOW VARIABLE
>
> I believe this is about 512 megs. I have 8 gigs RAM on this server and
> tried 65536 and before it 32768. Either one seems to work fine - I didn't
> notice any significant performance difference yet between them.
Try 1024, and see if it makes a difference. If it still doesn't help,
bring up your system with whatever kernel boot parameter you need to to
make it think there's only, 256 MB of RAM in the system, and see if
the problem goes away.
What kind of disk subsystem do you have on this machine? How many MB/sec
can you write to the data drives when doing sequential writes? Random
writes? Do you have anything else (such as your logfile) on the same
drives as the data files?
Outside of the disk with the transaction log, do you see any disk
activity between checkpoints? Or, just after a checkpoint, do you see
almost no disk activity (except to the transaction log)?
I'm wondering if perhaps your cached filesystem data blocks are not
being written out as they are generated, but are being saved up and only
written when a checkpoint occurs (and they are forced out). Since you
can cache so many changed blocks, you would have to have a very, very
capable disk subsystem to be able to deal with hundreds of megabytes
being written out all at once, and in more or less random order.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC