Re: [PERFORM] concurrent IO in postgres?
Typically my problem is that the large queries are simply CPU bound.. do you have a sar/top output that you see. I'm currently setting up two FusionIO DUO @640GB in a lvm stripe to do some testing with, I will publish the results after I'm done. If anyone has some tests/suggestions they would like to see done please let me know. - John -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Przemek Wozniak Sent: Thursday, December 23, 2010 11:38 AM To: pgsql-performance@postgresql.org Subject: [PERFORM] concurrent IO in postgres? When testing the IO performance of ioSAN storage device from FusionIO (650GB MLC version) one of the things I tried is a set of IO intensive operations in Postgres: bulk data loads, updates, and queries calling for random IO. So far I cannot make Postgres take advantage of this tremendous IO capacity. I can squeeze a factor of a few here and there when caching cannot be utilized, but this hardware can do a lot more. Low level testing with fio shows on average x10 speedups over disk for sequential IO and x500-800 for random IO. With enough threads I can get IOPS in the 100-200K range and 1-1.5GB/s bandwidth, basically what's advertised. But not with Postgres. Is this because the Postgres backend is essentially single threaded and in general does not perform asynchronous IO, or I'm missing something? I found out that the effective_io_concurrency parameter only takes effect for bitmap index scans. Also, is there any work going on to allow concurrent IO in the backend and adapt Postgres to the capabilities of Flash? Will appreciate any comments, experiences, etc. Przemek Wozniak -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] Index Bloat - how to tell?
How can you tell when your indexes are starting to get bloated and when you need to rebuild them. I haven't seen a quick way to tell and not sure if it's being tracked. ___ | John W. Strange | Investment Bank | Global Commodities Technology | J.P. Morgan | 700 Louisiana, 11th Floor | T: 713-236-4122 | C: 281-744-6476 | F: 713 236- | john.w.stra...@jpmchase.com | jpmorgan.com This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- 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] Hardware recommendations
If you are worried about wearing out the SSD's long term get a larger SSD and create the partition smaller than the disk, this will reduce the write amplification and extend the life of the drive. TRIM support also helps lower write amplification issues by not requiring as many pages to do the writes, and improve performance as well! As a test I bought 4 cheap 40GB drives in a raid0 software stripe, I have run it for almost a year now with a lot of random IO. I portioned them as 30GB drives, leaving an extra 25% spare area to reduce the write amplification, I can still get over 600MB/sec on these for a whopping cost of $400 and a little of my time. SSD's can be very useful, but you have to be aware of the shortcomings and how to overcome them. - John -Original Message- From: Marti Raudsepp [mailto:ma...@juffo.org] Sent: Thursday, December 09, 2010 6:09 AM To: Scott Marlowe Cc: Benjamin Krajmalnik; John W Strange; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Hardware recommendations On Thu, Dec 9, 2010 at 04:28, Scott Marlowe wrote: > On Wed, Dec 8, 2010 at 5:03 PM, Benjamin Krajmalnik > wrote: >> My biggest concern with SSD drives is their life expectancy, > > Generally that's not a big issue, especially as the SSDs get larger. > Being able to survive a power loss without corruption is more of an > issue, so if you go SSD get ones with a supercapacitor that can write > out the data before power down. I agree with Benjamin here. Even if you put multiple SSD drives into a RAID array, all the drives get approximately the same write load and thus will likely wear out and fail at the same time! > As for the Areca controllers, I haven't tested them with the latest > drivers or firmware, but we would routinely get 180 to 460 days of > uptime between lockups That sucks! But does a BBU even help with SSDs? The flash eraseblock is larger than the RAID cache unit size anyway, so as far as I can tell, it might not save you in the case of a power loss. Any thoughts whether software RAID on SSD is a good idea? Regards, Marti This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- 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] Hardware recommendations
Ben, It would help if you could tell us a bit more about the read/write mix and transaction requirements. *IF* you are heavy writes I would suggest moving off the RAID1 configuration to a RAID10 setup. I would highly suggest looking at SLC based solid state drives or if your budget has legs, look at fusionIO drives. We currently have several setups with two FusionIO Duo cards that produce > 2GB second reads, and over 1GB/sec writes. They are pricey but, long term cheaper for me than putting SAN in place that can meet that sort of performance. It all really depends on your workload: http://www.fusionio.com/products/iodrive/ - BEST in slot currently IMHO. http://www.intel.com/design/flash/nand/extreme/index.htm?wapkw=(X25-E) - not a bad alternative. There are other SSD controllers on the market but I have experience with both so I can recommend both as well. - John -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Benjamin Krajmalnik Sent: Wednesday, December 08, 2010 5:04 PM To: pgsql-performance@postgresql.org Subject: [PERFORM] Hardware recommendations I need to build a new high performance server to replace our current production database server. The current server is a SuperMicro 1U with 2 RAID-1 containers (one for data, one for log, SAS - data is 600GB, Logs 144GB), 16GB of RAM, running 2 quad core processors (E5405 @ 2GHz), Adaptec 5405 Controller with BBU. I am already having serious I/O bottlenecks with iostat -x showing extended periods where the disk subsystem on the data partition (the one with all the random i/o) at over 85% busy. The system is running FreeBSD 7.2 amd64 and PostgreSQL 8.4.4 on amd64-portbld-freebsd7.2, compiled by GCC cc (GCC) 4.2.1 20070719 [FreeBSD], 64-bit. Currently I have about 4GB of shared memory allocated to PostgreSQL. Database is currently about 80GB, with about 60GB being in partitioned tables which get rotated nightly to purge old data (sort of like a circular buffer of historic data). I was looking at one of the machines which Aberdeen has (the X438), and was planning on something along the lines of 96GB RAM with 16 SAS drives (15K). If I create a RAID 10 (stripe of mirrors), leaving 2 hot spares, should I still place the logs in a separate RAID-1 mirror, or can they be left on the same RAID-10 container? On the processor front, are there advantages to going to X series processors as opposed to the E series (especially since I am I/O bound)? Is anyone running this type of hardware, specially on FreeBSD? Any opinions, especially concerning the Areca controllers which they use? The new box would ideally be built with the latest released version of FreeBSD, PG 9.x. Also, is anyone running the 8.x series of FreeBSD with PG 9 in a high throughput production environment? I will be upgrading one of our test servers in one week to this same configuration to test out, but just wanted to make sure there aren't any caveats others have experienced, especially as it pertains with the autovacuum not launching worker processes which I have experienced. Best regards, Benjamin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes
