> 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
> 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(at)postgresql(dot)org
>> To: Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>
>> Cc: pgsql-performance(at)postgresql(dot)org <pgsql-performance(at)postgresql(dot)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
>> 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
>> To make changes to your subscription:
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
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.
In response to
pgsql-performance by date
|Next:||From: Joshua D. Drake||Date: 2009-01-23 17:30:07|
|Subject: Re: SSD performance|
|Previous:||From: Ted Allen||Date: 2009-01-23 15:56:44|
|Subject: More Troubles Dumping a Very Large Table|