[Linux-cluster] GFS create file performance

[C. Handel]

Is your session data valuable? what happens if you loose it? For web
application this normally means, that users need to login again. How
big is your data? What is the read/write ratio?

You could go for a memcache. Try two dedicated machines with lots of
memory. Write your session storage to always write to both and read
from one. Handle failure in software. Unbeatable performance. will
saturate gigbit links with ease.

In case one node fails nothing happens. The one coming back up needs
to copy all content from the other before serving data.

Or look in a nosql (couchdb, jackrabbit) solution if you need storing on disk.

Greetings
   Christoph


>> This is in addition to the block for the inode itself, and if selinux or
>> acls are in use, additional blocks may be allocated to contain their
>> xattrs as well.
>
> Good to know.  We'll likely disable selinux for a future round of testing.
>
> We're very aware that we're starting to push the envelope of GFS and clustered filesystems a bit.  Armed with this understanding, we might try to revamp our session storage so we don't need to create as many files.  One possibility is appending new information to existing files in lieu of creating new files for each session.
>
> The high performance of mainstream filesystems like ext3 (without sync) can delude us into thinking file creation is cheap, or essentially free.  In the end we're still limited by I/O.
>
> We can also take a more critical look at our block storage itself.  Either FiberChannel or solid-state storage should help to reduce latency.  High capacity drives are not required for our application, but latency and throughput are critical.
>
> (I'm aware too there are non-filesystem approaches to solving our problem, but if we abandon the cluster fs too quickly I won't have learned what its true limits are.)
>
> -Jeff