Feizhou wrote:
not so. I used to run boxes that handled 600 to 1000 smtp connections each. Creating and deleting thousands of small files was the environment I worked in.
and if the power failed in the middle of this, how many messages were lost?
I must say that the 3ware cards on those boxes that had them were not 955x series and therefore had no cache. Perhaps things would have been different if it were 955x cards in there but at that time, the 9xxx 3ware cards were not even out yet.
We typically use 15000 rpm scsi or fiberchannel storage for our databases, not SATA.
Since you have clearly pointed out the performance benefit really comes from the cache (if you have enough) on the board I do not see why using software raid and a battery-backed RAM card like the umem or even the gigabyte i-ram for the journal of the filesystem will be any less slow if at all.
its not the file system journal I'm talking about, its an application specific journal file, which contains the indicies and state of the queue files, of which there's a very large number constantly being written. We need to flush the queue files AND the journal files for it to be safe. These run around 10GB total as I understand it (not each flush, but the aggregate queues can be this big).
if the server has a writeback enabled controller like a HP Smart Array 5i/532, it all works great. if it doesn't, it all grinds to a halt. quite simple, really. We have absolutely no desire to start architecting around 3rd party ram/battery disks, they won't be supported by our production system vendors, and they will make what is currently a fairly simple and robust system a lot more convoluted..
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
