On Sat, 1 Mar 2008, Craig James wrote:
Right, I do understand that, but reliability is not a top priority in this
system. The database will be replicated, and can be reproduced from the raw
data.
So what you're saying is:
1. Reliability is not important.
2. There's zero write traffic once th
Subject about says it all. Should I be more concerned about checkpoints
happening 'frequently' or lasting 'longer'? In other words, is it ok to
checkpoint say, every 5 minutes, if it only last a second or three or better
to have checkpoints every 10 minutes that last half a minute? Stupid exampl
On Mar 2, 2008, at 11:02 PM, Steve Poe wrote:
It seems the RAID card manufacturers have more to do with failures
than the drives themselves. Have you found a RAID card you did not
have to drop to U160?
The only array for which I've had to drop to U160 on an LSI card is
the Dell array. I th
On Mar 2, 2008, at 11:23 PM, Scott Marlowe wrote:
And I've never had any of the problems you list with LSI cards. The
only issue I've seen is mediocre RAID-10 performance on their cards
I don't fault the LSI card. The 320-2X is by far one of the fastest
cards I've ever used, and the most
Matthew wrote:
On Sat, 1 Mar 2008, Craig James wrote:
Right, I do understand that, but reliability is not a top priority in
this system. The database will be replicated, and can be reproduced
from the raw data.
So what you're saying is:
1. Reliability is not important.
2. There's zero write
Matthew wrote:
On Sat, 1 Mar 2008, Craig James wrote:
Right, I do understand that, but reliability is not a top priority in
this system. The database will be replicated, and can be reproduced
from the raw data.
So what you're saying is:
1. Reliability is not important.
2. There's zero write
On Mon, 3 Mar 2008, Mark Mielke wrote:
Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0 is
faster for these sorts of loads? My understanding is that RAID 1+0 *can*
reduce latency for reads, but that it relies on random access, whereas RAID 0
performs best for sequential scan
On Mar 3, 2008, at 12:16 AM, Greg Smith wrote:
I've collected up many of the past list comments on this subject and
put a summary athttp://www.postgresqldocs.org/index.php/SCSI_vs._IDE/SATA_Disks
I'll add a recommendation of Partners Data Systems http://www.partnersdata.com/
as a great ven
Matthew wrote:
On Mon, 3 Mar 2008, Mark Mielke wrote:
Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0
is faster for these sorts of loads? My understanding is that RAID 1+0
*can* reduce latency for reads, but that it relies on random access,
whereas RAID 0 performs best for
On Mon, Mar 3, 2008 at 8:25 AM, Douglas J Hunley <[EMAIL PROTECTED]> wrote:
> Subject about says it all. Should I be more concerned about checkpoints
> happening 'frequently' or lasting 'longer'? In other words, is it ok to
> checkpoint say, every 5 minutes, if it only last a second or three or b
Hello
---
Postgresql version: 8.1.10
4GB RAM
2x HP 72GB 10K SAS RAID1/smartarray
---
I have a colleague that is having som performance problems from time to
time when deleting some rows from a table.
We found out that the database having this probl
On Mon, Mar 3, 2008 at 8:48 AM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Matthew wrote:
> > On Sat, 1 Mar 2008, Craig James wrote:
> >> Right, I do understand that, but reliability is not a top priority in
> >> this system. The database will be replicated, and can be reproduced
> >> from the r
On Mon, 3 Mar 2008, Douglas J Hunley wrote:
In other words, is it ok to checkpoint say, every 5 minutes, if it only
last a second or three or better to have checkpoints every 10 minutes
that last half a minute?
When checkpoints do too much work at once they will block clients for a
significa
On Mon, 3 Mar 2008, Chris Browne wrote:
Now, if you have reasonable settings (I'm not sure how well its tuning
is documented :-(), checkpoint "flushes" should be able to be short,
however infrequent they may be. In effect, the "oops, the database got
blocked by checkpoint flushing" issue shoul
Rafael Martinez <[EMAIL PROTECTED]> writes:
> manage=# EXPLAIN ANALYZE DELETE FROM module WHERE deviceid='7298';
> QUERY PLAN
> -
> Nested Loop (cost=0.00..14.63 rows=1 width=67) (actual
> time=2.365..
[EMAIL PROTECTED] (Douglas J Hunley) writes:
> Subject about says it all. Should I be more concerned about checkpoints
> happening 'frequently' or lasting 'longer'? In other words, is it ok to
> checkpoint say, every 5 minutes, if it only last a second or three or better
> to have checkpoints ev
Greg Smith wrote:
On Sat, 1 Mar 2008, Steve Poe wrote:
SATA over SCSI?
I've collected up many of the past list comments on this subject and put
a summary at
http://www.postgresqldocs.org/index.php/SCSI_vs._IDE/SATA_Disks
Should this section:
ATA Disks... Always default to the write cache
I've got a new server and am myself new to tuning postgres.
Server is an 8 core Xeon 2.33GHz, 8GB RAM, RAID 10 on a 3ware 9550SX-4LP w/ BBU.
It's serving as the DB for a fairly write intensive (maybe 25-30%) Web
application in PHP. We are not using persistent connections, thus the
high max conne
"alan bryan" <[EMAIL PROTECTED]> wrote:
>
> I've got a new server and am myself new to tuning postgres.
>
> Server is an 8 core Xeon 2.33GHz, 8GB RAM, RAID 10 on a 3ware 9550SX-4LP w/
> BBU.
>
> It's serving as the DB for a fairly write intensive (maybe 25-30%) Web
> application in PHP. We are
On Mon, Mar 3, 2008 at 4:26 PM, Bill Moran
<[EMAIL PROTECTED]> wrote:
> > > cat /boot/loader.conf
> > kern.ipc.semmni=256
> > kern.ipc.semmns=512
> > kern.ipc.semmnu=256
> >
> > > cat /etc/sysctl.conf
> > kern.ipc.shmall=393216
> > kern.ipc.shmmax=1610612736
>
> I would just set this to 2
On Mon, 3 Mar 2008, alan bryan wrote:
pgbench -c 100 -t 1000 testdb
tps = 558.013714 (excluding connections establishing)
Just for testing, I tried turning off fsync and got:
tps = 4061.662041 (excluding connections establishing)
This is odd. ~500 is what I expect from this test when there
21 matches
Mail list logo
