[EMAIL PROTECTED] (Shane Wright) wrote in message news:[EMAIL PROTECTED]...
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
getting some weird performance at times.
When the db is under medium-heavy load, it periodically spawns a
'checkpoint subprocess' which
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
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
Greg Mennie wrote:
[EMAIL PROTECTED] (Shane Wright) wrote in message news:[EMAIL PROTECTED]...
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
getting some weird performance at times.
When the db is under medium-heavy load, it periodically spawns a
On Wed, 11 Feb 2004, Peter Galbavy wrote:
scott.marlowe wrote:
Oh, spreading misinformation isn't lying? You live in a different
world than I do.
Again, I apologise if you took my comment so strongly. I can understand when
something that someone works on so hard is critisised. OTOH
scott.marlowe wrote:
I don't know who you think you are, but I've physically tested the
stuff I'm talking about. Care to qualify what you mean?
I would genuinely be interested in seeing the results and the methodology.
IDE drives (all the ones I've ever tested) LIE about their write
caches
scott.marlowe [EMAIL PROTECTED] writes:
Unfortunately not --- at checkpoint time, the constraint goes the other
way. We have to be sure all the data file updates are down to disk
before we write a checkpoint record to the WAL log. So you can still
get screwed if the data-file drive lies
On Mon, 9 Feb 2004, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
That said we have a really HUGE (~200 drive) IDE storage array my web /
app server sits on top of. No clue if that thing will reliably work under
a database, and I'm in no hurry to find out.
But since the
On Tue, 10 Feb 2004, Peter Galbavy wrote:
scott.marlowe wrote:
I don't know who you think you are, but I've physically tested the
stuff I'm talking about. Care to qualify what you mean?
I would genuinely be interested in seeing the results and the methodology.
IDE drives (all the
If he doesn't have the wit to respond then he's just a troll anyway.
Well, I still feel I should apologize for my harshness on a public list.
I could have at least taken that one private. But you are right, I did
spend a lot of my time chasing down the IDE issues, so to be so flippantly
-Original Message-
From: scott.marlowe [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 4:37 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] hanging for 30sec when checkpointing
On Mon, 9 Feb 2004 [EMAIL PROTECTED] wrote:
If you're gonna accuse me of lying, you damned
scott.marlowe wrote:
Also, running on SCSI drives will be much faster than running on IDE
drives if the IDE drives have their caches disabled like they should,
since they lie otherwise. Since SCSI disks don't usually lie, and are
designed to handle multiple requests in parallel, they are much
On Sat, Feb 07, 2004 at 10:56:57AM -, Peter Galbavy wrote:
Nice to see old fashioned misinformation being spread around the place...
Do you care to clarify that remark? Because there's _plenty_ of
evidence that some IDE drives do not tell the truth about what
they're doing, and that SCSI
Hi
Thanks to you all for your help! I'm continually impressed with how responsive and knowledgeable y'all are!
To clarify; it's an IDE drive with a reiserfs filesystem. DMA is definately enabled, sequential reads pull 35Mb/sec sustained.
The I/O caused by the checkpoint just seems to be too
Shane Wright [EMAIL PROTECTED] writes:
Hmm that gives me an idea, for bulk processing, is there a way of
detecting from a client when a checkpoint is about to happen so it can
wait until it's finished?
No, but maybe you could think about scheduling checkpoints yourself
to not coincide with
Tom,
Damn, why didn't I think of that myself...
Although, is there any performance implication of not doing checkpoints very often? (aside from, I assume, that each checkpoint will take longer and hence saturate available I/O for longer)
Cheers
Shane
On 6 Feb 2004, at 15:33, Tom Lane wrote:
On Fri, Feb 06, 2004 at 12:34:47PM -0500, Tom Lane wrote:
Mmm, right, I forgot to mention that one, which was a bit silly
considering that that was the focus of the discussion. No, infrequent
checkpoints won't hurt performance between checkpoints.
In my experience, though, they do hurt _quite
On Wed, 4 Feb 2004, Iain wrote:
If I understand checkpoints correctly, data that is already written to the
WAL (and flushed to disk) is being written to the DB (flushing to disk).
Meanwhile, other writer transactions are continuing to busily write to the
WAL. In which case a disk bandwidth
I've seen similar behaviour with other disk-intensive apps, and in every
case it transpired that DMA was not enabled on the relevant disk/s -
something to check, certainly.
On Tue, 3 Feb 2004, Shane Wright wrote:
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
getting some weird performance at times.
When the db is under medium-heavy load, it periodically spawns a
'checkpoint subprocess' which runs for between 15 seconds and a minute.
Ok, fair enough, the only problem is
Shane Wright [EMAIL PROTECTED] writes:
When the db is under medium-heavy load, it periodically spawns a
'checkpoint subprocess' which runs for between 15 seconds and a minute.
It sounds like checkpoint is saturating your disk bandwidth.
I've looked at the documentation and various bits
] hanging for 30sec when checkpointing
Hi,
I'm running a reasonable sized (~30Gb) 7.3.4 database on Linux and I'm
getting some weird performance at times.
When the db is under medium-heavy load, it periodically spawns a
'checkpoint subprocess' which runs for between 15 seconds and a minute
22 matches
Mail list logo
