From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
Cc: | Greg Mennie <gjm(at)caledoncard(dot)com>, <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: hanging for 30sec when checkpointing |
Date: | 2004-02-13 00:28:17 |
Message-ID: | Pine.LNX.4.33.0402121727560.6927-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, 12 Feb 2004, Steve Crawford wrote:
> > > I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux
> > > and I'm getting some weird performance at times.
> <snip>
> > I am having a similar problem and this is what I've found so far:
> >
> > During the checkpoint the volume of data that's written isn't very
> > high and it goes on for a fairly long time (up to 20 seconds) at a
> > rate that appears to be well below our disk array's potential. The
> > volume of data written is usually 1-5 MB/sec on an array that we've
> > tested to sustain over 50 MB/sec (sequential writes, of course).
> >
> > It turns out that what's going on is that the command queue for the
> > RAID array (3Ware RAID card) is filling up during the checkpoint
> > and is staying at the max (254 commands) for most of the
> > checkpoint. The odd lucky insert appears to work, but is extremely
> > slow. In our case, the WAL files are on the same array as the data
> > files, so everything grinds to a halt.
>
> I spoke with some 3Ware reps at a trade show and they recommended
> adding the following to /etc/sysctl.conf:
> vm.max-readahead = 256
> vm.min-readahead = 128
>
> These settings take effect at boot. To change on a running system:
> echo 256 > /proc/sys/vm/max-readahead
> echo 128 > /proc/sys/vm/min-readahead
Note that if you edit /etc/sysctl.conf and want the changes to take
effect, you can do so with:
sysctl -p
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-13 00:29:35 | Re: No space left on device |
Previous Message | Ansley, Tom | 2004-02-13 00:00:13 | unsubscribe |