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