On Mon, Mar 12, 2012 at 7:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 11, 2012 at 11:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas robertmh...@gmail.com wrote:
I've finally been able to run some more tests of the effect of
On Tue, Mar 13, 2012 at 11:18 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 13, 2012 at 6:44 PM, Josh Berkus j...@agliodbs.com wrote:
That's a speedup of nearly a factor of two, so clearly fsync-related
stalls are a big problem here, even with wal_buffers cranked up
through the
On Wed, Mar 14, 2012 at 3:29 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I think my analysis is pretty much a re-wording of yours, but I'd
emphasize that getting the WALWriteLock is bad not just because they
fight over the lock, but because someone else (probably background wal
writer) is
On Tuesday, March 13, 2012 03:26:34 AM Robert Haas wrote:
Meanwhile, here are some TPS graphs at 16MB and 32MB on the IBM POWER7
machine. 32 clients, 1800 seconds, scale factor 300, synchronous
commit off.
That graph makes me cringe because its pretty representative of what I have
seen in
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Rerunning all 4 benchmarks (both 16MB and 32MB wal_buffers on both
machines) with fsync=off (as well as synchronous_commit=off still)
might help clarify things.
If it increases the TPS of Nate@16MB, but doesn't change the
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Rerunning all 4 benchmarks (both 16MB and 32MB wal_buffers on both
machines) with fsync=off (as well as synchronous_commit=off still)
might help clarify things.
I reran the 32-client benchmark on the IBM machine with
On Tue, Mar 13, 2012 at 3:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Rerunning all 4 benchmarks (both 16MB and 32MB wal_buffers on both
machines) with fsync=off (as well as synchronous_commit=off still)
might help
On Tue, Mar 13, 2012 at 4:55 AM, Andres Freund and...@anarazel.de wrote:
On Tuesday, March 13, 2012 03:26:34 AM Robert Haas wrote:
Meanwhile, here are some TPS graphs at 16MB and 32MB on the IBM POWER7
machine. 32 clients, 1800 seconds, scale factor 300, synchronous
commit off.
That graph
That's a speedup of nearly a factor of two, so clearly fsync-related
stalls are a big problem here, even with wal_buffers cranked up
through the ceiling.
H. Do you have any ability to test on XFS?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
On Wed, Mar 14, 2012 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 13, 2012 at 3:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Rerunning all 4 benchmarks (both 16MB and 32MB wal_buffers on both
On Tue, Mar 13, 2012 at 10:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 14, 2012 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 13, 2012 at 3:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Mar 13, 2012 at 6:44 PM, Josh Berkus j...@agliodbs.com wrote:
That's a speedup of nearly a factor of two, so clearly fsync-related
stalls are a big problem here, even with wal_buffers cranked up
through the ceiling.
H. Do you have any ability to test on XFS?
It seems I do.
On Sun, Mar 11, 2012 at 11:51 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas robertmh...@gmail.com wrote:
I've finally been able to run some more tests of the effect of
adjusting wal_buffers to values higher than 16MB. I ran the test on
the 16 core
On Sat, Mar 10, 2012 at 7:55 PM, Robert Haas robertmh...@gmail.com wrote:
I've finally been able to run some more tests of the effect of
adjusting wal_buffers to values higher than 16MB. I ran the test on
the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
configuration
On Mon, Mar 12, 2012 at 12:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Nate Boley's machine, the difference was ~100% increase rather than
~10%.
Oh, right. I had forgotten how dramatic the changes were in those
test runs. I guess I should be happy that the absolute numbers on
this
On Mon, Mar 12, 2012 at 10:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 12, 2012 at 12:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Nate Boley's machine, the difference was ~100% increase rather than
~10%.
Oh, right. I had forgotten how dramatic the changes were in those
On Mon, Mar 12, 2012 at 4:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Do you think the difference is in the CPU architecture, or the
IO subsystem?
That is an excellent question. I tried looking at vmstat output, but
a funny thing kept happening: periodically, the iowait column would
show
On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas robertmh...@gmail.com wrote:
I've finally been able to run some more tests of the effect of
adjusting wal_buffers to values higher than 16MB. I ran the test on
the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
configuration
I've finally been able to run some more tests of the effect of
adjusting wal_buffers to values higher than 16MB. I ran the test on
the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
configuration settings:
shared_buffers = 8GB
maintenance_work_mem = 1GB
synchronous_commit = off
19 matches
Mail list logo
