On Tue, Nov 20, 2007 at 09:56:37AM -0800, David Lang wrote:
> for cyrus you should have the same sort of requirements that you would have for
> a database server, including the fact that without a battery-backed disk cache
> (or solid state drive) to handle your updates, you end up being throttled by
> your disk rotation rate (you can only do a single fsync write per rotation, and
> that good only if you don't have to seek), RAID 5/6 arrays are even worse, as
> almost all systems will require a read of the entire stripe before writing a
> single block (and it's parity block) back out, and since the stripe is
> frequently larger then the OS readahead, the OS throws much of the data away
> immediatly.
You're mixing things up. Readahead has absolutely zero influence on when
data is evicted from the cache.
> if we can identify the files that are the bottlenecks it would be very
> interesting to see the result of puttng them on a solid-state drive.
On Linux you can use blktrace to log every I/O operations, you could use
it to catch I/O ops that take longer than expected. It works below the
files system level however so you need to use something like debugfs to
translate the sector numbers back to inodes/file names.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
