pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedBenchmark: Dell/Perc 6, 8 disk RAID 10
45+ messages / 17 participants
[nested] [flat]
* Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 04:55 Craig James <craig_james@emolecules.com>
1 sibling, 2 replies; 45+ messages in thread
From: Craig James @ 2008-03-13 04:55 UTC (permalink / raw)
To: pgsql-performance
I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be "insert into ... (select ...)" where the resulting insert is on the order of 100 to 10K rows of two integers. An external process also uses a LOT of CPU power along with each query.
Thanks,
Craig
Configuration:
Dell 2950
8 CPU (Intel 2GHz Xeon)
8 GB memory
Dell Perc 6i with battery-backed cache
RAID 10 of 8x 146GB SAS 10K 2.5" disks
Everything (OS, WAL and databases) are on the one RAID array.
Diffs from original configuration:
max_connections = 1000
shared_buffers = 400MB
work_mem = 256MB
max_fsm_pages = 1000000
max_fsm_relations = 5000
wal_buffers = 256kB
effective_cache_size = 4GB
Bonnie output (slightly reformatted)
------------------------------------------------------------------------------
Delete files in random order...done.
Version 1.03
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
16G 64205 99 234252 38 112924 26 65275 98 293852 24 940.3 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++ 15578 82
www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
------------------------------------------------------------------------------
$ pgbench -c 10 -t 10000 -v test -U test
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 2786.377933 (including connections establishing)
tps = 2787.888209 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 05:31 Scott Marlowe <scott.marlowe@gmail.com>
parent: Craig James <craig_james@emolecules.com>
1 sibling, 0 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-13 05:31 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
On Wed, Mar 12, 2008 at 9:55 PM, Craig James <craig_james@emolecules.com> wrote:
> I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be "insert into ... (select ...)" where the resulting insert is on the order of 100 to 10K rows of two integers. An external process also uses a LOT of CPU power along with each query.
Have you been inserting each insert individually, or as part of a
larger transaction. Wrapping a few thousand up in a begin;end; pair
can really help. You can reasonably wrap 100k or more inserts into a
single transaction. if any one insert fails the whole insert sequence
fails.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 05:55 Joshua D. Drake <jd@commandprompt.com>
parent: Craig James <craig_james@emolecules.com>
1 sibling, 1 reply; 45+ messages in thread
From: Joshua D. Drake @ 2008-03-13 05:55 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 12 Mar 2008 21:55:18 -0700
Craig James <craig_james@emolecules.com> wrote:
> Diffs from original configuration:
>
> max_connections = 1000
> shared_buffers = 400MB
> work_mem = 256MB
> max_fsm_pages = 1000000
> max_fsm_relations = 5000
> wal_buffers = 256kB
> effective_cache_size = 4GB
I didn't see which OS but I assume linux. I didn't see postgresql so I
assume 8.3.
wal_sync_method = open_sync
checkpoint_segments = 30
shared_buffers = 2000MB
asyncrhonous_commit = off (sp?)
Try again.
Thanks this is useful stuff!
Joshua D. Drake
>
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL political pundit | Mocker of Dolphins
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH2MHsATb/zqfZUUQRAqqtAJsEa8RkJbpqY2FAYSrNVHhvTK/GBgCfYzYD
9myRDV7AYXq+Iht7rIZVZcc=
=PLpQ
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 08:11 Justin Graf <justin@emproshunts.com>
1 sibling, 4 replies; 45+ messages in thread
From: Justin Graf @ 2008-03-13 08:11 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; pgsql-performance
I recent just got a new server also from dell 2 weeks ago
went with more memory slower CPU, and smaller harddrives
have not run pgbench
Dell PE 2950 III
2 Quad Core 1.866 Ghz
16 gigs of ram.
8 hard drives 73Gig 10k RPM SAS
2 drives in Mirrored for OS, Binaries, and WAL
6 in a raid 10
Dual Gig Ethernet
OS Ubuntu 7.10
-----------------------------------------------
Version 1.03
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
PriData 70000M 51030 90 107488 29 50666 10 38464 65 102931 9 268.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
PriData,70000M,51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
the difference in our results are interesting.
What are the setting on the RAID card . I have the cache turned on with Read Ahead
---- Message from mailto:craig_james@emolecules.com Craig James <craig_james@emolecules.com> at 03-12-2008 09:55:18 PM ------
I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be "insert into ... (select ...)" where the resulting insert is on the order of 100 to 10K rows of two integers. An external process also uses a LOT of CPU power along with each query.
Thanks,
Craig
Configuration:
Dell 2950
8 CPU (Intel 2GHz Xeon)
8 GB memory
Dell Perc 6i with battery-backed cache
RAID 10 of 8x 146GB SAS 10K 2.5" disks
Everything (OS, WAL and databases) are on the one RAID array.
Diffs from original configuration:
max_connections = 1000
shared_buffers = 400MB
work_mem = 256MB
max_fsm_pages = 1000000
max_fsm_relations = 5000
wal_buffers = 256kB
effective_cache_size = 4GB
Bonnie output (slightly reformatted)
------------------------------------------------------------------------------
Delete files in random order...done.
Version 1.03
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
16G 64205 99 234252 38 112924 26 65275 98 293852 24 940.3 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++ 15578 82
www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
------------------------------------------------------------------------------
$ pgbench -c 10 -t 10000 -v test -U test
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 2786.377933 (including connections establishing)
tps = 2787.888209 (excluding connections establishing)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 12:11 Doug Knight <dknight@wsi.com>
parent: Justin Graf <justin@emproshunts.com>
3 siblings, 1 reply; 45+ messages in thread
From: Doug Knight @ 2008-03-13 12:11 UTC (permalink / raw)
To: Justin Graf <justin@emproshunts.com>; +Cc: Craig James <craig_james@emolecules.com>; pgsql-performance
All,
I am in the process of specing out a purchase for our production
systems, and am looking at the Dell 2950s as well. I am very interested
to see where this thread goes, and what combinations work with different
application loading types. Our systems will have one pair of
heartbeat-controlled, drbd mirrored servers running postgresql 8.3, with
a more write intensive, multiple writers and few readers application.
The other similarly configured pair will have lots of readers and few
writers. Our initial plan is RAID 10 for the database (four 300GB 15K
drives in an attached MD1000 box) and RAID 1 for the OS (pair of 73GB
drives internal to the 2950). PERC 6i for the internal drives (256MB
battery backed cache), PERC 6E for the external drives (512MB battery
backed cache). 8GB RAM, also dual Gig NICs for internet and
heartbeat/drbd. Not sure which processor we're going with, or if 8GB
memory will be enough. Keep the benchmarks coming.
Doug
On Thu, 2008-03-13 at 04:11 -0400, Justin Graf wrote:
> I recent just got a new server also from dell 2 weeks ago
> went with more memory slower CPU, and smaller harddrives
> have not run pgbench
>
> Dell PE 2950 III
> 2 Quad Core 1.866 Ghz
> 16 gigs of ram.
> 8 hard drives 73Gig 10k RPM SAS
> 2 drives in Mirrored for OS, Binaries, and WAL
> 6 in a raid 10
> Dual Gig Ethernet
> OS Ubuntu 7.10
> -----------------------------------------------
>
> Version 1.03
> ------Sequential Output------ --Sequential Input-
> --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr-
> --Block-- --Seeks--
> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> K/sec %CP /sec %CP
> PriData 70000M 51030 90 107488 29 50666 10 38464 65
> 102931 9 268.2 0
>
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
> PriData,70000M,51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
> +++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
>
> the difference in our results are interesting.
>
> What are the setting on the RAID card . I have the cache turned on
> with Read Ahead
>
>
> ---- Message from Craig James <craig_james@emolecules.com> at
> 03-12-2008 09:55:18 PM ------
>
> I just received a new server and thought benchmarks would be
> interesting. I think this looks pretty good, but maybe there
> are some suggestions about the configuration file. This is a
> web app, a mix of read/write, where writes tend to be "insert
> into ... (select ...)" where the resulting insert is on the
> order of 100 to 10K rows of two integers. An external process
> also uses a LOT of CPU power along with each query.
>
> Thanks,
> Craig
>
>
> Configuration:
> Dell 2950
> 8 CPU (Intel 2GHz Xeon)
> 8 GB memory
> Dell Perc 6i with battery-backed cache
> RAID 10 of 8x 146GB SAS 10K 2.5" disks
>
> Everything (OS, WAL and databases) are on the one RAID array.
>
> Diffs from original configuration:
>
> max_connections = 1000
> shared_buffers = 400MB
> work_mem = 256MB
> max_fsm_pages = 1000000
> max_fsm_relations = 5000
> wal_buffers = 256kB
> effective_cache_size = 4GB
>
> Bonnie output (slightly reformatted)
>
> ------------------------------------------------------------------------------
>
> Delete files in random order...done.
> Version 1.03
> ------Sequential Output------ --Sequential
> Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr-
> --Block-- --Seeks--
> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> K/sec %CP /sec %CP
> 16G 64205 99 234252 38 112924 26 65275 98
> 293852 24 940.3 1
>
> ------Sequential Create------ --------Random
> Create--------
> -Create-- --Read--- -Delete-- -Create--
> --Read--- -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %
> CP /sec %CP
> 16 12203 95 +++++ +++ 19469 94 12297 95 +++++
> +++ 15578 82
>
> www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
>
> ------------------------------------------------------------------------------
>
> $ pgbench -c 10 -t 10000 -v test -U test
> starting vacuum...end.
> starting vacuum accounts...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
> number of transactions per client: 10000
> number of transactions actually processed: 100000/100000
> tps = 2786.377933 (including connections establishing)
> tps = 2787.888209 (excluding connections establishing)
>
>
>
> --
> Sent via pgsql-performance mailing list
> (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
>
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 13:11 Will Weaver <will@myemma.com>
parent: Justin Graf <justin@emproshunts.com>
3 siblings, 0 replies; 45+ messages in thread
From: Will Weaver @ 2008-03-13 13:11 UTC (permalink / raw)
To: Justin Graf <justin@emproshunts.com>; pgsql-performance
Justin,
This may be a bit out of context, but did you run into any troubles
getting your Perc6i RAID controller to work under Ubuntu 7.1? I've
heard there were issues with that.
Thanks,
Will
On Mar 13, 2008, at 3:11 AM, Justin Graf wrote:
> I recent just got a new server also from dell 2 weeks ago
> went with more memory slower CPU, and smaller harddrives
> have not run pgbench
>
> Dell PE 2950 III
> 2 Quad Core 1.866 Ghz
> 16 gigs of ram.
> 8 hard drives 73Gig 10k RPM SAS
> 2 drives in Mirrored for OS, Binaries, and WAL
> 6 in a raid 10
> Dual Gig Ethernet
> OS Ubuntu 7.10
> -----------------------------------------------
>
> Version 1.03
> ------Sequential Output------ --Sequential
> Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --
> Block-- --Seeks--
> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> K/sec %CP /sec %CP
> PriData 70000M 51030 90 107488 29 50666 10 38464
> 65 102931 9 268.2 0
>
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
> PriData,70000M,
> 51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
> +++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
>
> the difference in our results are interesting.
>
> What are the setting on the RAID card . I have the cache turned on
> with Read Ahead
>
>
> ---- Message from Craig James <craig_james@emolecules.com> at
> 03-12-2008 09:55:18 PM ------
> I just received a new server and thought benchmarks would be
> interesting. I think this looks pretty good, but maybe there are
> some suggestions about the configuration file. This is a web app, a
> mix of read/write, where writes tend to be "insert into ...
> (select ...)" where the resulting insert is on the order of 100 to
> 10K rows of two integers. An external process also uses a LOT of
> CPU power along with each query.
>
> Thanks,
> Craig
>
>
> Configuration:
> Dell 2950
> 8 CPU (Intel 2GHz Xeon)
> 8 GB memory
> Dell Perc 6i with battery-backed cache
> RAID 10 of 8x 146GB SAS 10K 2.5" disks
>
> Everything (OS, WAL and databases) are on the one RAID array.
>
> Diffs from original configuration:
>
> max_connections = 1000
> shared_buffers = 400MB
> work_mem = 256MB
> max_fsm_pages = 1000000
> max_fsm_relations = 5000
> wal_buffers = 256kB
> effective_cache_size = 4GB
>
> Bonnie output (slightly reformatted)
>
> ------------------------------------------------------------------------------
>
> Delete files in random order...done.
> Version 1.03
> ------Sequential Output------ --Sequential
> Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --
> Block-- --Seeks--
> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec
> %CP /sec %CP
> 16G 64205 99 234252 38 112924 26 65275 98 293852
> 24 940.3 1
>
> ------Sequential Create------ --------Random
> Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -
> Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /
> sec %CP
> 16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++
> 15578 82
>
> www.xxx.com,16G,
> 64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+
> ++++,+++,19469,94,12297,95,+++++,+++,15578,82
>
> ------------------------------------------------------------------------------
>
> $ pgbench -c 10 -t 10000 -v test -U test
> starting vacuum...end.
> starting vacuum accounts...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
> number of transactions per client: 10000
> number of transactions actually processed: 100000/100000
> tps = 2786.377933 (including connections establishing)
> tps = 2787.888209 (excluding connections establishing)
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
>
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 13:55 Justin Graf <justin@emproshunts.com>
parent: Justin Graf <justin@emproshunts.com>
3 siblings, 0 replies; 45+ messages in thread
From: Justin Graf @ 2008-03-13 13:55 UTC (permalink / raw)
To: Will Weaver <will@myemma.com>; pgsql-performance
I did not run into one install problem, I read a thread about people having problems but the thread is over a year old now.
I used the 7.1 gutsy amd64 server version
I then installed gnome desktop because its not installed by default. "i'm a windows admin i have to have my gui"
then installed postgres 8.3 gutsy.
it took about 3 hours to get the server setup.
---- Message from mailto:will@myemma.com Will Weaver <will@myemma.com> at 03-13-2008 08:11:06 AM ------
Justin,
This may be a bit out of context, but did you run into any troubles getting your Perc6i RAID controller to work under Ubuntu 7.1? I've heard there were issues with that.
Thanks,
Will
On Mar 13, 2008, at 3:11 AM, Justin Graf wrote:
I recent just got a new server also from dell 2 weeks ago
went with more memory slower CPU, and smaller harddrives
have not run pgbench
Dell PE 2950 III
2 Quad Core 1.866 Ghz
16 gigs of ram.
8 hard drives 73Gig 10k RPM SAS
2 drives in Mirrored for OS, Binaries, and WAL
6 in a raid 10
Dual Gig Ethernet
OS Ubuntu 7.10
-----------------------------------------------
Version 1.03
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
PriData 70000M 51030 90 107488 29 50666 10 38464 65 102931 9 268.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
PriData,70000M,51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
the difference in our results are interesting.
What are the setting on the RAID card . I have the cache turned on with Read Ahead
---- Message from mailto:craig_james@emolecules.com Craig James <craig_james@emolecules.com> at 03-12-2008 09:55:18 PM ------
I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be "insert into ... (select ...)" where the resulting insert is on the order of 100 to 10K rows of two integers. An external process also uses a LOT of CPU power along with each query.
Thanks,
Craig
Configuration:
Dell 2950
8 CPU (Intel 2GHz Xeon)
8 GB memory
Dell Perc 6i with battery-backed cache
RAID 10 of 8x 146GB SAS 10K 2.5" disks
Everything (OS, WAL and databases) are on the one RAID array.
Diffs from original configuration:
max_connections = 1000
shared_buffers = 400MB
work_mem = 256MB
max_fsm_pages = 1000000
max_fsm_relations = 5000
wal_buffers = 256kB
effective_cache_size = 4GB
Bonnie output (slightly reformatted)
------------------------------------------------------------------------------
Delete files in random order...done.
Version 1.03
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
16G 64205 99 234252 38 112924 26 65275 98 293852 24 940.3 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++ 15578 82
http://www.xxx.com www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
------------------------------------------------------------------------------
$ pgbench -c 10 -t 10000 -v test -U test
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 2786.377933 (including connections establishing)
tps = 2787.888209 (excluding connections establishing)
--
Sent via pgsql-performance mailing list (mailto:pgsql-performance@postgresql.org )
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 14:29 Craig James <craig_james@emolecules.com>
parent: Justin Graf <justin@emproshunts.com>
3 siblings, 1 reply; 45+ messages in thread
From: Craig James @ 2008-03-13 14:29 UTC (permalink / raw)
To: Justin Graf <justin@emproshunts.com>; +Cc: pgsql-performance
Justin Graf wrote:
> I recent just got a new server also from dell 2 weeks ago
> went with more memory slower CPU, and smaller harddrives
> have not run pgbench
>
> Dell PE 2950 III
> 2 Quad Core 1.866 Ghz
> 16 gigs of ram.
> 8 hard drives 73Gig 10k RPM SAS
> 2 drives in Mirrored for OS, Binaries, and WAL
> 6 in a raid 10
> Dual Gig Ethernet
> OS Ubuntu 7.10
> -----------------------------------------------
>
> Version 1.03
> ------Sequential Output------ --Sequential Input-
> --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> K/sec %CP /sec %CP
> PriData 70000M 51030 90 107488 29 50666 10 38464 65
> 102931 9 268.2 0
>
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
> PriData,70000M,51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
> +++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
>
> the difference in our results are interesting.
>
> What are the setting on the RAID card . I have the cache turned on with
> Read Ahead
First, did you get the Perc 6i with battery-backed cache? Not all versions have it. I found this really confusing when trying to order -- we had to work pretty hard to figure out exactly what to order to be sure we got this feature. (Does anyone at Dell follow these discussions?)
Second, Dell ships a Linux driver with this hardware, and we installed it. I have no idea what the driver does, because I think you can run the system without it, but my guess is that without the Dell driver, it's using the Perc6 card in some "normal" mode that doesn't take advantage of its capabilities.
With a 6-disk RAID 10, you should get numbers at least in the same ballpark as my numbers.
Craig
>
>
> ---- Message from Craig James <craig_james@emolecules.com>
> <mailto:craig_james@emolecules.com> at 03-12-2008 09:55:18 PM ------
>
> I just received a new server and thought benchmarks would be
> interesting. I think this looks pretty good, but maybe there are
> some suggestions about the configuration file. This is a web app, a
> mix of read/write, where writes tend to be "insert into ... (select
> ...)" where the resulting insert is on the order of 100 to 10K rows
> of two integers. An external process also uses a LOT of CPU power
> along with each query.
>
> Thanks,
> Craig
>
>
> Configuration:
> Dell 2950
> 8 CPU (Intel 2GHz Xeon)
> 8 GB memory
> Dell Perc 6i with battery-backed cache
> RAID 10 of 8x 146GB SAS 10K 2.5" disks
>
> Everything (OS, WAL and databases) are on the one RAID array.
>
> Diffs from original configuration:
>
> max_connections = 1000
> shared_buffers = 400MB
> work_mem = 256MB
> max_fsm_pages = 1000000
> max_fsm_relations = 5000
> wal_buffers = 256kB
> effective_cache_size = 4GB
>
> Bonnie output (slightly reformatted)
>
> ------------------------------------------------------------------------------
>
> Delete files in random order...done.
> Version 1.03
> ------Sequential Output------ --Sequential Input-
> --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> /sec %CP
> 16G 64205 99 234252 38 112924 26 65275 98 293852 24
> 940.3 1
>
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read---
> -Delete--
> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> /sec %CP
> 16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++
> 15578 82
>
> www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
>
> ------------------------------------------------------------------------------
>
> $ pgbench -c 10 -t 10000 -v test -U test
> starting vacuum...end.
> starting vacuum accounts...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
> number of transactions per client: 10000
> number of transactions actually processed: 100000/100000
> tps = 2786.377933 (including connections establishing)
> tps = 2787.888209 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 14:36 Craig James <craig_james@emolecules.com>
parent: Doug Knight <dknight@wsi.com>
0 siblings, 0 replies; 45+ messages in thread
From: Craig James @ 2008-03-13 14:36 UTC (permalink / raw)
To: Doug Knight <dknight@wsi.com>; +Cc: Justin Graf <justin@emproshunts.com>; pgsql-performance
Doug Knight wrote:
> All,
> I am in the process of specing out a purchase for our production
> systems, and am looking at the Dell 2950s as well. I am very interested
> to see where this thread goes, and what combinations work with different
> application loading types. Our systems will have one pair of
> heartbeat-controlled, drbd mirrored servers running postgresql 8.3, with
> a more write intensive, multiple writers and few readers application.
> The other similarly configured pair will have lots of readers and few
> writers. Our initial plan is RAID 10 for the database (four 300GB 15K
> drives in an attached MD1000 box) and RAID 1 for the OS (pair of 73GB
> drives internal to the 2950). PERC 6i for the internal drives (256MB
> battery backed cache), PERC 6E for the external drives (512MB battery
> backed cache). 8GB RAM, also dual Gig NICs for internet and
> heartbeat/drbd. Not sure which processor we're going with, or if 8GB
> memory will be enough. Keep the benchmarks coming.
We considered this configuration too. But in the end, we decided that by going with the 146 GB 2.5" drives, we could get 8 disks in the main box, and save the cost of the MD1000, which almost doubles the price of the system. We end up with a 546 GB RAID assembly, more than enough for our needs.
I think that 8 10K disks in a RAID 10 will be faster than 4 15K disks, and you only gain a little space (two 300GB versus four 146GB). So it seemed like we'd be paying more and getting less. With the battery-backed Perc 6i RAID, the advice seemed to be that the OS, WAL and Database could all share the disk without conflict, and I think the numbers will back that up. We're not in production yet, so only time will tell.
Craig
>
> Doug
>
> On Thu, 2008-03-13 at 04:11 -0400, Justin Graf wrote:
>> I recent just got a new server also from dell 2 weeks ago
>> went with more memory slower CPU, and smaller harddrives
>> have not run pgbench
>>
>> Dell PE 2950 III
>> 2 Quad Core 1.866 Ghz
>> 16 gigs of ram.
>> 8 hard drives 73Gig 10k RPM SAS
>> 2 drives in Mirrored for OS, Binaries, and WAL
>> 6 in a raid 10
>> Dual Gig Ethernet
>> OS Ubuntu 7.10
>> -----------------------------------------------
>>
>> Version 1.03
>> ------Sequential Output------ --Sequential Input-
>> --Random-
>> -Per Chr- --Block-- -Rewrite- -Per Chr-
>> --Block-- --Seeks--
>> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
>> K/sec %CP /sec %CP
>> PriData 70000M 51030 90 107488 29 50666 10 38464
>> 65 102931 9 268.2 0
>>
>> ------Sequential Create------ --------Random Create--------
>> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
>> 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
>> PriData,70000M,51030,90,107488,29,50666,10,38464,65,102931,9,268.2,0,16,
>> +++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
>>
>> the difference in our results are interesting.
>>
>> What are the setting on the RAID card . I have the cache turned on
>> with Read Ahead
>>
>>
>> ---- Message from Craig James <craig_james@emolecules.com>
>> <mailto:craig_james@emolecules.com> at 03-12-2008 09:55:18 PM ------
>>
>> I just received a new server and thought benchmarks would be
>> interesting. I think this looks pretty good, but maybe there are
>> some suggestions about the configuration file. This is a web app,
>> a mix of read/write, where writes tend to be "insert into ...
>> (select ...)" where the resulting insert is on the order of 100 to
>> 10K rows of two integers. An external process also uses a LOT of
>> CPU power along with each query.
>>
>> Thanks,
>> Craig
>>
>>
>> Configuration:
>> Dell 2950
>> 8 CPU (Intel 2GHz Xeon)
>> 8 GB memory
>> Dell Perc 6i with battery-backed cache
>> RAID 10 of 8x 146GB SAS 10K 2.5" disks
>>
>> Everything (OS, WAL and databases) are on the one RAID array.
>>
>> Diffs from original configuration:
>>
>> max_connections = 1000
>> shared_buffers = 400MB
>> work_mem = 256MB
>> max_fsm_pages = 1000000
>> max_fsm_relations = 5000
>> wal_buffers = 256kB
>> effective_cache_size = 4GB
>>
>> Bonnie output (slightly reformatted)
>>
>> ------------------------------------------------------------------------------
>>
>> Delete files in random order...done.
>> Version 1.03
>> ------Sequential Output------ --Sequential Input-
>> --Random-
>> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
>> --Seeks--
>> Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec
>> %CP /sec %CP
>> 16G 64205 99 234252 38 112924 26 65275 98 293852
>> 24 940.3 1
>>
>> ------Sequential Create------ --------Random
>> Create--------
>> -Create-- --Read--- -Delete-- -Create-- --Read---
>> -Delete--
>> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
>> /sec %CP
>> 16 12203 95 +++++ +++ 19469 94 12297 95 +++++ +++
>> 15578 82
>>
>> www.xxx.com,16G,64205,99,234252,38,112924,26,65275,98,293852,24,940.3,1,16,12203,95,+++++,+++,19469,94,12297,95,+++++,+++,15578,82
>>
>> ------------------------------------------------------------------------------
>>
>> $ pgbench -c 10 -t 10000 -v test -U test
>> starting vacuum...end.
>> starting vacuum accounts...end.
>> transaction type: TPC-B (sort of)
>> scaling factor: 1
>> number of clients: 10
>> number of transactions per client: 10000
>> number of transactions actually processed: 100000/100000
>> tps = 2786.377933 (including connections establishing)
>> tps = 2787.888209 (excluding connections establishing)
>>
>>
>>
>> --
>> Sent via pgsql-performance mailing list
>> (pgsql-performance@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>>
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 14:54 Craig James <craig_james@emolecules.com>
parent: Joshua D. Drake <jd@commandprompt.com>
0 siblings, 1 reply; 45+ messages in thread
From: Craig James @ 2008-03-13 14:54 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; pgsql-performance
Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 12 Mar 2008 21:55:18 -0700
> Craig James <craig_james@emolecules.com> wrote:
>
>
>> Diffs from original configuration:
>>
>> max_connections = 1000
>> shared_buffers = 400MB
>> work_mem = 256MB
>> max_fsm_pages = 1000000
>> max_fsm_relations = 5000
>> wal_buffers = 256kB
>> effective_cache_size = 4GB
>
> I didn't see which OS but I assume linux. I didn't see postgresql so I
> assume 8.3.
Right on both counts.
> wal_sync_method = open_sync
> checkpoint_segments = 30
> shared_buffers = 2000MB
> asyncrhonous_commit = off (sp?)
>
> Try again.
Nice improvement! About 25% increase in TPS:
$ pgbench -c 10 -t 10000 -v test -U test
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 3423.636423 (including connections establishing)
tps = 3425.957521 (excluding connections establishing)
For reference, here are the results before your suggested changes:
$ pgbench -c 10 -t 10000 -v test -U test
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 2786.377933 (including connections establishing)
tps = 2787.888209 (excluding connections establishing)
Thanks!
Craig
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 16:01 Greg Smith <gsmith@gregsmith.com>
parent: Craig James <craig_james@emolecules.com>
0 siblings, 1 reply; 45+ messages in thread
From: Greg Smith @ 2008-03-13 16:01 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Joshua D. Drake <jd@commandprompt.com>; pgsql-performance
On Thu, 13 Mar 2008, Craig James wrote:
>> wal_sync_method = open_sync
There was a bug report I haven't had a chance to investigate yet that
suggested some recent Linux versions have issues when using open_sync.
I'd suggest popping that back to the default for now unless you have time
to really do a long certification process that your system runs reliably
with it turned on.
I suspect most of the improvement you saw from Joshua's recommendations
was from raising checkpoint_segments.
> $ pgbench -c 10 -t 10000 -v test -U test
> scaling factor: 1
> number of clients: 10
A scaling factor of 1 means you are operating on a positively trivial 16MB
database. It also means there's exactly one entry in a table that every
client updates on every transactions. You have 10 clients, and they're
all fighting over access to it.
If you actually want something that approaches useful numbers here, you
need to at run 'pgbench -i -s 10' to get a scaling factor of 10 and a
160MB database. Interesting results on this class of hardware are when
you set scaling to 100 or more (100=1.6GB database). See
http://www.westnet.com/~gsmith/content/postgresql/pgbench-scaling.htm for
some examples of how that works, from a less powerful system than yours.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 21:06 Joshua D. Drake <jd@commandprompt.com>
parent: Greg Smith <gsmith@gregsmith.com>
0 siblings, 2 replies; 45+ messages in thread
From: Joshua D. Drake @ 2008-03-13 21:06 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: Craig James <craig_james@emolecules.com>; pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 13 Mar 2008 12:01:50 -0400 (EDT)
Greg Smith <gsmith@gregsmith.com> wrote:
> On Thu, 13 Mar 2008, Craig James wrote:
>
> >> wal_sync_method = open_sync
>
> There was a bug report I haven't had a chance to investigate yet that
> suggested some recent Linux versions have issues when using
> open_sync. I'd suggest popping that back to the default for now
> unless you have time to really do a long certification process that
> your system runs reliably with it turned on.
Well the default would be ugly, that's fsync, fdatasync is probably a
better choice in that case.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL political pundit | Mocker of Dolphins
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH2ZdMATb/zqfZUUQRArZvAJ9Ja3Jnj2WD3eSYWoAv0ps5TVlPCQCglIEK
CAelb/M/BR+RJXhhEh7Iecw=
=pq2P
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 21:09 justin <justin@emproshunts.com>
parent: Craig James <craig_james@emolecules.com>
0 siblings, 1 reply; 45+ messages in thread
From: justin @ 2008-03-13 21:09 UTC (permalink / raw)
To: ; +Cc: pgsql-performance
Absolutely on the battery backup.
I did not load the linux drivers from dell, it works so i figured i was not
going to worry about it. This server is so oversized for its load its
unreal. I have always gone way overboard on server specs and making sure
its redundant.
The difference in our bonnie++ numbers is interesting, In some cases my
setup blows by yours and in other your's destroys mine.
On the raid setup. I'm a windows guy so i setup like its windows machine
keeping the OS/logs way separate from the DATA.
I chose to use ext3 on these partition
---- Message from Craig James <craig_james@emolecules.com> at 03-13-2008
07:29:23 AM ------
First, did you get the Perc 6i with battery-backed cache? Not all
versions have it. I found this really confusing when trying to order -- we
had to work pretty hard to figure out exactly what to order to be sure we
got this feature. (Does anyone at Dell follow these discussions?)
Second, Dell ships a Linux driver with this hardware, and we installed it.
I have no idea what the driver does, because I think you can run the system
without it, but my guess is that without the Dell driver, it's using the
Perc6 card in some "normal" mode that doesn't take advantage of its
capabilities.
With a 6-disk RAID 10, you should get numbers at least in the same
ballpark as my numbers.
Craig
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 21:27 Greg Smith <gsmith@gregsmith.com>
parent: Joshua D. Drake <jd@commandprompt.com>
1 sibling, 1 reply; 45+ messages in thread
From: Greg Smith @ 2008-03-13 21:27 UTC (permalink / raw)
To: pgsql-performance
On Thu, 13 Mar 2008, Joshua D. Drake wrote:
> Greg Smith <gsmith@gregsmith.com> wrote:
>>>> wal_sync_method = open_sync
>>
>> There was a bug report I haven't had a chance to investigate yet that
>> suggested some recent Linux versions have issues when using
>> open_sync. I'd suggest popping that back to the default for now
>> unless you have time to really do a long certification process that
>> your system runs reliably with it turned on.
>
> Well the default would be ugly, that's fsync, fdatasync is probably a
> better choice in that case.
I haven't found fdatasync to be significantly better in my tests on Linux
but I never went out of my way to try and quantify it. My understanding
is that some of the write barrier implementation details on ext3
filesystems make any sync call a relatively heavy operation but I haven't
poked at the code yet to figure out why.
There are really some substantial gains for WAL-heavy loads under Linux
just waiting for someone to dig into this more. For example, I have a
little plan sitting here to allow opening the WAL files with noatime even
if the rest of the filesystem can't be mounted that way, which would
collapse one of the big reasons to use a separate WAL disk.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-13 22:53 justin <justin@emproshunts.com>
parent: Joshua D. Drake <jd@commandprompt.com>
1 sibling, 1 reply; 45+ messages in thread
From: justin @ 2008-03-13 22:53 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; pgsql-performance
----- Original Message -----
From: "Greg Smith" <gsmith@gregsmith.com>
To: <pgsql-performance@postgresql.org>
Sent: Thursday, March 13, 2008 4:27 PM
Subject: Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10
> On Thu, 13 Mar 2008, Joshua D. Drake wrote:
>
>> Greg Smith <gsmith@gregsmith.com> wrote:
>>>>> wal_sync_method = open_sync
>>>
>>> There was a bug report I haven't had a chance to investigate yet that
>>> suggested some recent Linux versions have issues when using
>>> open_sync. I'd suggest popping that back to the default for now
>>> unless you have time to really do a long certification process that
>>> your system runs reliably with it turned on.
>>
>> Well the default would be ugly, that's fsync, fdatasync is probably a
>> better choice in that case.
>
> I haven't found fdatasync to be significantly better in my tests on Linux
> but I never went out of my way to try and quantify it. My understanding
> is that some of the write barrier implementation details on ext3
> filesystems make any sync call a relatively heavy operation but I haven't
> poked at the code yet to figure out why.
>
> There are really some substantial gains for WAL-heavy loads under Linux
> just waiting for someone to dig into this more. For example, I have a
> little plan sitting here to allow opening the WAL files with noatime even
> if the rest of the filesystem can't be mounted that way, which would
> collapse one of the big reasons to use a separate WAL disk.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
I'm ran pgbench from my laptop to the new server
My laptop is dual core with 2 gigs of ram and 1 gig enthernet connection to
server. so i don't think the network is going to be a problem in the test.
When i look at the server memory its only consuming 463 megs. I have the
effective cache set at 12 gigs and sharebuffer at 100megs and work mem set
to 50megs
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 20.618557 (including connections establishing)
tps = 20.618557 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 10
number of transactions actually processed: 100/100
tps = 18.231541 (including connections establishing)
tps = 18.231541 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 19.116073 (including connections establishing)
tps = 19.116073 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 1000
number of transactions actually processed: 40000/40000
tps = 20.368217 (including connections establishing)
tps = 20.368217 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:09 Scott Marlowe <scott.marlowe@gmail.com>
parent: justin <justin@emproshunts.com>
0 siblings, 0 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-14 06:09 UTC (permalink / raw)
To: justin <justin@emproshunts.com>; +Cc: Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On Thu, Mar 13, 2008 at 4:53 PM, justin <justin@emproshunts.com> wrote:
>
> I'm ran pgbench from my laptop to the new server
>
> My laptop is dual core with 2 gigs of ram and 1 gig enthernet connection to
> server. so i don't think the network is going to be a problem in the test.
>
> When i look at the server memory its only consuming 463 megs. I have the
> effective cache set at 12 gigs and sharebuffer at 100megs and work mem set
> to 50megs
You do know that effective_cache_size is the size of the OS level
cache. i.e. it won't show up in postgresql's memory usage. On a
machine with (I assume) 12 or more gigs or memory, you should have
your shared_buffers set to a much higher number than 100Meg. (unless
you're still running 7.4 but that's another story.)
pgbench will never use 50 megs of work_mem, as it's transactional and
hitting single rows at a time, not sorting huge lists of rows. Having
PostgreSQL use up all the memory is NOT necessarily your best bet.
Letting the OS cache your data is quite likely a good choice here, so
I'd keep your shared_buffers in the 500M to 2G range.
> transaction type: TPC-B (sort of)
> scaling factor: 100
> number of clients: 1
>
> number of transactions per client: 10
> number of transactions actually processed: 10/10
> tps = 20.618557 (including connections establishing)
> tps = 20.618557 (excluding connections establishing)
>
>
> transaction type: TPC-B (sort of)
> scaling factor: 100
>
> number of clients: 10
> number of transactions per client: 10
> number of transactions actually processed: 100/100
> tps = 18.231541 (including connections establishing)
> tps = 18.231541 (excluding connections establishing)
>
>
> transaction type: TPC-B (sort of)
> scaling factor: 100
>
> number of clients: 10
> number of transactions per client: 100
> number of transactions actually processed: 1000/1000
> tps = 19.116073 (including connections establishing)
> tps = 19.116073 (excluding connections establishing)
>
>
> transaction type: TPC-B (sort of)
> scaling factor: 100
>
> number of clients: 40
> number of transactions per client: 1000
> number of transactions actually processed: 40000/40000
> tps = 20.368217 (including connections establishing)
> tps = 20.368217 (excluding connections establishing)
Those numbers are abysmal. I had a P-III-750 5 years ago that ran
well into the hundreds on a large scaling factor (1000 or so) pgbench
db with 100 or more concurrent connections all the way down to 10
threads. I.e. it never dropped below 200 or so during the testing.
this was with a Perc3 series LSI controller with LSI firmware and the
megaraid 2.0.x driver, which I believe is the basis for the current
LSI drivers today.
A few points. 10 or 100 total transactions is far too few
transactions to really get a good number. 1000 is about the minimum
to run to get a good average, and running 10000 or so is about the
minimum I shoot for. So your later tests are likely to be less noisy.
They're all way too slow for a modern server, and point ot
non-optimal hardware. An untuned pgsql database should be able to get
to or over 100 tps. I had a sparc-20 that could do 80 or so.
Do you know if you're I/O bound or CPU bound?
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:12 Scott Marlowe <scott.marlowe@gmail.com>
parent: justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Scott Marlowe @ 2008-03-14 06:12 UTC (permalink / raw)
To: justin <justin@emproshunts.com>; +Cc: pgsql-performance
On Thu, Mar 13, 2008 at 3:09 PM, justin <justin@emproshunts.com> wrote:
> I chose to use ext3 on these partition
You should really consider another file system. ext3 has two flaws
that mean I can't really use it properly. A 2TB file system size
limit (at least on the servers I've tested) and it locks the whole
file system while deleting large files, which can take several seconds
and stop ANYTHING from happening during that time. This means that
dropping or truncating large tables in the middle of the day could
halt your database for seconds at a time. This one misfeature means
that ext2/3 are unsuitable for running under a database.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:17 Jesper Krogh <jesper@krogh.cc>
parent: Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 1 reply; 45+ messages in thread
From: Jesper Krogh @ 2008-03-14 06:17 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: justin <justin@emproshunts.com>; pgsql-performance
Scott Marlowe wrote:
> On Thu, Mar 13, 2008 at 3:09 PM, justin <justin@emproshunts.com> wrote:
>
>> I chose to use ext3 on these partition
>
> You should really consider another file system. ext3 has two flaws
> that mean I can't really use it properly. A 2TB file system size
> limit (at least on the servers I've tested) and it locks the whole
> file system while deleting large files, which can take several seconds
> and stop ANYTHING from happening during that time. This means that
> dropping or truncating large tables in the middle of the day could
> halt your database for seconds at a time. This one misfeature means
> that ext2/3 are unsuitable for running under a database.
I cannot acknowledge or deny the last one, but the first one is not
true. I have several volumes in the 4TB+ range on ext3 performing nicely.
I can test the "large file stuff", but how large? .. several GB is not a
problem here.
Jesper
--
Jesper
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:19 Scott Marlowe <scott.marlowe@gmail.com>
parent: Jesper Krogh <jesper@krogh.cc>
0 siblings, 3 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-14 06:19 UTC (permalink / raw)
To: Jesper Krogh <jesper@krogh.cc>; +Cc: justin <justin@emproshunts.com>; pgsql-performance
On Fri, Mar 14, 2008 at 12:17 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>
> Scott Marlowe wrote:
> > On Thu, Mar 13, 2008 at 3:09 PM, justin <justin@emproshunts.com> wrote:
> >
> >> I chose to use ext3 on these partition
> >
> > You should really consider another file system. ext3 has two flaws
> > that mean I can't really use it properly. A 2TB file system size
> > limit (at least on the servers I've tested) and it locks the whole
> > file system while deleting large files, which can take several seconds
> > and stop ANYTHING from happening during that time. This means that
> > dropping or truncating large tables in the middle of the day could
> > halt your database for seconds at a time. This one misfeature means
> > that ext2/3 are unsuitable for running under a database.
>
> I cannot acknowledge or deny the last one, but the first one is not
> true. I have several volumes in the 4TB+ range on ext3 performing nicely.
>
> I can test the "large file stuff", but how large? .. several GB is not a
> problem here.
Is this on a 64 bit or 32 bit machine? We had the problem with a 32
bit linux box (not sure what flavor) just a few months ago. I would
not create a filesystem on a partition of 2+TB
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:23 Scott Marlowe <scott.marlowe@gmail.com>
parent: Scott Marlowe <scott.marlowe@gmail.com>
2 siblings, 0 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-14 06:23 UTC (permalink / raw)
To: Jesper Krogh <jesper@krogh.cc>; +Cc: justin <justin@emproshunts.com>; pgsql-performance
On Fri, Mar 14, 2008 at 12:19 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>
> On Fri, Mar 14, 2008 at 12:17 AM, Jesper Krogh <jesper@krogh.cc> wrote:
> >
> > Scott Marlowe wrote:
> > > On Thu, Mar 13, 2008 at 3:09 PM, justin <justin@emproshunts.com> wrote:
> > >
> > >> I chose to use ext3 on these partition
> > >
> > > You should really consider another file system. ext3 has two flaws
> > > that mean I can't really use it properly. A 2TB file system size
> > > limit (at least on the servers I've tested) and it locks the whole
> > > file system while deleting large files, which can take several seconds
> > > and stop ANYTHING from happening during that time. This means that
> > > dropping or truncating large tables in the middle of the day could
> > > halt your database for seconds at a time. This one misfeature means
> > > that ext2/3 are unsuitable for running under a database.
> >
> > I cannot acknowledge or deny the last one, but the first one is not
> > true. I have several volumes in the 4TB+ range on ext3 performing nicely.
> >
> > I can test the "large file stuff", but how large? .. several GB is not a
> > problem here.
>
> Is this on a 64 bit or 32 bit machine? We had the problem with a 32
> bit linux box (not sure what flavor) just a few months ago. I would
> not create a filesystem on a partition of 2+TB
>
OK, according to this it's 16TiB:
http://en.wikipedia.org/wiki/Ext2
so I'm not sure what problem we were having. It was a friend setting
up the RAID and I'd already told him to use xfs but he really wanted
to use ext3 because he was more familiar with it.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 06:29 Jesper Krogh <jesper@krogh.cc>
parent: Scott Marlowe <scott.marlowe@gmail.com>
2 siblings, 0 replies; 45+ messages in thread
From: Jesper Krogh @ 2008-03-14 06:29 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: justin <justin@emproshunts.com>; pgsql-performance
Scott Marlowe wrote:
> On Fri, Mar 14, 2008 at 12:17 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>> Scott Marlowe wrote:
>> > On Thu, Mar 13, 2008 at 3:09 PM, justin <justin@emproshunts.com> wrote:
>> >
>> >> I chose to use ext3 on these partition
>> >
>> > You should really consider another file system. ext3 has two flaws
>> > that mean I can't really use it properly. A 2TB file system size
>> > limit (at least on the servers I've tested) and it locks the whole
>> > file system while deleting large files, which can take several seconds
>> > and stop ANYTHING from happening during that time. This means that
>> > dropping or truncating large tables in the middle of the day could
>> > halt your database for seconds at a time. This one misfeature means
>> > that ext2/3 are unsuitable for running under a database.
>>
>> I cannot acknowledge or deny the last one, but the first one is not
>> true. I have several volumes in the 4TB+ range on ext3 performing nicely.
>>
>> I can test the "large file stuff", but how large? .. several GB is not a
>> problem here.
>
> Is this on a 64 bit or 32 bit machine? We had the problem with a 32
> bit linux box (not sure what flavor) just a few months ago. I would
> not create a filesystem on a partition of 2+TB
It is on a 64 bit machine.. but ext3 doesnt have anything specifik in it
as far as I know.. I have mountet filesystems created on 32 bit on 64
bit and the other way around. The filesystems are around years old.
http://en.wikipedia.org/wiki/Ext3 => Limit seems to be 16TB currently
(It might get down to something lower if you choose a small blocksize).
--
Jesper
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 08:19 Greg Smith <gsmith@gregsmith.com>
parent: Justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Greg Smith @ 2008-03-14 08:19 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: pgsql-performance
On Fri, 14 Mar 2008, Justin wrote:
> I played with shared_buffer and never saw much of an improvement from
> 100 all the way up to 800 megs moved the checkpoints from 3 to 30 and
> still never saw no movement in the numbers.
Increasing shared_buffers normally improves performance as the size of the
database goes up, but since the pgbench workload is so simple the
operating system will cache it pretty well even if you don't give the
memory directly to PostgreSQL. Also, on Windows large settings for
shared_buffers don't work very well, you might as well keep it in the
100MB range.
> wal_sync_method=fsync
You might get a decent boost in resuls that write data (not the SELECT
ones) by changing
wal_sync_method = open_datasync
which is the default on Windows. The way you've got your RAID controller
setup, this is no more or less safe than using fsync.
> i agree with you, those numbers are terrible i realized after posting i
> had the option -C turned on if i read the option -C correctly it is
> disconnecting and reconnecting between transactions. The way read -C
> option creates the worst case.
In addition to being an odd testing mode, there's an outstanding bug in
how -C results are computed that someone submitted a fix for, but it
hasn't been applied yet. I would suggest forgetting you ever ran that
test.
> number of clients: 10
> number of transactions per client: 10000
> number of transactions actually processed: 100000/100000
> tps = 1768.940935 (including connections establishing)
> number of clients: 40
> number of transactions per client: 10000
> number of transactions actually processed: 400000/400000
> tps = 567.149831 (including connections establishing)
> tps = 568.648692 (excluding connections establishing)
Note how the total number of transactions goes up here, because it's
actually doing clients x requested transcations in total. The 40 client
case is actually doing 4X as many total operations. That also means you
can expect 4X as many checkpoints during that run. It's a longer run like
this second one that you might see some impact by increasing
checkpoint_segments.
To keep comparisons like this more fair, I like to keep the total
transactions constant and just divide that number by the number of clients
to figure out what to set the -t parameter to. 400000 is a good medium
length test, so for that case you'd get
-c 10 -t 40000
-c 40 -t 10000
as the two to compare.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 08:31 Justin <justin@emproshunts.com>
parent: Scott Marlowe <scott.marlowe@gmail.com>
2 siblings, 1 reply; 45+ messages in thread
From: Justin @ 2008-03-14 08:31 UTC (permalink / raw)
To: pgsql-performance
> Is this on a 64 bit or 32 bit machine? We had the problem with a 32
> bit linux box (not sure what flavor) just a few months ago. I would
> not create a filesystem on a partition of 2+TB
>
Yes this machine is 64bit
> You do know that effective_cache_size is the size of the OS level
> cache. i.e. it won't show up in postgresql's memory usage. On a
> machine with (I assume) 12 or more gigs or memory, you should have
> your shared_buffers set to a much higher number than 100Meg. (unless
> you're still running 7.4 but that's another story.)
Sorry for my ignorance of linux, i'm used to windows task manager or
performance monitor showing all the
memory usage. I
decided to move to Linux on the new server to get 64bit so still in the
learning curve with that
I played with shared_buffer and never saw much of an improvement from
100 all the way up to 800 megs moved the checkpoints from 3 to 30 and
still never saw no movement in the numbers.
i agree with you, those numbers are terrible i realized after posting i
had the option -C turned on
if i read the option -C correctly it is disconnecting and reconnecting
between transactions. The way read -C option creates the worst case.
The raid controller setting is set to make sure it don't lie on fsync
shared_buffers = 800megs
temp_buffers 204800
work_mem 256MB
fsync_on
wal_syns_method fysnc
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 10000 -v -h
192.168.1.9 -U postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 1768.940935 (including connections establishing)
tps = 1783.230500 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 567.149831 (including connections establishing)
tps = 568.648692 (excluding connections establishing)
--------------now with just Select --------------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 10 -t 10000 -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 16160.310278 (including connections establishing)
tps = 17436.791630 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 40 -t 10000 -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 18338.529250 (including connections establishing)
tps = 20031.048125 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 10:49 Justin <justin@emproshunts.com>
parent: Greg Smith <gsmith@gregsmith.com>
0 siblings, 1 reply; 45+ messages in thread
From: Justin @ 2008-03-14 10:49 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: pgsql-performance
Greg Smith wrote:
> On Fri, 14 Mar 2008, Justin wrote:
>
>> I played with shared_buffer and never saw much of an improvement from
>> 100 all the way up to 800 megs moved the checkpoints from 3 to 30 and
>> still never saw no movement in the numbers.
>
> Increasing shared_buffers normally improves performance as the size of
> the database goes up, but since the pgbench workload is so simple the
> operating system will cache it pretty well even if you don't give the
> memory directly to PostgreSQL. Also, on Windows large settings for
> shared_buffers don't work very well, you might as well keep it in the
> 100MB range.
>
>> wal_sync_method=fsync
>
> You might get a decent boost in resuls that write data (not the SELECT
> ones) by changing
>
> wal_sync_method = open_datasync
>
> which is the default on Windows. The way you've got your RAID
> controller setup, this is no more or less safe than using fsync.
I moved the window server back to fsync a long time ago. Around here we
are super paranoid about making sure the data does not become corrupt,
performance is secondary. The new server along with the old server is
way over built for the load it will ever see. I will be making the old
server a slony replicator located in the manufacturing building.
Also **note* *tried setting the value open_datasync and get invalid
parameter. instead i use open_sync
>
>> i agree with you, those numbers are terrible i realized after posting
>> i had the option -C turned on if i read the option -C correctly it is
>> disconnecting and reconnecting between transactions. The way read -C
>> option creates the worst case.
>
> In addition to being an odd testing mode, there's an outstanding bug
> in how -C results are computed that someone submitted a fix for, but
> it hasn't been applied yet. I would suggest forgetting you ever ran
> that test.
Why is the -C option odd?
>
> Note how the total number of transactions goes up here, because it's
> actually doing clients x requested transcations in total. The 40
> client case is actually doing 4X as many total operations. That also
> means you can expect 4X as many checkpoints during that run. It's a
> longer run like this second one that you might see some impact by
> increasing checkpoint_segments.
>
> To keep comparisons like this more fair, I like to keep the total
> transactions constant and just divide that number by the number of
> clients to figure out what to set the -t parameter to. 400000 is a
> good medium length test, so for that case you'd get
>
> -c 10 -t 40000
> -c 40 -t 10000
>
> as the two to compare.
>
---- retested with fsync turned on -----
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 767.040279 (including connections establishing)
tps = 767.707166 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 648.988227 (including connections establishing)
tps = 650.935720 (excluding connections establishing)
-------open_sync------------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 798.030461 (including connections establishing)
tps = 798.752349 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 613.879195 (including connections establishing)
tps = 615.592023 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-14 15:16 Michael Stone <mstone+postgres@mathom.us>
parent: Greg Smith <gsmith@gregsmith.com>
0 siblings, 0 replies; 45+ messages in thread
From: Michael Stone @ 2008-03-14 15:16 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: pgsql-performance
On Thu, Mar 13, 2008 at 05:27:09PM -0400, Greg Smith wrote:
>I haven't found fdatasync to be significantly better in my tests on Linux
>but I never went out of my way to try and quantify it. My understanding
>is that some of the write barrier implementation details on ext3
>filesystems make any sync call a relatively heavy operation but I haven't
>poked at the code yet to figure out why.
Which is why having the checkpoints on a seperate ext2 partition tends
to be a nice win. (Even if its not on a seperate disk.)
Mike Stone
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 06:19 Justin <justin@emproshunts.com>
parent: Justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Justin @ 2008-03-16 06:19 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: pgsql-performance
I decided to reformat the raid 10 into ext2 to see if there was any real
big difference in performance as some people have noted here is the
test results
please note the WAL files are still on the raid 0 set which is still in
ext3 file system format. these test where run with the fsync as
before. I made sure every thing was the same as with the first test.
As you can see there is a 3 to 3.5 times increase in performance
numbers just changing the file system
With -S option set there is not change in performance numbers
-------First Run 10 clients------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 2108.036891 (including connections establishing)
tps = 2112.902970 (excluding connections establishing)
-----Second Run 10 clients -----
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 2316.114949 (including connections establishing)
tps = 2321.990410 (excluding connections establishing)
-----First Run 40 clients --------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 2675.585284 (including connections establishing)
tps = 2706.707899 (excluding connections establishing)
---Second Run ----
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 2600.560421 (including connections establishing)
tps = 2629.952529 (excluding connections establishing)
---- Select Only Option ------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 10 -t 40000 -v -h
192.168.1.9
-U postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 18181.818182 (including connections establishing)
tps = 18550.294486 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 40 -t 10000 -v -h
192.168.1.9
-U postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 18991.548761 (including connections establishing)
tps = 20729.684909 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 11:25 Dave Cramer <pg@fastcrypt.com>
parent: Justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Dave Cramer @ 2008-03-16 11:25 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On 16-Mar-08, at 2:19 AM, Justin wrote:
>
> I decided to reformat the raid 10 into ext2 to see if there was any
> real big difference in performance as some people have noted here
> is the test results
>
> please note the WAL files are still on the raid 0 set which is still
> in ext3 file system format. these test where run with the fsync as
> before. I made sure every thing was the same as with the first test.
>
This is opposite to the way I run things. I use ext2 on the WAL and
ext3 on the data. I'd also suggest RAID 10 on the WAL it is mostly
write.
Dave
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 19:04 Craig James <craig_james@emolecules.com>
parent: Dave Cramer <pg@fastcrypt.com>
0 siblings, 4 replies; 45+ messages in thread
From: Craig James @ 2008-03-16 19:04 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Justin <justin@emproshunts.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Dave Cramer wrote:
>
> On 16-Mar-08, at 2:19 AM, Justin wrote:
>
>>
>> I decided to reformat the raid 10 into ext2 to see if there was any
>> real big difference in performance as some people have noted here is
>> the test results
>>
>> please note the WAL files are still on the raid 0 set which is still
>> in ext3 file system format. these test where run with the fsync as
>> before. I made sure every thing was the same as with the first test.
>>
> This is opposite to the way I run things. I use ext2 on the WAL and ext3
> on the data. I'd also suggest RAID 10 on the WAL it is mostly write.
Just out of curiosity: Last time I did research, the word seemed to be that xfs was better than ext2 or ext3. Is that not true? Why use ext2/3 at all if xfs is faster for Postgres?
Criag
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 19:08 Craig James <craig_james@emolecules.com>
parent: Craig James <craig_james@emolecules.com>
3 siblings, 0 replies; 45+ messages in thread
From: Craig James @ 2008-03-16 19:08 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Justin <justin@emproshunts.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Craig James wrote:
> Dave Cramer wrote:
>>
>> On 16-Mar-08, at 2:19 AM, Justin wrote:
>>
>>>
>>> I decided to reformat the raid 10 into ext2 to see if there was any
>>> real big difference in performance as some people have noted here
>>> is the test results
>>>
>>> please note the WAL files are still on the raid 0 set which is still
>>> in ext3 file system format. these test where run with the fsync as
>>> before. I made sure every thing was the same as with the first test.
>>>
>> This is opposite to the way I run things. I use ext2 on the WAL and
>> ext3 on the data. I'd also suggest RAID 10 on the WAL it is mostly write.
>
> Just out of curiosity: Last time I did research, the word seemed to be
> that xfs was better than ext2 or ext3. Is that not true? Why use
> ext2/3 at all if xfs is faster for Postgres?
>
> Criag
And let's see if I can write my own name ...
Craig
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 19:36 Dave Cramer <pg@fastcrypt.com>
parent: Craig James <craig_james@emolecules.com>
3 siblings, 2 replies; 45+ messages in thread
From: Dave Cramer @ 2008-03-16 19:36 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Justin <justin@emproshunts.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On 16-Mar-08, at 3:04 PM, Craig James wrote:
> Dave Cramer wrote:
>> On 16-Mar-08, at 2:19 AM, Justin wrote:
>>>
>>> I decided to reformat the raid 10 into ext2 to see if there was
>>> any real big difference in performance as some people have noted
>>> here is the test results
>>>
>>> please note the WAL files are still on the raid 0 set which is
>>> still in ext3 file system format. these test where run with the
>>> fsync as before. I made sure every thing was the same as with
>>> the first test.
>>>
>> This is opposite to the way I run things. I use ext2 on the WAL and
>> ext3 on the data. I'd also suggest RAID 10 on the WAL it is mostly
>> write.
>
> Just out of curiosity: Last time I did research, the word seemed to
> be that xfs was better than ext2 or ext3. Is that not true? Why
> use ext2/3 at all if xfs is faster for Postgres?
>
I would like to see the evidence of this. I doubt that it would be
faster than ext2. There is no journaling on ext2.
Dave
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-16 20:56 Scott Marlowe <scott.marlowe@gmail.com>
parent: Dave Cramer <pg@fastcrypt.com>
1 sibling, 0 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-16 20:56 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Craig James <craig_james@emolecules.com>; Justin <justin@emproshunts.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On Sun, Mar 16, 2008 at 1:36 PM, Dave Cramer <pg@fastcrypt.com> wrote:
>
> On 16-Mar-08, at 3:04 PM, Craig James wrote:
> > Just out of curiosity: Last time I did research, the word seemed to
> > be that xfs was better than ext2 or ext3. Is that not true? Why
> > use ext2/3 at all if xfs is faster for Postgres?
> >
> I would like to see the evidence of this. I doubt that it would be
> faster than ext2. There is no journaling on ext2.
Well, if you're dropping a large table ext2/3 has that very long wait
thing that can happen. Don't know how much battery backed cache would
help.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 07:14 Craig Ringer <craig@postnewspapers.com.au>
parent: Justin <justin@emproshunts.com>
2 siblings, 1 reply; 45+ messages in thread
From: Craig Ringer @ 2008-03-17 07:14 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Dave Cramer <pg@fastcrypt.com>; Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Justin wrote:
> OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
> out if XFS file system is installed, if not installed getting it
> installed.
There are two parts to the file system, really. One is the kernel driver
for the file system. This is almost certainly available, as it will ship
with the kernel. It might be a module that is loaded on demand or it
might be compiled into the kernel its self.
On my Debian Etch system it's a module, xfs.ko, that can be loaded
manually with:
modprobe xfs
... however, you should not need to do that, as it'll be autoloaded when
you try to mount an xfs volume.
The other part to the file system is the userspace tools for creating,
checking, resizing, etc the file system. An `apt-cache search xfs' shows
that these tools have the package name xfsprogs, at least on Debian.
You can install them with "apt-get install xfsprogs". If they're already
installed no action will be taken.
When xfsprogs is installed you can use mkfs.xfs (see: man mkfs.xfs) to
format a block device (say, a partition like /dev/sda1 or an LVM logical
volume like /dev/SOMELVMVG/somelvmlv) with the xfs file system.
Once the file system is formatted you can mount it manually with the
mount command, eg:
mkdir /mnt/tmp
mount -t xfs /dev/sda1 /mnt/tmp
... or have it mounted on boot using an fstab entry like:
/dev/sda1 /path/to/desired/mountpoint xfs defaults 0 0
--
Craig Ringer
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 07:36 Justin <justin@emproshunts.com>
parent: Dave Cramer <pg@fastcrypt.com>
1 sibling, 3 replies; 45+ messages in thread
From: Justin @ 2008-03-17 07:36 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
out if XFS file system is installed, if not installed getting it
installed.
I would like to see the difference between XFS and ext2 performance
numbers.
any pointers would be nice. I 'm not going to reinstall the OS. Nor do
i want to install some unstable library into the kernel.
Dave Cramer wrote:
>
> On 16-Mar-08, at 3:04 PM, Craig James wrote:
>
>> Dave Cramer wrote:
>>> On 16-Mar-08, at 2:19 AM, Justin wrote:
>>>>
>>>> I decided to reformat the raid 10 into ext2 to see if there was any
>>>> real big difference in performance as some people have noted here
>>>> is the test results
>>>>
>>>> please note the WAL files are still on the raid 0 set which is
>>>> still in ext3 file system format. these test where run with the
>>>> fsync as before. I made sure every thing was the same as with the
>>>> first test.
>>>>
>>> This is opposite to the way I run things. I use ext2 on the WAL and
>>> ext3 on the data. I'd also suggest RAID 10 on the WAL it is mostly
>>> write.
>>
>> Just out of curiosity: Last time I did research, the word seemed to
>> be that xfs was better than ext2 or ext3. Is that not true? Why use
>> ext2/3 at all if xfs is faster for Postgres?
>>
> I would like to see the evidence of this. I doubt that it would be
> faster than ext2. There is no journaling on ext2.
>
> Dave
>
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 08:02 Andrej Ricnik-Bay <andrej.groups@gmail.com>
parent: Justin <justin@emproshunts.com>
2 siblings, 0 replies; 45+ messages in thread
From: Andrej Ricnik-Bay @ 2008-03-17 08:02 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: pgsql-performance
On 17/03/2008, Justin <justin@emproshunts.com> wrote:
> OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
> out if XFS file system is installed, if not installed getting it
> installed.
...
> any pointers would be nice. I 'm not going to reinstall the OS. Nor do
> i want to install some unstable library into the kernel.
It's there. All you need to do is (I hope ;}) back-up the
partition with the database files on it, reformat using mkfs.xfs
(man mkfs.xfs for details), modify /etc/fstab to say xfs where
it says ext2 for the database partition, restore the data and
use it...
Cheers,
Andrej
--
Please don't top post, and don't use HTML e-Mail :} Make your quotes concise.
http://www.american.edu/econ/notes/htmlmail.htm
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 09:11 Tino Wildenhain <tino@wildenhain.de>
parent: Justin <justin@emproshunts.com>
2 siblings, 0 replies; 45+ messages in thread
From: Tino Wildenhain @ 2008-03-17 09:11 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Dave Cramer <pg@fastcrypt.com>; Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Justin wrote:
> OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
> out if XFS file system is installed, if not installed getting it
> installed.
Hm? Installed/not installed? You can select that when you are preparing
your partitions. If you run the automated partitioner there is of course
not much choice but you can try the manual mode. Even after that you
can format individual partitions with XFS if you want. XFS is long since
included in the recent linux kernels, also there is raiserfs if you feel
desperate (well in fact raiser fs is ok too but you should not use it
on flaky hardware). Both xfs and raiser are designed for journaling -
it is believed that xfs performs better with large files and raiser
good with many small files (like Maildir for example).
I'd suggest a test with your data and workload to be sure.
Regards
Tino
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 16:31 Justin <justin@emproshunts.com>
parent: Craig Ringer <craig@postnewspapers.com.au>
0 siblings, 0 replies; 45+ messages in thread
From: Justin @ 2008-03-17 16:31 UTC (permalink / raw)
To: Craig Ringer <craig@postnewspapers.com.au>; +Cc: Dave Cramer <pg@fastcrypt.com>; Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Well every thing worked right up to the point where i tried to mount the
file system
Warning: xfs_db: /dev/sdb1 contains a mounted file system
fatal error -- couldn't initialize XFS library.
think i'm missing something???
Craig Ringer wrote:
> Justin wrote:
>
>> OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
>> out if XFS file system is installed, if not installed getting it
>> installed.
>>
>
> There are two parts to the file system, really. One is the kernel driver
> for the file system. This is almost certainly available, as it will ship
> with the kernel. It might be a module that is loaded on demand or it
> might be compiled into the kernel its self.
>
> On my Debian Etch system it's a module, xfs.ko, that can be loaded
> manually with:
>
> modprobe xfs
>
> ... however, you should not need to do that, as it'll be autoloaded when
> you try to mount an xfs volume.
>
> The other part to the file system is the userspace tools for creating,
> checking, resizing, etc the file system. An `apt-cache search xfs' shows
> that these tools have the package name xfsprogs, at least on Debian.
>
> You can install them with "apt-get install xfsprogs". If they're already
> installed no action will be taken.
>
> When xfsprogs is installed you can use mkfs.xfs (see: man mkfs.xfs) to
> format a block device (say, a partition like /dev/sda1 or an LVM logical
> volume like /dev/SOMELVMVG/somelvmlv) with the xfs file system.
>
> Once the file system is formatted you can mount it manually with the
> mount command, eg:
>
> mkdir /mnt/tmp
> mount -t xfs /dev/sda1 /mnt/tmp
>
> ... or have it mounted on boot using an fstab entry like:
>
> /dev/sda1 /path/to/desired/mountpoint xfs defaults 0 0
>
> --
> Craig Ringer
>
>
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 18:12 Dave Cramer <pg@fastcrypt.com>
parent: Justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Dave Cramer @ 2008-03-17 18:12 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On 17-Mar-08, at 2:50 PM, Justin wrote:
>
>>
>> Just out of curiosity: Last time I did research, the word seemed to
>> be that xfs was better than ext2 or ext3. Is that not true? Why
>> use ext2/3 at all if xfs is faster for Postgres?
>>
>> Criag
>
> Ext2 vs XFS on my setup there is difference in the performance
> between the two file systems but its not OMG let switch. XFS did
> better then Ext2 only one time, then Ext2 won out by small margin at
> best was 6%. the other test ran at 3 to 4% better than XFS
> performance.
>
> XFS has journaling so it should be safer. I think i may stick with
> XFS as it has journaling
>
> One thing i think is clear don't use ext3 it just kills performance
> by factors not small percents
>
> here is article i found on XFS http://linux-xfs.sgi.com/projects/xfs/papers/xfs_white/xfs_white_paper.html
>
> I hope this is helpful to people. I know the process has taught me
> new things, and thanks to those that helped me out.
>
> Before i throw this sever into production any one else want
> performance numbers.
>
> C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
> 192.168.1.9 -U
> postgres play
> Password:
> starting vacuum...end.
> starting vacuum accounts...end.
> transaction type: TPC-B (sort of)
> scaling factor: 100
> number of clients: 10
> number of transactions per client: 40000
> number of transactions actually processed: 400000/400000
> tps = 2181.512770 (including connections establishing)
> tps = 2187.107004 (excluding connections establishing)
>
2000 tps ??? do you have fsync turned off ?
Dave
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 18:33 Craig James <craig_james@emolecules.com>
parent: Justin <justin@emproshunts.com>
0 siblings, 1 reply; 45+ messages in thread
From: Craig James @ 2008-03-17 18:33 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Justin wrote:
>> 2000 tps ??? do you have fsync turned off ?
>>
>> Dave
>>
>
> No its turned on.
Unless I'm seriously confused, something is wrong with these numbers. That's the sort of performance you expect from a good-sized RAID 10 six-disk array. With a single 7200 rpm SATA disk and XFS, I get 640 tps. There's no way you could 2000 tps from a single disk.
Craig
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 18:50 Justin <justin@emproshunts.com>
parent: Craig James <craig_james@emolecules.com>
3 siblings, 1 reply; 45+ messages in thread
From: Justin @ 2008-03-17 18:50 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Dave Cramer <pg@fastcrypt.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
>
> Just out of curiosity: Last time I did research, the word seemed to be
> that xfs was better than ext2 or ext3. Is that not true? Why use
> ext2/3 at all if xfs is faster for Postgres?
>
> Criag
Ext2 vs XFS on my setup there is difference in the performance between
the two file systems but its not OMG let switch. XFS did better then
Ext2 only one time, then Ext2 won out by small margin at best was 6%.
the other test ran at 3 to 4% better than XFS performance.
XFS has journaling so it should be safer. I think i may stick with XFS
as it has journaling
One thing i think is clear don't use ext3 it just kills performance by
factors not small percents
here is article i found on XFS
http://linux-xfs.sgi.com/projects/xfs/papers/xfs_white/xfs_white_paper.html
I hope this is helpful to people. I know the process has taught me new
things, and thanks to those that helped me out.
Before i throw this sever into production any one else want performance
numbers.
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 2181.512770 (including connections establishing)
tps = 2187.107004 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 40000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 40000
number of transactions actually processed: 400000/400000
tps = 2248.365719 (including connections establishing)
tps = 2254.308547 (excluding connections establishing)
-----------Clients log increased to 40------------
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 2518.447629 (including connections establishing)
tps = 2548.014141 (excluding connections establishing)
C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres play
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 2606.933139 (including connections establishing)
tps = 2638.626859 (excluding connections establishing)
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 19:12 Justin <justin@emproshunts.com>
parent: Dave Cramer <pg@fastcrypt.com>
0 siblings, 1 reply; 45+ messages in thread
From: Justin @ 2008-03-17 19:12 UTC (permalink / raw)
To: ; +Cc: Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
>>
>>
>
>
> 2000 tps ??? do you have fsync turned off ?
>
> Dave
>
No its turned on.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 19:38 Justin <justin@emproshunts.com>
parent: Craig James <craig_james@emolecules.com>
0 siblings, 2 replies; 45+ messages in thread
From: Justin @ 2008-03-17 19:38 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Craig James wrote:
> Justin wrote:
>>> 2000 tps ??? do you have fsync turned off ?
>>>
>>> Dave
>>>
>>
>> No its turned on.
>
> Unless I'm seriously confused, something is wrong with these numbers.
> That's the sort of performance you expect from a good-sized RAID 10
> six-disk array. With a single 7200 rpm SATA disk and XFS, I get 640
> tps. There's no way you could 2000 tps from a single disk.
>
> Craig
>
it is a RAID 10 controller with 6 SAS 10K 73 gig drives. The server
is 3 weeks old now.
it has 16 gigs of RAM
2 quad core Xenon 1.88 Ghz processors
2 gig Ethernet cards.
RAID controller perc 6/i with battery backup 512meg cache, setup not lie
about fsync
WAL is on a RAID 0 drive along with the OS
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 20:58 Enrico Sirola <enrico.sirola@gmail.com>
parent: Justin <justin@emproshunts.com>
1 sibling, 1 reply; 45+ messages in thread
From: Enrico Sirola @ 2008-03-17 20:58 UTC (permalink / raw)
To: Justin <justin@emproshunts.com>; +Cc: Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
Hi Justin,
Il giorno 17/mar/08, alle ore 20:38, Justin ha scritto:
> it is a RAID 10 controller with 6 SAS 10K 73 gig drives. The
> server is 3 weeks old now.
>
> it has 16 gigs of RAM
> 2 quad core Xenon 1.88 Ghz processors
> 2 gig Ethernet cards. RAID controller perc 6/i with battery backup
> 512meg cache, setup not lie about fsync
>
> WAL is on a RAID 0 drive along with the OS
Did you try with a single raid 10 hosting DB + WAL? It gave me much
better performances on similar hardware
Bye,
e.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-17 21:57 Scott Marlowe <scott.marlowe@gmail.com>
parent: Enrico Sirola <enrico.sirola@gmail.com>
0 siblings, 0 replies; 45+ messages in thread
From: Scott Marlowe @ 2008-03-17 21:57 UTC (permalink / raw)
To: Enrico Sirola <enrico.sirola@gmail.com>; +Cc: Justin <justin@emproshunts.com>; Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
On Mon, Mar 17, 2008 at 2:58 PM, Enrico Sirola <enrico.sirola@gmail.com> wrote:
> Hi Justin,
>
> Il giorno 17/mar/08, alle ore 20:38, Justin ha scritto:
>
> > it is a RAID 10 controller with 6 SAS 10K 73 gig drives. The
> > server is 3 weeks old now.
> >
> > it has 16 gigs of RAM
> > 2 quad core Xenon 1.88 Ghz processors
> > 2 gig Ethernet cards. RAID controller perc 6/i with battery backup
> > 512meg cache, setup not lie about fsync
> >
> > WAL is on a RAID 0 drive along with the OS
>
> Did you try with a single raid 10 hosting DB + WAL? It gave me much
> better performances on similar hardware
> Bye,
Note that it can often be advantageous to have one big physical
partition on RAID-10 and to then break it into logical partitions for
the computer, so that you have a partition with just ext2 for the WAL
and since it has its own file system you usually get better
performance without having to actually hard partition out a separate
RAID-1 or RAID-10 for WAL.
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-18 07:08 James Mansion <james@mansionfamily.plus.com>
parent: Justin <justin@emproshunts.com>
1 sibling, 0 replies; 45+ messages in thread
From: James Mansion @ 2008-03-18 07:08 UTC (permalink / raw)
To: justin@emproshunts.com; +Cc: Craig James <craig_james@emolecules.com>; Greg Smith <gsmith@gregsmith.com>; pgsql-performance
justin@emproshunts.com wrote:
>
> WAL is on a RAID 0 drive along with the OS
Isn't that just as unsafe as having the whole lot on RAID0?
^ permalink raw reply [nested|flat] 45+ messages in thread
* Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
@ 2008-03-18 11:04 Michael Stone <mstone+postgres@mathom.us>
parent: Craig James <craig_james@emolecules.com>
3 siblings, 0 replies; 45+ messages in thread
From: Michael Stone @ 2008-03-18 11:04 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
On Sun, Mar 16, 2008 at 12:04:44PM -0700, Craig James wrote:
>Just out of curiosity: Last time I did research, the word seemed to be that
>xfs was better than ext2 or ext3. Is that not true? Why use ext2/3 at all
>if xfs is faster for Postgres?
For the WAL, the filesystem is largely irrelevant. (It's relatively
small, the files are preallocated, the data is synced to disk so there's
not advantage from write buffering, etc.) The best filesystem is one
that does almost nothing and stays out of the way--ext2 is a good choice
for that. The data is a different story and a different filesystem is
usually a better choice. (If for no other reason than to avoid long
fsck times.)
Mike Stone
^ permalink raw reply [nested|flat] 45+ messages in thread
end of thread, other threads:[~2008-03-18 11:04 UTC | newest]
Thread overview: 45+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-03-13 04:55 ` Craig James <craig_james@emolecules.com>
2008-03-13 05:31 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-13 05:55 ` Joshua D. Drake <jd@commandprompt.com>
2008-03-13 14:54 ` Craig James <craig_james@emolecules.com>
2008-03-13 16:01 ` Greg Smith <gsmith@gregsmith.com>
2008-03-13 21:06 ` Joshua D. Drake <jd@commandprompt.com>
2008-03-13 21:27 ` Greg Smith <gsmith@gregsmith.com>
2008-03-14 15:16 ` Michael Stone <mstone+postgres@mathom.us>
2008-03-13 22:53 ` justin <justin@emproshunts.com>
2008-03-14 06:09 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-13 08:11 ` Justin Graf <justin@emproshunts.com>
2008-03-13 12:11 ` Doug Knight <dknight@wsi.com>
2008-03-13 14:36 ` Craig James <craig_james@emolecules.com>
2008-03-13 13:11 ` Will Weaver <will@myemma.com>
2008-03-13 13:55 ` Justin Graf <justin@emproshunts.com>
2008-03-13 14:29 ` Craig James <craig_james@emolecules.com>
2008-03-13 21:09 ` justin <justin@emproshunts.com>
2008-03-14 06:12 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-14 06:17 ` Jesper Krogh <jesper@krogh.cc>
2008-03-14 06:19 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-14 06:23 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-14 06:29 ` Jesper Krogh <jesper@krogh.cc>
2008-03-14 08:31 ` Justin <justin@emproshunts.com>
2008-03-14 08:19 ` Greg Smith <gsmith@gregsmith.com>
2008-03-14 10:49 ` Justin <justin@emproshunts.com>
2008-03-16 06:19 ` Justin <justin@emproshunts.com>
2008-03-16 11:25 ` Dave Cramer <pg@fastcrypt.com>
2008-03-16 19:04 ` Craig James <craig_james@emolecules.com>
2008-03-16 19:08 ` Craig James <craig_james@emolecules.com>
2008-03-16 19:36 ` Dave Cramer <pg@fastcrypt.com>
2008-03-16 20:56 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-17 07:36 ` Justin <justin@emproshunts.com>
2008-03-17 07:14 ` Craig Ringer <craig@postnewspapers.com.au>
2008-03-17 16:31 ` Justin <justin@emproshunts.com>
2008-03-17 08:02 ` Andrej Ricnik-Bay <andrej.groups@gmail.com>
2008-03-17 09:11 ` Tino Wildenhain <tino@wildenhain.de>
2008-03-17 18:50 ` Justin <justin@emproshunts.com>
2008-03-17 18:12 ` Dave Cramer <pg@fastcrypt.com>
2008-03-17 19:12 ` Justin <justin@emproshunts.com>
2008-03-17 18:33 ` Craig James <craig_james@emolecules.com>
2008-03-17 19:38 ` Justin <justin@emproshunts.com>
2008-03-17 20:58 ` Enrico Sirola <enrico.sirola@gmail.com>
2008-03-17 21:57 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-18 07:08 ` James Mansion <james@mansionfamily.plus.com>
2008-03-18 11:04 ` Michael Stone <mstone+postgres@mathom.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox