Le Wednesday 02 July 2008, Jonah H. Harris a écrit :
> On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <jwbaker@gmail.com> 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@enterprisedb.com
> 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
