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.
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/