Re: Flash or SSD for MultiBlock Reads

  • From: Frits Hoogland <frits.hoogland@xxxxxxxxx>
  • To: dmarc-noreply@xxxxxxxxxxxxx
  • Date: Tue, 16 Sep 2014 23:16:42 +0200

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
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] On 
> Behalf Of Chitale, Hemant K
> Sent: Wednesday, September 10, 2014 11:24 PM
> 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 
> at

Other related posts: