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 -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
