Re: xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

On 12/05/2012 11:51 AM, Jean-David Beyer wrote: I thought that postgreSQL did its own journalling, if that is the proper term, so why not use an ext2 file system to lower overhead? Postgres journalling will not save you from a corrupt file system. cheers andrew -- Sent via pgsql-perfo

Re: xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

On Wed, Dec 5, 2012 at 1:51 PM, Jean-David Beyer wrote: > I thought that postgreSQL did its own journalling, if that is the proper > term, so why not use an ext2 file system to lower overhead? Because you can still have metadata-level corruption. -- Sent via pgsql-performance mailing list (pgs

Re: xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

On 12/05/2012 10:34 AM, Andrea Suisani wrote: > [sorry for resuming an old thread] > > [cut] > Question is... will that remove the performance penalty of HyperThreading? >>> >>> So I've added to my todo list to perform a test to verify this claim :) >> >> done. > > on this box: > >> in a

xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

[sorry for resuming an old thread] [cut] Question is... will that remove the performance penalty of HyperThreading? So I've added to my todo list to perform a test to verify this claim :) done. on this box: in a brief: the box is dell a PowerEdge r720 with 16GB of RAM, the cpu is a Xeon

Re: [PERFORM] Two identical systems, radically different performance

On Wed, Oct 17, 2012 at 11:57 PM, Andrea Suisani wrote: > On 10/17/2012 06:35 PM, Scott Marlowe wrote: >> >> On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani >> wrote: >>> >>> On 10/15/2012 05:34 PM, Scott Marlowe wrote: I'd recommend more synthetic benchmarks when trying to compare syst

Re: [PERFORM] Two identical systems, radically different performance

On 10/17/2012 06:35 PM, Scott Marlowe wrote: On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani wrote: On 10/15/2012 05:34 PM, Scott Marlowe wrote: I'd recommend more synthetic benchmarks when trying to compare systems like this. bonnie++, you were right. bonnie++ (-f -n 0 -c 4) show that the

Re: [PERFORM] Two identical systems, radically different performance

On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani wrote: > On 10/15/2012 05:34 PM, Scott Marlowe wrote: >> I'd recommend more synthetic benchmarks when trying to compare systems >> like this. bonnie++, > > > you were right. bonnie++ (-f -n 0 -c 4) show that there's very little (if > any) > differen

Re: [PERFORM] Two identical systems, radically different performance

On 10/15/2012 05:34 PM, Scott Marlowe wrote: On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote: sure you're right. It's just that my bet was on a higher throughput when HT was isabled from the BIOS (as you stated previously in this

Re: [PERFORM] Two identical systems, radically different performance

On 15.10.2012 17:01, Craig James wrote: On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote: > I've googled a bit and I've found a way to disable hyperthreading > without > the need to reboot the system and entering the bios: > > echo 0 >/sys/devices/system/node/no

Re: [PERFORM] Two identical systems, radically different performance

On 10/15/2012 05:34 PM, Scott Marlowe wrote: On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote: sure you're right. It's just that my bet was on a higher throughput when HT was isabled from the BIOS (as you stated previously in this

Re: [PERFORM] Two identical systems, radically different performance

On 10/15/2012 05:28 PM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote: It does prove they're not equivalent though. sure you're right. It's just that my bet was on a higher throughput when HT was isabled from the BIOS (as you stated previously in this thread).

Re: [PERFORM] Two identical systems, radically different performance

[cut] TPS including connection establishing, pgbench run in a single thread mode, connection made through unix socket, OS cache dropped and Postgres restarted for every run. those are the results: HTHT SYSFS DISHT BIOS DISABLE -c -t r1 r2 r3r1 r2 r3

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote: > On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote: >> sure you're right. >> >> It's just that my bet was on a higher throughput >> when HT was isabled from the BIOS (as you stated >> previously in this thread). > > Yes, mine too. It's

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 9:01 AM, Craig James wrote: > On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani wrote: >> (I suspect that there's something wrong with the PERC >> because, having the controller cache enabled make no >> difference in terms of TPS), it seems strange that disabling >> HT from

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote: >> It does prove they're not equivalent though. >> > > sure you're right. > > It's just that my bet was on a higher throughput > when HT was isabled from the BIOS (as you stated > previously in this thread). Yes, mine too. It's bizarre. If I

Re: [PERFORM] Two identical systems, radically different performance

On 10/15/2012 05:01 PM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani wrote: it seems strange that disabling HT from the bios will give lesser TPS that HT disable through sysfs interface. It does prove they're not equivalent though. sure you're right. It's just tha

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani wrote: > it seems strange that disabling > HT from the bios will give lesser TPS that HT disable through > sysfs interface. It does prove they're not equivalent though. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani wrote: > On 10/11/2012 04:40 PM, Andrea Suisani wrote: >> >> On 10/11/2012 04:19 PM, Claudio Freire wrote: >>> >>> On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani >>> wrote: sorry to come late to the party, but being in a similar conditio

Re: [PERFORM] Two identical systems, radically different performance

On 10/11/2012 04:40 PM, Andrea Suisani wrote: On 10/11/2012 04:19 PM, Claudio Freire wrote: On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote: sorry to come late to the party, but being in a similar condition I've googled a bit and I've found a way to disable hyperthreading without the ne

Re: [PERFORM] Two identical systems, radically different performance

On 10/11/2012 04:19 PM, Claudio Freire wrote: On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote: sorry to come late to the party, but being in a similar condition I've googled a bit and I've found a way to disable hyperthreading without the need to reboot the system and entering the bios:

Re: [PERFORM] Two identical systems, radically different performance

On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote: > sorry to come late to the party, but being in a similar condition > I've googled a bit and I've found a way to disable hyperthreading without > the need to reboot the system and entering the bios: > > echo 0 >/sys/devices/system/node/node0/

Re: [PERFORM] Two identical systems, radically different performance

On 10/09/2012 01:40 AM, Craig James wrote: Nobody has commented on the hyperthreading question yet ... does it really matter? The old (fast) server has hyperthreading disabled, and the new (slower) server has hyperthreads enabled. If hyperthreading is definitely NOT an issue, it will save me a

Re: [PERFORM] Two identical systems, radically different performance

On Tue, Oct 9, 2012 at 2:40 AM, Craig James wrote: > Nobody has commented on the hyperthreading question yet ... does it really > matter? The old (fast) server has hyperthreading disabled, and the new > (slower) server has hyperthreads enabled. > > If hyperthreading is definitely NOT an issue, it

Re: [PERFORM] Two identical systems, radically different performance

On 09/10/12 12:40, Craig James wrote: Nobody has commented on the hyperthreading question yet ... does it really matter? The old (fast) server has hyperthreading disabled, and the new (slower) server has hyperthreads enabled. If hyperthreading is definitely NOT an issue, it will save me a trip

Re: [PERFORM] Two identical systems, radically different performance

On Tue, Oct 9, 2012 at 9:02 AM, Shaun Thomas wrote: > On 10/08/2012 06:40 PM, Craig James wrote: > > Nobody has commented on the hyperthreading question yet ... does it >> really matter? The old (fast) server has hyperthreading disabled, and >> the new (slower) server has hyperthreads enabled. >>

Re: [PERFORM] Two identical systems, radically different performance

On Tue, Oct 9, 2012 at 9:14 AM, David Thomas wrote: > On Mon, Oct 08, 2012 at 04:40:31PM -0700, Craig James wrote: > >Nobody has commented on the hyperthreading question yet ... does it > >really matter? The old (fast) server has hyperthreading disabled, and > >the new (slower) server

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 08, 2012 at 04:40:31PM -0700, Craig James wrote: >Nobody has commented on the hyperthreading question yet ... does it >really matter? The old (fast) server has hyperthreading disabled, and >the new (slower) server has hyperthreads enabled. >If hyperthreading is definitel

Re: [PERFORM] Two identical systems, radically different performance

On 10/08/2012 06:40 PM, Craig James wrote: Nobody has commented on the hyperthreading question yet ... does it really matter? The old (fast) server has hyperthreading disabled, and the new (slower) server has hyperthreads enabled. I doubt it's this. With the newer post-Nehalem processors, hyp

Re: [PERFORM] Two identical systems, radically different performance

On 2012-10-08 23:45, Craig James wrote: This is driving me crazy. A new server, virtually identical to an old one, has 50% of the performance with pgbench. I've checked everything I can think of. The setups (call the servers "old" and "new"): old: 2 x 4-core Intel Xeon E5620 new: 4 x 4-core

Re: [PERFORM] Two identical systems, radically different performance

Nobody has commented on the hyperthreading question yet ... does it really matter? The old (fast) server has hyperthreading disabled, and the new (slower) server has hyperthreads enabled. If hyperthreading is definitely NOT an issue, it will save me a trip to the co-lo facility. Thanks, Craig On

Re: [PERFORM] Two identical systems, radically different performance

On Oct 9, 2012, at 3:24 AM, Tomas Vondra wrote: > On 9.10.2012 00:33, Evgeny Shishkin wrote: >>> >>> pgbench: Old server >>> >>>pgbench -i -s 100 -U test >>>pgbench -U test -c ... -t ... >>> >>>-c -t TPS >>> 5 2 3777 >>>10 1 2622 >>>20 5000 3759 >>

Re: [PERFORM] Two identical systems, radically different performance

On 9.10.2012 00:33, Evgeny Shishkin wrote: >> >> pgbench: Old server >> >> pgbench -i -s 100 -U test >> pgbench -U test -c ... -t ... >> >> -c -t TPS >> 5 2 3777 >> 10 1 2622 >> 20 5000 3759 >> 30 5712 >> 40 2500 5953 >> 50 2000

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 8:03 PM, Craig James wrote: >> > But again ... the two systems are identical. This can't explain it. >> >> Is the read-ahead the same in both systems? > > > Yes, as I said in the original reply (it got cut off from your reply): "Same > on both servers." Oh, yes. Google col

Re: [PERFORM] Two identical systems, radically different performance

On 9.10.2012 01:03, Craig James wrote: > > > On Mon, Oct 8, 2012 at 3:50 PM, Claudio Freire > wrote: > > On Mon, Oct 8, 2012 at 7:48 PM, Craig James > wrote: > >> > # blockdev --getra /dev/sdb1 > >> > 256 > >> >

Re: [PERFORM] Two identical systems, radically different performance

On 09/10/12 11:48, Craig James wrote: On Mon, Oct 8, 2012 at 3:44 PM, Claudio Freire wrote: On Mon, Oct 8, 2012 at 7:25 PM, Craig James wrote: But why? What have I overlooked? Do you have readahead properly set up on the new one? # blockdev --getra /dev/sdb1 256 It's probably this. 256

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 3:50 PM, Claudio Freire wrote: > On Mon, Oct 8, 2012 at 7:48 PM, Craig James wrote: > >> > # blockdev --getra /dev/sdb1 > >> > 256 > >> > >> > >> It's probably this. 256 is way too low to saturate your I/O system. > >> Pump it up. I've found 8192 works nice for a system I

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 7:48 PM, Craig James wrote: >> > # blockdev --getra /dev/sdb1 >> > 256 >> >> >> It's probably this. 256 is way too low to saturate your I/O system. >> Pump it up. I've found 8192 works nice for a system I have, 32000 I >> guess could work too. > > > But again ... the two sy

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 3:44 PM, Claudio Freire wrote: > On Mon, Oct 8, 2012 at 7:25 PM, Craig James wrote: > >> > But why? What have I overlooked? > >> > >> Do you have readahead properly set up on the new one? > > > > > > # blockdev --getra /dev/sdb1 > > 256 > > > It's probably this. 256 is way

Re: [PERFORM] Two identical systems, radically different performance

On Oct 9, 2012, at 2:44 AM, Claudio Freire wrote: > On Mon, Oct 8, 2012 at 7:25 PM, Craig James wrote: But why? What have I overlooked? >>> >>> Do you have readahead properly set up on the new one? >> >> >> # blockdev --getra /dev/sdb1 >> 256 > > > It's probably this. 256 is way too l

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 7:25 PM, Craig James wrote: >> > But why? What have I overlooked? >> >> Do you have readahead properly set up on the new one? > > > # blockdev --getra /dev/sdb1 > 256 It's probably this. 256 is way too low to saturate your I/O system. Pump it up. I've found 8192 works nic

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 7:06 PM, Craig James wrote: >> Sequential Input on the new one is 279MB/s, on the old 400MB/s. >> > > But why? What have I overlooked? Do you have readahead properly set up on the new one? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To m

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 3:33 PM, Evgeny Shishkin wrote: > > On Oct 9, 2012, at 1:45 AM, Craig James wrote: > > One dramatic difference I noted via vmstat. On the old server, the I/O > load during the bonnie++ run was steady, like this: > > procs ---memory-- ---swap-- -io -

Re: [PERFORM] Two identical systems, radically different performance

On Oct 9, 2012, at 1:45 AM, Craig James wrote: > This is driving me crazy. A new server, virtually identical to an old one, > has 50% of the performance with pgbench. I've checked everything I can think > of. > > The setups (call the servers "old" and "new"): > > old: 2 x 4-core Intel Xeon

Re: [PERFORM] Two identical systems, radically different performance

One mistake in my descriptions... On Mon, Oct 8, 2012 at 2:45 PM, Craig James wrote: > This is driving me crazy. A new server, virtually identical to an old > one, has 50% of the performance with pgbench. I've checked everything I > can think of. > > The setups (call the servers "old" and "new

Re: [PERFORM] Two identical systems, radically different performance

>old: 2 x 4-core Intel Xeon E5620 >new: 4 x 4-core Intel Xeon E5606 http://ark.intel.com/compare/47925,52583 old: Xeon E5620 : 4 cores ; 8 Threads ; *Clock Speed : 2.40 GHz ; Max Turbo Frequency: 2.66 GHz* new: Xeon E5606 :4 cores ; 4 Threads ; Clock Speed : 2.13 GHz ; Max Tur

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 3:09 PM, Claudio Freire wrote: > On Mon, Oct 8, 2012 at 7:06 PM, Craig James wrote: > >> Sequential Input on the new one is 279MB/s, on the old 400MB/s. > >> > > > > But why? What have I overlooked? > > Do you have readahead properly set up on the new one? > # blockdev --

Re: [PERFORM] Two identical systems, radically different performance

On 10/08/2012 02:45 PM, Craig James wrote: This is driving me crazy. A new server, virtually identical to an old one, has 50% of the performance with pgbench. I've checked everything I can think of. The setups (call the servers "old" and "new"): old: 2 x 4-core Intel Xeon E5620 new: 4 x 4-c

Re: [PERFORM] Two identical systems, radically different performance

On Oct 9, 2012, at 2:06 AM, Craig James wrote: > > > On Mon, Oct 8, 2012 at 2:57 PM, Evgeny Shishkin wrote: > > On Oct 9, 2012, at 1:45 AM, Craig James wrote: > >> I tested both the RAID10 data disk and the RAID1 xlog disk with bonnie++. >> The xlog disks were almost identical in perform

Re: [PERFORM] Two identical systems, radically different performance

On Mon, Oct 8, 2012 at 2:57 PM, Evgeny Shishkin wrote: > > On Oct 9, 2012, at 1:45 AM, Craig James wrote: > > I tested both the RAID10 data disk and the RAID1 xlog disk with bonnie++. > The xlog disks were almost identical in performance. The RAID10 pg-data > disks looked like this: > > Old serv

Re: [PERFORM] Two identical systems, radically different performance

On Oct 9, 2012, at 1:45 AM, Craig James wrote: > This is driving me crazy. A new server, virtually identical to an old one, > has 50% of the performance with pgbench. I've checked everything I can think > of. > > The setups (call the servers "old" and "new"): > > old: 2 x 4-core Intel Xeon

[PERFORM] Two identical systems, radically different performance

This is driving me crazy. A new server, virtually identical to an old one, has 50% of the performance with pgbench. I've checked everything I can think of. The setups (call the servers "old" and "new"): old: 2 x 4-core Intel Xeon E5620 new: 4 x 4-core Intel Xeon E5606 both: memory: 12 GB DD