[OSM-dev] Alternative tile webserver needed?
nick at nickhill.co.uk
Fri Apr 27 18:13:32 BST 2007
Before we deployed the T at H drive, I spent some time testing different file systems.
I have written a C program which takes a list of files and file sizes, creates a
directory structure of files of the given sizes. I fed a list of 20 million T at H
file names and sizes into differing file systems. I tested write, read and
delete times for all files. I am happy to share it along with a file list
representing T at H tiles.
I tested reiserfs, reiserfs without tail, ext2 ext3 and JFS.
Most of the drive time is not spent transferring data, but is spent seeking each
file being only a few hundred bytes or a few k. The drive will take 25
microseconds to read/write 2k, but may take several 8ms seeks to get to that 2k.
I didn't realise you could use reiserfs without journaling. Can you point me to
info about that?
Robert (Jamie) Munro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Dirk-Lüder Kreie wrote:
>> Nick Hill schrieb:
>>>> Hello Sebastien
>>>> The tiles drive is 160Gb and is currently running at 80% space usage and rising.
>> ReiserFS is said to slow down considerably if it gets past 85% full.
>>>> The problem is simply that the tile generation process is taking every available
>>>> second of disk I/O. Backing off the generator process will provide enough I/O
>>>> time for the tiles to be read and more-or-less solve the problem.
> It seems unlikely that network upload bandwidth would be greater than
> disk I/O bandwidth. Therefore the problem is probably not absolute disk
> I/O, but how efficiently it is being used. Perhaps we should look at
> tuning the ReiserFS options - disabling journalling, for example, or we
> could try other filesystems. If the problem is tile uploads, the new
> exponential backoff features of T at H clients should help a bit.
> Another thought I had is try try serving the tiles with TUX, the kernel
> web server, which is extremely fast and efficient - it never makes
> multiple copies of the file (or parts of the file) in RAM, it just tells
> the network card to get the data from the disc buffer directly. This may
> free up apache processes and RAM and make things more responsive.
> Disclaimer: I haven't ever tried to run TUX myself - I don't know how
> well it works in practise.
> Robert (Jamie) Munro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the dev