RE: Flash or SSD for MultiBlock Reads

  • From: "Chitale, Hemant K" <Hemant-K.Chitale@xxxxxx>
  • To: <mwf@xxxxxxxx>
  • Date: Thu, 18 Sep 2014 09:50:50 +0800

> Well configured SSD can saturate the plumbing or CPU

I agree.  I see that happening when we move from disks to the new technology (I 
don’t know what Flash/SSD/Vendor technology it really is, details aren’t 
visible to me).  We’ve had to add more CPU cores to handle the I/O being 
returned by PQ slaves.   (Earlier, disk being the bottleneck, CPUs were idle, 
now they are “in demand”).

 

Hemant K Chitale

 

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Mark W. Farnham
Sent: Wednesday, September 17, 2014 3:55 PM
To: 'Kevin Closson'; frits.hoogland@xxxxxxxxx
Cc: 'ORACLE-L'
Subject: RE: Flash or SSD for MultiBlock Reads

 

I *think* Kevin and my analyses are ultimately exactly the same. Well 
configured SSD can saturate the plumbing or CPU with either single block or 
multi-block read, direct or buffered, but you might need parallelism of demand 
to fully load the plumbing if you have good plumbing.

 

Also in the context of the OP about the difference: There is more advantage for 
single block because there is more seek to eliminate, which is latency 
eliminated even at 100% bandwidth. That does not make single block SSD reads 
faster than multiple block SSD reads. It makes single block SSD a greater 
proportional improvement over single blocks from spinning rust than multi-block 
SSD is over multiple blocks from spinning rust.

 

mwf

 

From: Kevin Closson [mailto:ora_kclosson@xxxxxxxxx] 
Sent: Tuesday, September 16, 2014 7:02 PM
To: frits.hoogland@xxxxxxxxx; dmarc-noreply@xxxxxxxxxxxxx
Cc: mwf@xxxxxxxx; ORACLE-L
Subject: Re: Flash or SSD for MultiBlock Reads

 

I'm only responding to the OP which is MBRC in the context of Non-Mechanical 
storage. There are so many host ramifications that have to do with MBRC, yes, 
but my assertion is the size of MBRC *from modern all flash perspective* 
doesn't matter nearly as much as it does in mechanical storage. And as my case 
in point suggests I get saturate storage plumbing with low MBRC or high MBRC 
and that actually goes for conventional and direct. Now, having said all that 
I'll loop back to my mention of short tables scans. I really don't think it is 
optimal at the app level to wait for, say, 2 PIO on a really short table scan 
when perhaps the whole small table could have been read in a single I/O.

 

In general there are so many things we know about how Oracle evolved to 
optimize out the pain suffered by physical high latency I/O. It's good to 
remember old facts, but things change too...

 

So what's the reader to do? Well, I'll put it this way. Test *always* with the 
defaults Oracle sets. If you aren't perfectly happy with that then consider 
taking action.

 

 

________________________________

From: Frits Hoogland <frits.hoogland@xxxxxxxxx>
To: dmarc-noreply@xxxxxxxxxxxxx 
Cc: "mwf@xxxxxxxx" <mwf@xxxxxxxx>; ORACLE-L <oracle-l@xxxxxxxxxxxxx> 
Sent: Tuesday, September 16, 2014 2:16 PM
Subject: Re: Flash or SSD for MultiBlock Reads

 

There is a big, inherent, difference between the multiblock reads done buffered 
(scattered read) or to PGA (direct path read), because direct path reads are 
automatically and adaptively being done in parallel outside of parallel query.

 

But I think you are talking about direct path reads I guess Kevin? 


Frits Hoogland

http://fritshoogland.wordpress.com <http://fritshoogland.wordpress.com/> 
frits.hoogland@xxxxxxxxx

Office : +31 20 5939953

Mobile: +31 6 14180860

 

 

On 16 Sep 2014, at 23:06, Kevin Closson (Redacted sender 
"ora_kclosson@xxxxxxxxx" for DMARC) <dmarc-noreply@xxxxxxxxxxxxx> wrote:

 

multiblock reads make it easy to suffer storage networking bottlenecks but 
since these devices are seek free it so happens to be the case that usually one 
can obtain the same throughput with, say, 32K reads as with 1MB. Be aware 
however, it depends on how the firmware of the device works. In other words, 
mileage varies. 

 

I can speak of devices I'm familiar with. For example, EMC XtremIO with PQO 
MBRC=8/db_block_size=8K will saturate the 4x8GFC (~95% of max theoretical) 
plumbing (per X-Brick) just as easily as MBRC=64 or 128.

 

 

________________________________

From: Mark W. Farnham <mwf@xxxxxxxx>
To: 'ORACLE-L' <oracle-l@xxxxxxxxxxxxx> 
Sent: Thursday, September 11, 2014 8:09 AM
Subject: FW: Flash or SSD for MultiBlock Reads

 

forgot the list.

 

From: Mark W. Farnham [mailto:mwf@xxxxxxxx] 
Sent: Thursday, September 11, 2014 12:44 AM
To: 'Hemant-K.Chitale@xxxxxx'
Subject: RE: Flash or SSD for MultiBlock Reads

 

For direct single block reads you have a chance to have a seek plus read for 
each single block read. For direct multiblock reads when the size is reasonably 
matched to the disk you probably get only 1 or 2 seeks (2 when you hit a 
boundary in the middle of the read).

 

Since seeking is the biggest advantage of SSD over spinning rust, that means 
the advantage of SSD is likely maximized for single block reads.

 

For writes it is complicated by the page write size, but we’re only talking 
about reads here, right? On file systems you get some reduction in seeks 
because there is probably prospective next block buffering into the file system 
cache (but you pay for that overall by the move from cache to cache, which is 
why folks like direct, although you probably don’t dodge all levels of cache on 
a modern disk farm.)

 

But marginally for most workloads the advantage of SSD is diminished a bit for 
multiblock reads because there are fewer seeks per volume of data moved. For 
parallel you’ve got to tell us how fat your communications pipes are. You can 
probably multi-read from SSD faster than your channels can absorb and cpus can 
process, so there is a ceiling to the advantage of ssd in the parallel model.

 

Kevin Closson has been publishing some “holy cow that is fast” measurements of 
a certain combination of hardware kit. With the right configuration of the 
stuff he is using, it appears data loading is gated on cpu speed. (We always 
have some pacing resource. When it is memory movement or cpu, that is pretty 
much as fast as it can get).

 

mwf

 

From: oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>  
[mailto:oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx> ] 
On Behalf Of Chitale, Hemant K
Sent: Wednesday, September 10, 2014 11:24 PM
To: ORACLE-L
Subject: Flash or SSD for MultiBlock Reads

 

Are there any “thumb-rules” or “guidances” about the performance improvement of 
Flash / SSD over rotating disks when serving multiblock reads  and/or parallel 
query full-table-scans ?

That is, is the performance gain of Flash / SSD over rotating disks the same or 
better or worse when doing multiblock reads versus when doing single block 
reads.

Hemant K Chitale


This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries 
athttps://www.sc.com/en/incorporation-details.html 
<https://www.sc.com/en/incorporation-details.html> .

 

 


This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
https://www.sc.com/en/incorporation-details.html.

Other related posts: