NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
The one thing which I'm more concerned about which is why I changed over is the amount of I/O that occurs on that queue file. Also the machines which are doing this aren't just relays, they are processing the data feeds. You are right though, the cost is an issue, but i'd rather go for the SAS drives instead of a SATA, IMHO. But on my systems here at COD, the issues which I started running into was disk I/O and system load and how much of a backup that occured, especially when people are accessing site pages on the same RAID array. Anyways memory isn't an issue when it comes to the new servers which we are purchasing which are going to be 32 gig a piece. Side note you are right on being a relay needing some type of fallback on data, But other than cost and the NEED to having a fallback I don't see much of an issue. Then again I remake my queue anyways each time I restart the machine because the only time my servers have gone down is from a crash and the queue was corrupt anyways. Just my 2 cents. -dave (((SNIP))) True, but we should be comparing them to system memory, not hard drives. 8 GB of system memory for one of my servers is selling for ~$600 right now. I can buy a RiDATA 32 GB SATA SSD for ~$680, which is ~ 1/4 the price/GB for my server. Depending on your server and its memory costs, SSD could be more expensive, but SSD's are advancing rapidly and I expect costs to drop quickly. ------------------------------------------------------------------------------- David B. Bukowski |email (work): bukowski@xxxxxxxxxxxxx Network Analyst III |email (personal): davebb@xxxxxxxxxxxxx College of Dupage |webpage: http://www.cshschess.org/davebb/ Glen Ellyn, Illinois |pager: (708) 241-7655 http://www.cod.edu/ |work phone: (630) 942-2591 -------------------------------------------------------------------------------
ldm-users
archives: