Le Wednesday 02 July 2008, Jonah H. Harris a écrit : > On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <jwbaker@xxxxxxxxx> wrote: > > Basically the ioDrive is smoking the RAID. The only real problem with > > this benchmark is that the machine became CPU-limited rather quickly. > > That's traditionally the problem with everything being in memory. > Unless the database algorithms are designed to exploit L1/L2 cache and > RAM, which is not the case for a disk-based DBMS, you generally lose > some concurrency due to the additional CPU overhead of playing only > with memory. This is generally acceptable if you're going to trade > off higher concurrency for faster service times. And, it isn't only > evidenced in single systems where a disk-based DBMS is 100% cached, > but also in most shared-memory clustering architectures. My experience is that using an IRAM for replication (on the slave) is very good. I am unfortunely unable to provide any numbers or benchs :/ (I'll try to get some but it won't be easy) I would probably use some flash/memory disk when Postgresql get the warm stand-by at transaction level (and is up for readonly query)... > > In most cases, when you're waiting on disk I/O, you can generally > support higher concurrency because the OS can utilize the CPU's free > cycles (during the wait) to handle other users. In short, sometimes, > disk I/O is a good thing; it just depends on what you need. > > -- > Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 > EnterpriseDB Corporation | fax: 732.331.1301 > 499 Thornall Street, 2nd Floor | jonah.harris@xxxxxxxxxxxxxxxx > Edison, NJ 08837 | http://www.enterprisedb.com/ -- Cédric Villemain Administrateur de Base de Données Cel: +33 (0)6 74 15 56 53 http://dalibo.com - http://dalibo.org
Attachment:
signature.asc
Description: This is a digitally signed message part.
