Now you are telling me that somehow you have code that makes your database stuff its journal on your RAID controller's cache. Cool, mind sharing it with the rest of us?
fsync(handle); If we -dont- do this after processing each event, and the system fails catastrophically, a thousand or so events (a couple seconds worth of realtime data) are lost in the operating systems buffering. I feel like I'm repeating myself.
If the aggregate queues are up to 10GB, I really wonder wonder how much faster your hardware raid makes things unless of course your cache is much larger than 2GB. Just on the basis of the inadequate size of your cache I would give software raid + RAM card the benefit of the doubt.
the combined queue files average a few to 10GB total under a normal workload. if a downstream subscriber backs up, they can grow quite a bit, up to an arbitrarily set 100GB limit.. its these queue files that we are flushing with fsync(). each fsync is writing a few K to a few 100K bytes out, one 'event' worth of data which has been appended to one or another of the queues, from where it will eventually be forwarded to some number of downstream subscribers. What we're calling a journal is just the index/state of these queues, stored in a couple seperate very small files, that also get fsync() on writes, it has NOTHING to do with the file system.
to store these queues on a ramcard, we'd need 100GB to handle the backup cases, which, I hope you can agree, is ludicrious.
Throughput under test load (incoming streams free running as fast as they can be processed)
no fsync - 1000 events/second fsync w/ direct connect disk - 50-80 events/second fsync w/ hardware writeback cached raid - 800/second seems like a clear win to me. _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
