Re: [PERFORM] Linux: more cores = less concurrency.
On 04/11/2011 02:32 PM, Scott Marlowe wrote: On Mon, Apr 11, 2011 at 12:12 PM, Joshua D. Drakej...@commandprompt.com wrote: On Mon, 11 Apr 2011 13:09:15 -0500, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Glyn Astillglynast...@yahoo.co.uk wrote: The new server uses 4 x 8 core Xeon X7550 CPUs at 2Ghz Which has hyperthreading. our current servers are 2 x 4 core Xeon E5320 CPUs at 2Ghz. Which doesn't have hyperthreading. PostgreSQL often performs worse with hyperthreading than without. Have you turned HT off on your new machine? If not, I would start there. Anyone know the reason for that? And then make sure you aren't running CFQ. JD This++ Also if you're running a good hardware RAID controller, jsut go to NOOP -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com
Re: [PERFORM] How to fast the REINDEX
On 03/31/2010 11:11 PM, Craig Ringer wrote: Jaime Casanova wrote: On Wed, Mar 31, 2010 at 5:33 PM, raghavendra t raagavendra@gmail.com wrote: Why are you doing that? Our table face lot of updates and deletes in a day, so we prefer reindex to update the indexes as well overcome with a corrupted index. do you have a corrupted index? if not, there is nothing to do... REINDEX is not a mantenance task on postgres Actually, if your free_space_map (pre 8.4) isn't up to keeping track of bloat, or autovac isn't running enough, you're likely to get bloat of indexes as well as tables that may need VACUUM FULL + REINDEX to properly clean up. It's probably better to fix your fsm/autovac settings then CLUSTER the table so it doesn't happen again, though. -- Craig Ringer So am I to understand I don't need to do daily reindexing as a maintenance measure with 8.3.7 on FreeBSD. -- Stephen Clark NetWolves Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com www.netwolves.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] Abnormal performance difference between Postgres and MySQL
Kevin Grittner wrote: Farhan Husain russ...@gmail.com wrote: Thanks a lot Scott! I think that was the problem. I just changed the default statistics target to 50 and ran explain. The plan changed and I ran explain analyze. Now it takes a fraction of a second! Yeah, the default of 10 has been too low. In 8.4 it is being raised to 100. Thanks to all of you who wanted to help me. I would be happy if someone does me one last favor. I want to know how these query plans are generated and how the parameters you suggested to change affects it. If there is any article, paper or book on it please give me the name or url. In terms of tuning in general, you might start with these: http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server http://www.postgresql.org/docs/8.3/interactive/runtime-config-query.html To understand the mechanics of the optimizer you might be best off downloading the source code and reading through the README files and comments in the source code. -Kevin Hello List, Can this be set in the postgresql.conf file? default_statistics_target = 50 Thanks, Steve -- 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] Perc 3 DC
Glyn Astill wrote: --- On Sat, 22/11/08, Scott Marlowe [EMAIL PROTECTED] wrote: You really have two choices. First is to try and use it as a plain SCSI card, maybe with caching turned on, and do the raid in software. Second is to cut it into pieces and make jewelry out of it. Haha, I'm not really into jewelry, although I had thought of smacking it into a pile of dust with a lump hammer, that's much more my thing. Anything before the Perc 6 series is seriously brain damaged, and the Perc6 brings the dell raid array line squarly in line with a 5 year old LSI megaraid, give or take. And that's being generous. Well this card thinks it's a 5 year old lsi megaraid. I've got a pile of perc5i megaraid paperweights on my desk at work, so this was kinda expected really. I've tried writeback and write through modes, tried changing cache flush times, disabled and enabled multiple PCI delayed transactions, all seem to have little effect. Yeah, it's like trying to performance tune a yugo. Did I mention I drive a yugo? Finally I decided to wave goodbye to Dell's firmware. LSI has it down as a MegaRAID 493 elite 1600, so I flashed it with their latest firmware. Doesn't seem to have helped either though. Does it have a battery backup module? Often you can't really turn on write-back without one. That would certainly slow things down. But you should certainly expect 20 M/s on a modern RAID controller writing out to a 4 disk RAID10 Yeah the battery's on it, that and the 128Mb is really the only reason I thought I'd give it a whirl. Is the battery functioning? We found that the unit had to be on and charged before write back caching would work. -- 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] Intel's X25-M SSD
Scott Carey wrote: A fantastic review on this issue appeared in July: http://www.alternativerecursion.info/?p=106 And then the same tests on a RiData SSD show that they are the same drive with the same characteristics: http://www.alternativerecursion.info/?p=276 Most blamed it on MLC being slow to write compared to SLC. Technically, it is slower, but not by a whole lot -- we're talking a low level difference of tens of microseconds. A 250ms latency indicates an issue with the controller chip. SLC and MLC share similar overall performance characteristics at the millisecond level. The truth is that MLC designs were low cost designs without a lot of investment in the controller chip. The SLC designs were higher cost designs that focused early on on making smarter and more expensive controllers. SLC will always have an advantage, but it isn't going to be by several orders of magnitude like it was before Intel's drive appeared. Its going to be by factors of ~2 to 4 on random writes in the long run. However, for all flash based SSD devices, there are design tradeoffs to make. Maximizing writes sacrifices reads, maximizing random access performance reduces streaming performance and capacity. We'll have a variety of devices with varying characteristics optimal for different tasks. On Tue, Sep 23, 2008 at 8:24 PM, Bruce Momjian [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Greg Smith wrote: On Mon, 8 Sep 2008, Merlin Moncure wrote: What's interesting about the X25 is that they managed to pull the numbers they got out of a MLC flash product. They managed this with a DRAM buffer and the custom controller. I finally found a good analysis of what's wrong with most of the cheap MLC drives: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403p=7 http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403p=7 240ms random write latency...wow, no wonder I keep hearing so many reports of cheap SSD just performing miserably. JMicron is one of those companies I really avoid, never seen a design from them that wasn't cheap junk. Shame their awful part is in so many of the MLC flash products. I am surprised it too so long to identify the problem. -- Bruce Momjian [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org mailto:pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance Anybody know of any tests on systems that have specific filesystems for flash devices? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
