Subject | RE: [Firebird-Architect] Good open source database feature comparison? |
---|---|
Author | Steve Summers |
Post date | 2004-02-14T14:27:50Z |
The problem with using a RAM disk is you have to load it from a real disk,
and save it back when your done. If it's a read-only database, that might
make sense. But otherwise, it's a big risk to the data. The alternative is
caching, which is pretty effective too.
We run a 650MB database on a machine with 1GB of RAM. Firebird 1.5 is the
only thing running on the machine. Within a few user queries, the entire
database is cached. The only disk activity is for writes. Performance is so
fast that it does a GBAK in just 11 seconds. (!)
Of course, this database is growing by 20-50MB per month (it has a LOT of
RTF blobs with big screen shots) so I'm expecting this to outgrow the 1G of
memory in 3-6 months. When that happens, performance is going to drop quite
a bit. We can delay the inevitable with another GB of RAM, but the bottom
line is in the real world, most databases are larger than the computer's RAM
capacity, so the "lots o' RAM trick" doesn't eliminate the need for clever,
well designed code.
-----Original Message-----
From: Tiberiu Atudorei [mailto:tiberiu.atudorei@...]
Sent: Saturday, February 14, 2004 04:33am
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Good open source database feature
comparison?
Quoting Jim Starkey <jas@...>:
cheap 200 MB RAM-disk then consider the big-iron solution of SAN: a
multi-gigabyte storage solution with a 2 Gigabyte/s bandwidth (now you
get it for a price between 10k to 20k USD, depending on vendor).
The problem remains: if you can forget about "HDD slow - memory fast" and
you move to another level (where the speed of memory and the speed of
storage
are on the same order of magnitude, be it in a RAM disk or SAN) what changes
can be done (either in code or in database configuration) in order to get
a performance boost?
Right now my development system at home has 1GB RAM. For a production system
it is not unusual to have 2 GB or even 4 GB. For a small database
(500MB-1GB)
would you consider using it in a RAM-disk?
Tiberiu
Yahoo! Groups Links
and save it back when your done. If it's a read-only database, that might
make sense. But otherwise, it's a big risk to the data. The alternative is
caching, which is pretty effective too.
We run a 650MB database on a machine with 1GB of RAM. Firebird 1.5 is the
only thing running on the machine. Within a few user queries, the entire
database is cached. The only disk activity is for writes. Performance is so
fast that it does a GBAK in just 11 seconds. (!)
Of course, this database is growing by 20-50MB per month (it has a LOT of
RTF blobs with big screen shots) so I'm expecting this to outgrow the 1G of
memory in 3-6 months. When that happens, performance is going to drop quite
a bit. We can delay the inevitable with another GB of RAM, but the bottom
line is in the real world, most databases are larger than the computer's RAM
capacity, so the "lots o' RAM trick" doesn't eliminate the need for clever,
well designed code.
-----Original Message-----
From: Tiberiu Atudorei [mailto:tiberiu.atudorei@...]
Sent: Saturday, February 14, 2004 04:33am
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Good open source database feature
comparison?
Quoting Jim Starkey <jas@...>:
> Cooking benchmarks doesn't impress anyone. And nobody selects aOK, forget about benchmarks. If you don't like the trick to use my
> database on performance unless it's a weirdo application with unusually
> requirements. Being a slug doesn't do you any good, but presenting a
> benchmark with the consistency of overdone pot roast doesn't do your
> credibility any good, either.
cheap 200 MB RAM-disk then consider the big-iron solution of SAN: a
multi-gigabyte storage solution with a 2 Gigabyte/s bandwidth (now you
get it for a price between 10k to 20k USD, depending on vendor).
The problem remains: if you can forget about "HDD slow - memory fast" and
you move to another level (where the speed of memory and the speed of
storage
are on the same order of magnitude, be it in a RAM disk or SAN) what changes
can be done (either in code or in database configuration) in order to get
a performance boost?
Right now my development system at home has 1GB RAM. For a production system
it is not unusual to have 2 GB or even 4 GB. For a small database
(500MB-1GB)
would you consider using it in a RAM-disk?
Tiberiu
Yahoo! Groups Links