From: Jim Starkey Date: December 9 2008 6:23pm Subject: Re: Memory, Falcon, and $$$ List-Archive: http://lists.mysql.com/falcon/286 Message-Id: <493EB7A1.4080501@nimbusdb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip Stoev wrote: > Hello. > > I totally understand your argument, however you are buying bulk > generic memory. You also bought whitebox machines when you bought the > servers themselves for less than $2000 each. Unfortunately the > economics is a bit different in the corporate world. People still have > very expensive 80gig SCSI RAID arrays out there. Nope. The servers (case and motherboards) are Supermicro (http://www.nytimes.com/2008/11/24/technology/business-computing/24micro.html?partner=rss&emc=rss), who also peddle machines to the likes of EBay and Yahoo. Chris's machine, an Intel supplied prototype, was also a Supermicro machine. > > The cheapest Xeon server Sun sells retails for $3,435.28 with 4 GB of > memory, about twice as much as a simularily-configured whitebox > server. The next 8GB of memory costs USD $600 (six hundred united > states currency). And if Sun could find more customers to pay $600 for commodity memory available on the open market for $84, Sun stock price would be a great deal higher. There's a name for companies that believe customers will a lot extra for private labeled commodities: Extinct. > > I totally agree that we should not make any sacrifices in order to > have Falcon perform well in 32Mb. However, I am not sure if any of > those outcomes are acceptable: > * Refusing to execute a query that Innodb would execute and error with > an out-of-memory condition; > * Experience a performance degradation worse than one that would > happen due to OS trashing; > * Crash or unable to recover; Mostly, I agree. If InnoDB cheats with an "implicit" commit, that's a different story. Falcon is an engine designed for "modern on-line applications". It shouldn't sacrifice on-line performance to handle batch operations that $50 worth of memory would fix. I would be happy to trade-off mass update performance for on-line performance any day -- on-line means there's a human waiting. We need to batch operations, of course, but we don't need to lose sleep over their relative performance. > > Philip Stoev > > ----- Original Message ----- From: "Jim Starkey" > To: "FalconDev" > Sent: Tuesday, December 09, 2008 7:09 PM > Subject: Memory, Falcon, and $$$ > > >> I took delivery of 40 GB of ECC memory for my cloud. Excluding tax, >> the total cost was $420 plus tax, or $10.50 per GB (shipping was free). >> >> This is a question that everyone should ask himself or herself >> regularly: Would our users be willing to spend an extra $50 per >> server for a faster database? How can we use memory better to >> improve performance. And, does it make sense to sacrifice adequate >> memory performance to work in low memory situations? >> >> >> -- >> Jim Starkey >> President, NimbusDB, Inc. >> 978 526-1376 >> >> >> -- >> Falcon Storage Engine Mailing List >> For list archives: http://lists.mysql.com/falcon >> To unsubscribe: http://lists.mysql.com/falcon?unsub=philip.stoev@stripped >> >> > > -- Jim Starkey President, NimbusDB, Inc. 978 526-1376