Scott,
Long story short, yes I agree, the raids are all kinds of wrong and if I
had been involved in the build processes they would look very different
right now.
I have been playing around with different bs= and count= settings for some
simple dd tests tonight and found some striking differences
I'd be more interested in the random results from bonnie++ but my real
world experience tells me that for heavily parallel writes etc a
RAID-10 will stomp a RAID-6 or RAID-60 on the same number of drives.
On Mon, Mar 4, 2013 at 4:47 PM, Steven Crandell
wrote:
> Mark,
> I ran pg_fsync_test on log
Mark,
I ran pg_fsync_test on log and data LV's on both old and new hardware.
New hardware out performed old on every measurable on the log LV
Same for the data LV's except for the 16kB open_sync write where the old
hardware edged out the new by a hair (18649 vs 17999 ops/sec)
and write, fsync, cl
On Mon, Mar 4, 2013 at 4:17 PM, John Rouillard wrote:
> On Mon, Mar 04, 2013 at 03:54:40PM -0700, Steven Crandell wrote:
>> Here's our hardware break down.
>>
>> The logvg on the new hardware is 30MB/s slower (170 MB/s vs 200 MB/s )
>> than the logvg on the older hardware which was an immediately
On Mon, Mar 04, 2013 at 03:54:40PM -0700, Steven Crandell wrote:
> Here's our hardware break down.
>
> The logvg on the new hardware is 30MB/s slower (170 MB/s vs 200 MB/s )
> than the logvg on the older hardware which was an immediately interesting
> difference but we have yet to be able to crea
On Fri, Mar 1, 2013 at 1:52 AM, Steven Crandell
wrote:
> As far as we were able to gather in the frantic moments of downtime,
> hundreds of queries were hanging up while trying to COMMIT. This in turn
> caused new queries backup as they waited for locks and so on.
>
> Given that we're dealing wit
On 05/03/13 11:54, Steven Crandell wrote:
Here's our hardware break down.
The logvg on the new hardware is 30MB/s slower (170 MB/s vs 200 MB/s )
than the logvg on the older hardware which was an immediately interesting
difference but we have yet to be able to create a test scenario that
success
Here's our hardware break down.
The logvg on the new hardware is 30MB/s slower (170 MB/s vs 200 MB/s )
than the logvg on the older hardware which was an immediately interesting
difference but we have yet to be able to create a test scenario that
successfully implicates this slower log speed in ou
On 2/26/13 4:45 PM, Costin Oproiu wrote:
First, I've got no good explanation for this and it would be nice to
have one. As far as I can understand this issue, the heaviest update
traffic should be on the branches table and should affect all tests.
From http://www.postgresql.org/docs/current/sta
On Mon, Mar 4, 2013 at 6:31 PM, Joseph Pravato
wrote:
> Good Afternoon,
>
> We are having a performance issue with our views in PostgreSQL and based on
> the requirements for assistance you recommend providing the full table and
> index schema besides additional information from this site.
> https
2013/3/4 Joseph Pravato
> We are having a performance issue with our views in PostgreSQL and based
> on the requirements for assistance you recommend providing the full table
> and index schema besides additional information from this site.
> https://wiki.postgresql.org/wiki/Slow_Query_Questions
Good Afternoon,
We are having a performance issue with our views in PostgreSQL and based
on the requirements for assistance you recommend providing the full
table and index schema besides additional information from this site.
https://wiki.postgresql.org/wiki/Slow_Query_Questions
We have been uns
That's around the behavior I'm seeing - I'll be testing tonight! :-)
Den 04/03/2013 kl. 16.23 skrev Scott Marlowe :
> however
On Mon, Mar 4, 2013 at 7:43 AM, AJ Weber wrote:
> Great info, I really appreciate the insight. Is there a FAQ/recommended
> setup for running pgbench to determine where this might be? (Is there a
> reason to setup pgbench differently based on the server's cores/memory/etc?)
Well keep in mind th
Great info, I really appreciate the insight. Is there a FAQ/recommended
setup for running pgbench to determine where this might be? (Is there a
reason to setup pgbench differently based on the server's cores/memory/etc?)
Sorry if this detracts from the OP's original question.
-AJ
On 3/4/201
On Mon, Mar 4, 2013 at 7:04 AM, AJ Weber wrote:
> Apologies for the tangential question, but how would pgpool2 "increase
> throughput"? Wouldn't the same number of statements be issued by your
> application? It would likely reduce the number of concurrent connections,
> but that doesn't necessar
On Thu, Feb 28, 2013 at 11:20 AM, Pavan Deolasee
wrote:
> On Wed, Feb 27, 2013 at 3:15 AM, Costin Oproiu
> wrote:
>> I took some time to figure out a reasonable tuning for my fresh 9.2.3
>> installation when I've noticed the following:
>>
>> [costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.
On 04/03/13 13:52, Niels Kristian Schjødt wrote:
LSI MegaRAID SAS 9260-4i with four Intel SSDSC2CW240A3K5 SSDs OR four Hitachi
Ultrastar 15K600 SAS drives?
My app is pretty write heavy and I have a lot of concurrent connections 300 -
(though considering adding pgpool2 in front to increase th
Apologies for the tangential question, but how would pgpool2 "increase
throughput"? Wouldn't the same number of statements be issued by your
application? It would likely reduce the number of concurrent
connections, but that doesn't necessarily equate to "increased throughput".
-AJ
On 3/4/2
LSI MegaRAID SAS 9260-4i with four Intel SSDSC2CW240A3K5 SSDs OR four Hitachi
Ultrastar 15K600 SAS drives?
My app is pretty write heavy and I have a lot of concurrent connections 300 -
(though considering adding pgpool2 in front to increase throughput).
Regards Niels Kristian
--
Sent via pgsq
Thanks both of you for your input.
Earlier I have been discussing my extremely high IO wait with you here on the
mailing list, and have tried a lot of tweaks both on postgresql config, wal
directly location and kernel tweaks, but unfortunately my problem persists, and
I think I'm eventually dow
21 matches
Mail list logo
