david@xxxxxxx wrote: > On Fri, 23 Jan 2009, Luke Lonergan wrote: > >> Why not simply plug your server into a UPS and get 10-20x the >> performance using the same approach (with OS IO cache)? >> >> In fact, with the server it's more robust, as you don't have to >> transit several intervening physical devices to get to the RAM. >> >> If you want a file interface, declare a RAMDISK. >> >> Cheaper/faster/improved reliability. > > you can also disable fsync to not wait for your disks if you trust your > system to never go down. personally I don't trust any system to not go > down. > > if you have a system crash or reboot your RAMDISK will loose it's > content, this device won't. > > also you are limited to how many DIMMS you can put on your motherboard > (for the dual-socket systems I am buying nowdays, I'm limited to 32G of > ram) going to a different motherboard that can support additional ram > can be quite expensive. > > this isn't for everyone, but for people who need the performance, data > reliability, this looks like a very interesting option. > > David Lang > >> - Luke >> >> ----- Original Message ----- >> From: pgsql-performance-owner@xxxxxxxxxxxxxx >> <pgsql-performance-owner@xxxxxxxxxxxxxx> >> To: Glyn Astill <glynastill@xxxxxxxxxxx> >> Cc: pgsql-performance@xxxxxxxxxxxxxx <pgsql-performance@xxxxxxxxxxxxxx> >> Sent: Fri Jan 23 04:39:07 2009 >> Subject: Re: SSD performance >> >> On Fri, 23 Jan 2009, Glyn Astill wrote: >> >>>> I spotted a new interesting SSD review. it's a $379 >>>> 5.25" drive bay device that holds up to 8 DDR2 DIMMS >>>> (up to 8G per DIMM) and appears to the system as a SATA >>>> drive (or a pair of SATA drives that you can RAID-0 to get >>>> past the 300MB/s SATA bottleneck) >>>> >>> >>> Sounds very similar to the Gigabyte iRam drives of a few years ago >>> >>> http://en.wikipedia.org/wiki/I-RAM >> >> similar concept, but there are some significant differences >> >> the iRam was limited to 4G, used DDR ram, and used a PCI slot for power >> (which can be in >> short supply nowdays) >> >> this new drive can go to 64G, uses DDR2 ram (cheaper than DDR nowdays), >> gets powered like a normal SATA drive, can use two SATA channels (to be >> able to get past the throughput limits of a single SATA interface), and >> has a CF card slot to backup the data to if the system powers down. >> >> plus the performance appears to be significantly better (even without >> using the second SATA interface) >> >> David Lang >> >> >> -- >> Sent via pgsql-performance mailing list >> (pgsql-performance@xxxxxxxxxxxxxx) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-performance >> > Can I call a time out here? :) There are "always" going to be memory hierarchies -- registers on the processors, multiple levels of caches, RAM used for programs / data / I-O caches, and non-volatile rotating magnetic storage. And there are "always" going to be new hardware technologies cropping up at various levels in the hierarchy. There are always going to be cost / reliability / performance trade-offs, leading to "interesting" though perhaps not really business-relevant "optimizations". The equations are there for anyone to use should they want to optimize for a given workload at a given point in time with given business / service level constraints. See http://www.amazon.com/Storage-Network-Performance-Analysis-Huseyin/dp/076451685X for all the details. I question, however, whether there's much point in seeking an optimum. As was noted long ago by Nobel laureate Herbert Simon, in actual fact managers / businesses rarely optimize. Instead, they satisfice. They do what is "good enough", not what is best. And my own personal opinion in the current context -- PostgreSQL running on an open-source operating system -- is that * large-capacity inexpensive rotating disks, * a hardware RAID controller containing a battery-backed cache, * as much RAM as one can afford and the chassis will hold, and * enough cores to keep the workload from becoming processor-bound are good enough. And given that, a moderate amount of software tweaking and balancing will get you close to a local optimum. -- M. Edward (Ed) Borasky I've never met a happy clam. In fact, most of them were pretty steamed. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
