On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <[EMAIL PROTECTED]> 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. 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 | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
