RE: [Exadata] How do you use FlashDisk ?

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <greg@xxxxxxxxxxxxxxxxxx>, <jkstill@xxxxxxxxx>
  • Date: Sun, 20 Mar 2011 09:09:50 -0400

The next sentence:

"Testing has shown that moving redo logs on to EFDs results in a low
percentage of improvement."

The article, as with your question, is indeed about guns and butter choices
in the general case. That two adjacent sentences contradict one another is
also not my point. I think they meant it is a misconception that moving
online redo logs will benefit throughput more than moving some other things.
That they will benefit is clear, as they document in the very next sentence.
The question is how much, and I really wish they had shared what a "low"
percentage is. The last time I did comprehensive testing it was about 7%
increased throughput when log buffer flushes were only driven by log 1/3
full or timeout (not small commits and not using a silly small buffer to
magnify the results). The percentage improvement should be marginally better
if you have frequent small commits. Any you shouldn't use a silly small log
buffer at all. A sufficient size log buffer is the primary reason the
percentage improvement is "small."

If you have a lot of acreage dedicated to online redo logs to get sufficient
IO/s to simultaneously support flushing the redo buffer (as on every commit,
which if the redo devices are mixed with other storage may mean a seek on
each and every commit [though some commits, to be fair, may be batched]) and
reading to redo log to the archives, then it may be an economically correct
decision to put online redo logs on electronic storage.

You need an actual test of your workload and pricing out the amount of
online redo log you plan to have versus the hard disk saved in terms of
spindle count, not mere acreage, to make this determination. And if you have
big update jobs that barely fit (or miss by a little) in your "batch"
window, a 7% improvement might be a grand thing for a small price. The value
of keeping "batch" operations out of your morning shift arrival logon window
only awaits a little Method-R analysis of your important interactive jobs
with and without competition from the tail end of batch to help you access
whether this should be important to you.

In agreement with the overall theme, you might get much better percentage
throughput increases with other uses of electronic persistent media. But
putting online redo logs on electronic media definitely makes them faster,
as all the experimental data anyone has ever shown me indicates (including
this article). Whether it is a good economic choice for your actual
operational system has to be tested.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Greg Rahn
Sent: Saturday, March 19, 2011 2:02 PM
To: jkstill@xxxxxxxxx
Cc: robertgfreeman@xxxxxxxxx; surachart@xxxxxxxxx; Oracle-L@xxxxxxxxxxxxx
Subject: Re: [Exadata] How do you use FlashDisk ?

"It is a common misconception that Oracle online redo logs will benefit by
moving them on EFDs, whereas all the experimental data indicates the
opposite position"
page 17
http://www.emc.com/collateral/hardware/white-papers/h5967-leveraging-clariio
n-cx4-oracle-deploy-wp.pdf

On Sat, Mar 19, 2011 at 10:53 AM, Jared Still <jkstill@xxxxxxxxx> wrote:
>
>
> On Sat, Mar 19, 2011 at 6:58 AM, Robert Freeman 
> <robertgfreeman@xxxxxxxxx>
> wrote:
>>
>> Flash disks for WRITE operations are actually not that fast. I don't 
>> have the performance numbers here, but you really don't buy anything 
>> in terms of write performance with flash disks. So I would not 
>> recommend them for a disk group that will contain, say, online redo logs.
>
> Interesting observation Robert.
> From the two guys at LSI that test flash memory with Oracle:
> "Online redo logs are best handled by Hard Disk Drives because of the 
> sequential writes"


--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: