8 Krypton

Why VFCache adopts SLC Flash technologies

Morning,

As Oracle Tribes always be cutting-edge, I posted one of recent hottest  discussion - VFCache. As we knew, NAND Flash memory tech evolved and produced in at least four variations. The two types triggered my most interests which single-level cell(SLC) store only one bit of information in each cell and multi-level cell(MLC) devices store more than one bit per cell.  

Theoretically MLC and SLC offer capabilities that serve two different types of applications - high performance and large capacity (the dilemma usually confronts us sizing folks). I am certain there are much statistics sustain the SLC Flash architecture used by VFCache.

It depends on which one you prefer to share? 

0 Kudos
11 Replies
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

Well, general speaking, SLC provide 2 times read performance and 4 times write more than MLC does because SLC cell only has 2 status and MLC cell has 4 status. Therefore SLC offer more performance density and MLC does on capacity density.

VFachen does as a solution to provide host less latency of IO, SLC is preferred.

Eddy

Highlighted
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

As Eddy point out:

Most MLC NAND flash memory has four possible states per cell, so it can store two bits of information per cell. This reduces the amount of margin separating the states and results in the possibility of more errors. The primary benefit of MLC flash memory is its lower cost per unit of storage due to the higher data density. However, software complexity can be increased to compensate for a larger bit error ratio. The higher error ratio requires an algorithm that can correct errors up to five bits and detect the condition of more than five bad bits.Other drawbacks of MLC NAND are lower write speeds, lower number of program-erase cycles and higher power consumption compared to SLC flash memory.

SLC memory has the advantage of faster write speeds, lower power consumption and higher cell endurance. However, because it stores less data per cell, it costs more per megabyte of storage to manufacture. Due to faster transfer speeds and longer life, SLC flash technology is used in high-performance memory cards.

EMC VFcache is propositioned to critical applications in Enterprise. That's why SLC is current selected.

8 Krypton

Re: Why VFCache adopts SLC Flash technologies

Well, I like to expand this topic a little.

Generally, Controller does play a role as important as cell does, but as I know there is no one able to play well both of various IO size, IOPS/throughput. I,e. Crucial provide fastest 4K IO performance, Intel does well on balance, Corsair leverage his compression tech to optimize throughput.

Let us guess which one VFcache would buy in? I put my hand on Crucial.

Eddy

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

Thanks for both helpful inputs. Shall I conclude it in this way. We cannot determine to select Flash device without considering factors including Bit Error Rate, Retention, Endurance, Performance, Cost and etc. The main operational characteristic distinguish SLC from MLC as:

  1. SLC is typically specified to endure ~10x more erase/write cycles than MLC.
  2. MLC erase/write operations are 2x to 4x slower than SLC; reads are slightly slower.
  3. SLC costs less per performance and endurance, but about twice as much per capacity compared to MLC.

For each application, three of above builds the foundation of all buy-in options. Agree?

Beside physical storage key features, shall we go further on any application characteristic, popular workload or even benchmark to demonstrate strength of SLC technology for caching solution like VFCache? Expertise is always welcome.    

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

Quotes from a WP described as "In the TPC-C-like configuration tested, a 1.2TB Oracle 11gR2 database was constructed to simulate a 3,000 warehouse, 90M customer database. The run simulated 150 simultaneous users and achieved over 56K TPM using a dual-socket(eight 2.9GHz cores) server with 12GB of memory and 250GB of VFCache. At this transaction throughput, the VFCache serviced 22K read and 14K write requests per second of 8KB IOs, hence the card was being written at 112MB/s".

It is proven by good acceleration of transactionall database. You agree?

Lu

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

VFCache is as new distributed cache layer between host CPU/RAM and storage, that is in order to provide less IO latency than EFD does, therefore SLC is the one.

To application, anyone suffered with high IO latency, VFCache would benefit them, but the performance increase would do matter with data locality due to the size of VFCache, as the same reason, DSS would be not good one, OLTP is good with it.

Eddy

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

I have no doubt with VFCache helping improving Oracle performance, since that would lower latency of Ora DBWR, LGWR processor.

But I am very curious with the size of DB, 90M? that means all data in VFCache. It is a bit little compared with real world.

Eddy

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

Sorry for confusion. I believe 3,000 warehouse and 90M customers is just business mode of 1.2TB Oracle database to simulate. So the benchmark is somewhat closed to real OLTP workload we always want to accelerate. As we knew, VFCache provides read acceleration, so the higher the read/write ratio of the workload, the more performance benefit users will get. It may be a good idea to load all in it when you ensure the read ratio is high enough. Agree?

0 Kudos
8 Krypton

Re: Why VFCache adopts SLC Flash technologies

I can’t say I total agree.

OLAP is looking for sustaining IO throughput, I understand VFCache able to provide more throughput during starting phase of data loading, but I think eventually it would get down to the line speed of backend disks. How does it keep @ this speed?

Guess, does this test use EFD as backend disk configuration?

Thanks,

Eddy

0 Kudos