Re: [PERFORM] Some performance testing?
Scott, Can confirm that for pg purposes, 3.2 is basically broken in some not to great ways. We've had servers that were overloaded at load factors of 20 or 30 drop down to 5 or less with just a change from 3.2 to 3.11/3.13 on ubuntu 12.04 That's correct, and 3.5 shares the same problems. The underlying issue was that 3.X was tweaked to be MUCH more aggressive about cache-clearing, to the point where it would be evicting data from the FS cache which had just been read in and hadn't even been used yet. For some reason, this aggressive eviction got worse the more processes on the system which were using the FS cache, so where you really see it is when you have more processes with cache than you have cores. It's pretty easy to demonstrate just using pgbench, with a database larger than RAM, and 2X as many clients as cores. You'll see that kernels 3.2 and 3.5 will do 3X to 5X as much IO for the same workload as 3.10 and later will do. Greame, On 04/09/2015 04:01 AM, Graeme B. Bell wrote: performance with 2.6: (pgbench, size 100, 32 clients) 48 651 transactions per second (read only) 6 504 transactions per second (read-write) performance with 3.18 (pgbench, size 100, 32 clients) 129 303 transactions per second (read only) 16 895 transactions (read-write) Thanks for that data! I'm glad to see that 3.18 has improved so much. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? Sorry to cut in - So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much faster than with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness). We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml). http://elrepo.org/tiki/kernel-ml Graeme Bell -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
On Thu, Apr 9, 2015 at 7:35 AM, Graeme B. Bell g...@skogoglandskap.no wrote: ext4 settings ext4, nobarrier noatime+nodatime, stripestride aligned between raid10 ext4 correctly. Some other useful things to know -- h710p readahead disabled on H710P writeback cache enabled on H710P Direct IO enabled on H710P -- os filesystem settings linux readahead enabled (16384), nr_requests=975 NOOP scheduler non-NUMA -- pg io_concurrency on async commit.*** see below! All settings were kept identical on the server before and after the kernel change, so this performance increase can be entirely attributed to the newer kernel and its synergies with our configuration. 3.18 contains about 5-10 years of linux kernel development vs. 2.6 kernels (except where backported). I have conducted quite a lot of plug-pull testing with diskchecker.pl, and rather a lot of testing of scheduling/IO/RAID controller/etc parameters. The OS/RAID controller/file system settings are as fast as I've been able to achieve without compromising database integrity (please note: this server can run async_commit because of the work we use it for, but we do not use that setting on our other main production servers). Our local DBs run extremely nicely for all our normal queries which involve quite a mix of random small IO and full-table operations on e.g. 20GB+ tables , so they're not optimised for pgbench specifically. It would be handy to see a chart comparing 3.11, 3.13 and 3.18 as well, to see if most / any of those performance gains came in earlier kernels, but after 2.6 or 3.2 etc. Can confirm that for pg purposes, 3.2 is basically broken in some not to great ways. We've had servers that were overloaded at load factors of 20 or 30 drop down to 5 or less with just a change from 3.2 to 3.11/3.13 on ubuntu 12.04 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
ext4 settings ext4, nobarrier noatime+nodatime, stripestride aligned between raid10 ext4 correctly. Some other useful things to know -- h710p readahead disabled on H710P writeback cache enabled on H710P Direct IO enabled on H710P -- os filesystem settings linux readahead enabled (16384), nr_requests=975 NOOP scheduler non-NUMA -- pg io_concurrency on async commit.*** see below! All settings were kept identical on the server before and after the kernel change, so this performance increase can be entirely attributed to the newer kernel and its synergies with our configuration. 3.18 contains about 5-10 years of linux kernel development vs. 2.6 kernels (except where backported). I have conducted quite a lot of plug-pull testing with diskchecker.pl, and rather a lot of testing of scheduling/IO/RAID controller/etc parameters. The OS/RAID controller/file system settings are as fast as I've been able to achieve without compromising database integrity (please note: this server can run async_commit because of the work we use it for, but we do not use that setting on our other main production servers). Our local DBs run extremely nicely for all our normal queries which involve quite a mix of random small IO and full-table operations on e.g. 20GB+ tables , so they're not optimised for pgbench specifically. Graeme Bell On 09 Apr 2015, at 13:56, Przemysław Deć przemyslaw@linuxpolska.pl wrote: Wow, thats huge performance gain. And it was on ext4? -- Linux Polska Sp. z o.o. Przemysław Deć - Senior Solutions Architect RHCSA, RHCJA, PostgreSQL Professional Certification mob: +48 519 130 141 email: p...@linuxpolska.pl www.linuxpolska.pl ___ Linux Polska Sp. z o. o. Al. Jerozolimskie 123A (26 p.); 02-017 Warszawa; tel. (+48) 222139571; fax (+48)222139671 KRS - 326158 Sąd Rejonowy dla M. St. Warszawy w Warszawie, XII Wydział Gospodarczy KRS Kapitał zakładowy wpłacony 1 000 500PLN; NIP 7010181018; REGON 141791601 Mail Attachment.jpeg 2015-04-09 13:01 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: From a measurement I took back when we did the upgrade: performance with 2.6: (pgbench, size 100, 32 clients) 48 651 transactions per second (read only) 6 504 transactions per second (read-write) performance with 3.18 (pgbench, size 100, 32 clients) 129 303 transactions per second (read only) 16 895 transactions (read-write) So that looks like 2.6x improvement to reads and writes. That was an 8 core xeon server with H710P and 4x crucial M550 SSDs in RAID, pg9.3. Graeme Bell On 09 Apr 2015, at 12:39, Przemysław Deć przemyslaw@linuxpolska.pl wrote: Can you say how much faster it was? Przemek Deć 2015-04-09 11:04 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? Sorry to cut in - So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much faster than with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness). We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml). http://elrepo.org/tiki/kernel-ml Graeme Bell -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Hey Mike, What those graphs are showing is that the new kernel reduces the IO required for the same DB load. At least, that’s how we’re supposed to interpret it. I’d be curious to see a measure of the database load for both of those so we can verify that the new kernel does in fact provide better performance. -Wes From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Michael Nolan Sent: Wednesday, April 08, 2015 5:09 PM To: Josh Berkus Cc: Mel Llaguno; Przemysław Deć; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Some performance testing? On Wed, Apr 8, 2015 at 3:05 PM, Josh Berkus j...@agliodbs.commailto:j...@agliodbs.com wrote: On 04/07/2015 11:07 AM, Mel Llaguno wrote: Care to elaborate? We usually do not recommend specific kernel versions for our customers (who run on a variety of distributions). Thanks, M. You should. http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html Performance is literally 2X to 5X different between kernels. Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? -- Mike Nolan
Re: [PERFORM] Some performance testing?
Can you say how much faster it was? Przemek Deć 2015-04-09 11:04 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? Sorry to cut in - So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much faster than with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness). We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml). http://elrepo.org/tiki/kernel-ml Graeme Bell -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
From a measurement I took back when we did the upgrade: performance with 2.6: (pgbench, size 100, 32 clients) 48 651 transactions per second (read only) 6 504 transactions per second (read-write) performance with 3.18 (pgbench, size 100, 32 clients) 129 303 transactions per second (read only) 16 895 transactions (read-write) So that looks like 2.6x improvement to reads and writes. That was an 8 core xeon server with H710P and 4x crucial M550 SSDs in RAID, pg9.3. Graeme Bell On 09 Apr 2015, at 12:39, Przemysław Deć przemyslaw@linuxpolska.pl wrote: Can you say how much faster it was? Przemek Deć 2015-04-09 11:04 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? Sorry to cut in - So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much faster than with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness). We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml). http://elrepo.org/tiki/kernel-ml Graeme Bell -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Wow, thats huge performance gain. And it was on ext4? -- Linux Polska Sp. z o.o. Przemysław Deć - Senior Solutions Architect RHCSA, RHCJA, PostgreSQL Professional Certification mob: +48 519 130 141 email: p...@linuxpolska.pl www.linuxpolska.pl ___ Linux Polska Sp. z o. o. Al. Jerozolimskie 123A (26 p.); 02-017 Warszawa; tel. (+48) 222139571; fax (+48)222139671 KRS - 326158 Sąd Rejonowy dla M. St. Warszawy w Warszawie, XII Wydział Gospodarczy KRS Kapitał zakładowy wpłacony 1 000 500PLN; NIP 7010181018; REGON 141791601 [image: Open Source Day 2015] http://opensourceday.pl/ 2015-04-09 13:01 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: From a measurement I took back when we did the upgrade: performance with 2.6: (pgbench, size 100, 32 clients) 48 651 transactions per second (read only) 6 504 transactions per second (read-write) performance with 3.18 (pgbench, size 100, 32 clients) 129 303 transactions per second (read only) 16 895 transactions (read-write) So that looks like 2.6x improvement to reads and writes. That was an 8 core xeon server with H710P and 4x crucial M550 SSDs in RAID, pg9.3. Graeme Bell On 09 Apr 2015, at 12:39, Przemysław Deć przemyslaw@linuxpolska.pl wrote: Can you say how much faster it was? Przemek Deć 2015-04-09 11:04 GMT+02:00 Graeme B. Bell g...@skogoglandskap.no: Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? Sorry to cut in - So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much faster than with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness). We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml). http://elrepo.org/tiki/kernel-ml Graeme Bell -- Sent via pgsql-performance mailing list ( pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
On Wed, Apr 8, 2015 at 3:05 PM, Josh Berkus j...@agliodbs.com wrote: On 04/07/2015 11:07 AM, Mel Llaguno wrote: Care to elaborate? We usually do not recommend specific kernel versions for our customers (who run on a variety of distributions). Thanks, M. You should. http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html Performance is literally 2X to 5X different between kernels. Josh, there seems to be an inconsistency in your blog. You say 3.10.X is safe, but the graph you show with the poor performance seems to be from 3.13.X which as I understand it is a later kernel. Can you clarify which 3.X kernels are good to use and which are not? -- Mike Nolan
Re: [PERFORM] Some performance testing?
Cool. Good to know. I'll see if I can replicate these results in my environment. Thanks, M. From: Josh Berkus j...@agliodbs.com Sent: Wednesday, April 08, 2015 1:05 PM To: Mel Llaguno; Przemysław Deć Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Some performance testing? On 04/07/2015 11:07 AM, Mel Llaguno wrote: Care to elaborate? We usually do not recommend specific kernel versions for our customers (who run on a variety of distributions). Thanks, M. You should. http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html Performance is literally 2X to 5X different between kernels. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
On 04/07/2015 11:07 AM, Mel Llaguno wrote: Care to elaborate? We usually do not recommend specific kernel versions for our customers (who run on a variety of distributions). Thanks, M. You should. http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html Performance is literally 2X to 5X different between kernels. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
FYI - all my tests were conducted using Ubuntu 12.04 x64 LTS (which I believe are all 3.xx series kernels). Mel Llaguno • Staff Engineer – Team Lead Office: +1.403.264.9717 x310 www.coverity.com http://www.coverity.com/ • Twitter: @coverity Coverity by Synopsys On 4/6/15, 2:51 PM, Josh Berkus j...@agliodbs.com wrote: On 04/01/2015 01:37 AM, Przemysław Deć wrote: Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. Due to how these are hosted, I can't swap out kernels. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
On 04/07/2015 09:46 AM, Mel Llaguno wrote: FYI - all my tests were conducted using Ubuntu 12.04 x64 LTS (which I believe are all 3.xx series kernels). If it's 3.2 or 3.5, then your tests aren't useful, I'm afraid. Both of those kernels have known, severe, memory management issues. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Care to elaborate? We usually do not recommend specific kernel versions for our customers (who run on a variety of distributions). Thanks, M. Mel Llaguno • Staff Engineer – Team Lead Office: +1.403.264.9717 x310 www.coverity.com http://www.coverity.com/ • Twitter: @coverity Coverity by Synopsys On 4/7/15, 11:41 AM, Josh Berkus j...@agliodbs.com wrote: On 04/07/2015 09:46 AM, Mel Llaguno wrote: FYI - all my tests were conducted using Ubuntu 12.04 x64 LTS (which I believe are all 3.xx series kernels). If it's 3.2 or 3.5, then your tests aren't useful, I'm afraid. Both of those kernels have known, severe, memory management issues. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
On 04/01/2015 01:37 AM, Przemysław Deć wrote: Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. Due to how these are hosted, I can't swap out kernels. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Although the results only focus on SATA2 HDD, these may be useful for a comparison of ext4 vs. xfs : http://www.fuzzy.cz/bench/compare-pgbench.php?type[]=btrfs-datacow-barrier:1type[]=btrfs-datacow-nobarrier:1type[]=btrfs-nodatacow-barrier:1type[]=btrfs-nodatacow-nobarrier:1type[]=ext4-writeback-barrier:1type[]=ext4-writeback-nobarrier:1type[]=xfs-barrier:1type[]=xfs-nobarrier:1? M. From: Przemysław Deć przemyslaw@linuxpolska.pl Sent: Wednesday, April 01, 2015 3:02 AM To: Mel Llaguno Cc: Josh Berkus; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Some performance testing? Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. I was looking for some guidance what to choose and there is very poor information about such things. [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] -- Przemysław Deć Senior Solutions Architect Linux Polska Sp. z o.o 2015-04-01 10:37 GMT+02:00 Przemysław Deć przemyslaw@linuxpolska.plmailto:przemyslaw@linuxpolska.pl: Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. I was looking for some guidance what to choose and there is very poor information about such things. -- Przemysław Deć Senior Solutions Architect Linux Polska Sp. z o.o 2015-03-31 22:41 GMT+02:00 Mel Llaguno mllag...@coverity.commailto:mllag...@coverity.com: It would be interesting to get raw performance benchmarks in addition to PG specific benchmarks. I've been measuring raw I/O performance of a few of our systems and run the following tests as well: 1. 10 runs of bonnie++ 2. 5 runs of hdparm -Tt 3. Using a temp file created on the SSD, dd if=tempfile of=/dev/null bs=1M count=1024 echo 3 /proc/sys/vm/drop_caches; dd if=tempfileof=/dev/null bs=1M count=1024 4. Using phoronix benchmarks - stream / ramspeed / compress-7zip I was curious to measure the magnitude of difference between HDD - SSD. I would expect significant differences between SSD - PCI-E Flash. I've included some metrics from some previous runs vs. different types of SSDs (OWC Mercury Extreme 6G which is our standard SSD, an Intel S3700 SSD, a Samsung SSD 840 PRO) vs. some standard HDD from Western Digital and HGST. I put in a req for a 960Gb Mercury Excelsior PCI-E SSD which hasn't yet materialized ... Thanks, M. Mel Llaguno * Staff Engineer - Team Lead Office: +1.403.264.9717 x310 www.coverity.comhttp://www.coverity.com http://www.coverity.com/ * Twitter: @coverity Coverity by Synopsys On 3/31/15, 1:52 PM, Josh Berkus j...@agliodbs.commailto:j...@agliodbs.com wrote: All, I currently have access to a matched pair of 20-core, 128GB RAM servers with SSD-PCI storage, for about 2 weeks before they go into production. Are there any performance tests people would like to see me run on these? Otherwise, I'll just do some pgbench and DVDStore. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.orgmailto:pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.orgmailto:pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. I was looking for some guidance what to choose and there is very poor information about such things. -- Przemysław Deć Senior Solutions Architect Linux Polska Sp. z o.o 2015-04-01 10:37 GMT+02:00 Przemysław Deć przemyslaw@linuxpolska.pl: Maybe you will find time to benchamark xfs vs ext4 (with and without journaling enabled on ext4). Nice comparison also could be rhel 6.5 with its newest kernel 2.6.32-X vs RHEL 7.0 and kernel 3.10. I was looking for some guidance what to choose and there is very poor information about such things. -- Przemysław Deć Senior Solutions Architect Linux Polska Sp. z o.o 2015-03-31 22:41 GMT+02:00 Mel Llaguno mllag...@coverity.com: It would be interesting to get raw performance benchmarks in addition to PG specific benchmarks. I’ve been measuring raw I/O performance of a few of our systems and run the following tests as well: 1. 10 runs of bonnie++ 2. 5 runs of hdparm -Tt 3. Using a temp file created on the SSD, dd if=tempfile of=/dev/null bs=1M count=1024 echo 3 /proc/sys/vm/drop_caches; dd if=tempfileof=/dev/null bs=1M count=1024 4. Using phoronix benchmarks - stream / ramspeed / compress-7zip I was curious to measure the magnitude of difference between HDD - SSD. I would expect significant differences between SSD - PCI-E Flash. I’ve included some metrics from some previous runs vs. different types of SSDs (OWC Mercury Extreme 6G which is our standard SSD, an Intel S3700 SSD, a Samsung SSD 840 PRO) vs. some standard HDD from Western Digital and HGST. I put in a req for a 960Gb Mercury Excelsior PCI-E SSD which hasn’t yet materialized ... Thanks, M. Mel Llaguno • Staff Engineer – Team Lead Office: +1.403.264.9717 x310 www.coverity.com http://www.coverity.com/ • Twitter: @coverity Coverity by Synopsys On 3/31/15, 1:52 PM, Josh Berkus j...@agliodbs.com wrote: All, I currently have access to a matched pair of 20-core, 128GB RAM servers with SSD-PCI storage, for about 2 weeks before they go into production. Are there any performance tests people would like to see me run on these? Otherwise, I'll just do some pgbench and DVDStore. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list ( pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org ) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] Some performance testing?
All, I currently have access to a matched pair of 20-core, 128GB RAM servers with SSD-PCI storage, for about 2 weeks before they go into production. Are there any performance tests people would like to see me run on these? Otherwise, I'll just do some pgbench and DVDStore. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Some performance testing?
It would be interesting to get raw performance benchmarks in addition to PG specific benchmarks. I’ve been measuring raw I/O performance of a few of our systems and run the following tests as well: 1. 10 runs of bonnie++ 2. 5 runs of hdparm -Tt 3. Using a temp file created on the SSD, dd if=tempfile of=/dev/null bs=1M count=1024 echo 3 /proc/sys/vm/drop_caches; dd if=tempfileof=/dev/null bs=1M count=1024 4. Using phoronix benchmarks - stream / ramspeed / compress-7zip I was curious to measure the magnitude of difference between HDD - SSD. I would expect significant differences between SSD - PCI-E Flash. I’ve included some metrics from some previous runs vs. different types of SSDs (OWC Mercury Extreme 6G which is our standard SSD, an Intel S3700 SSD, a Samsung SSD 840 PRO) vs. some standard HDD from Western Digital and HGST. I put in a req for a 960Gb Mercury Excelsior PCI-E SSD which hasn’t yet materialized ... Thanks, M. Mel Llaguno • Staff Engineer – Team Lead Office: +1.403.264.9717 x310 www.coverity.com http://www.coverity.com/ • Twitter: @coverity Coverity by Synopsys On 3/31/15, 1:52 PM, Josh Berkus j...@agliodbs.com wrote: All, I currently have access to a matched pair of 20-core, 128GB RAM servers with SSD-PCI storage, for about 2 weeks before they go into production. Are there any performance tests people would like to see me run on these? Otherwise, I'll just do some pgbench and DVDStore. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance System Benchmarks.xlsx Description: System Benchmarks.xlsx -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
