Re: SSD performance - Mailing list pgsql-performance

david@lang.hm 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@postgresql.org
>> <pgsql-performance-owner@postgresql.org>
>> To: Glyn Astill <glynastill@yahoo.co.uk>
>> Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
>> Sent: Fri Jan 23 04:39:07 2009
>> Subject: Re: [PERFORM] 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@postgresql.org)
>> 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.