[OSM-dev] Alternative tile webserver needed?

[Nick Hill]

Hello Robert

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.
> http://en.wikipedia.org/wiki/TUX_web_server
> 
> Robert (Jamie) Munro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGMioXz+aYVHdncI0RApnLAJwMZJerfvsnGAOtjVNQ9XIX1+YyzQCglOQ3
> cvbZW2IYyNy2cmAnXyWRU0k=
> =xeEX
> -----END PGP SIGNATURE-----
>