The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
RAM Caching in V5.0
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
Are there any benchmarks with RAM caching turned off / on?
Are there any mechanisms for safety of the RAM cache in the event of an unexpected power failure?
Are there any mechanisms for safety of the RAM cache in the event of an unexpected power failure?
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
I'm not asking about RAM caching in HA, I'm asking about it in just regular Enterprise, which you've said previously is active today.
-
Constantin (staff)
Sorry, wrong topic reply.
No, we have no such tests, because of a lot of possible combinations of HDD+RAM and it`s performance.
In a write-through cache, every write to the cache causes a synchronous write to the backing store.
Alternatively, in a write-back (or write-behind) cache, writes are not immediately mirrored to the store. Instead, the cache tracks which of its locations have been written over and marks these locations as dirty. The data in these locations is written back to the backing store when those data are evicted from the cache, an effect referred to as a lazy write. For this reason, a read miss in a write-back cache (which requires a block to be replaced by another) will often require two memory accesses to service: one to retrieve the needed datum, and one to write replaced data from the cache to the store.
No, we have no such tests, because of a lot of possible combinations of HDD+RAM and it`s performance.
In a write-through cache, every write to the cache causes a synchronous write to the backing store.
Alternatively, in a write-back (or write-behind) cache, writes are not immediately mirrored to the store. Instead, the cache tracks which of its locations have been written over and marks these locations as dirty. The data in these locations is written back to the backing store when those data are evicted from the cache, an effect referred to as a lazy write. For this reason, a read miss in a write-back cache (which requires a block to be replaced by another) will often require two memory accesses to service: one to retrieve the needed datum, and one to write replaced data from the cache to the store.
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
So you are saying that in write-through mode, RAM caching is effectively disabled.
In write-back mode, RAM caching is enabled, similar to the way on-board cache works on RAID controllers, correct?
In write-back mode, RAM caching is enabled, similar to the way on-board cache works on RAID controllers, correct?
-
Constantin (staff)
In case of using write-through - you write synchronous to cache and HDD. All data is secured anyway.
In case of using write-back - you write first to cache, and then to disk. This is faster, but much less secure. Yes, it`s similar to RAID controllers cache.
In case of using write-back - you write first to cache, and then to disk. This is faster, but much less secure. Yes, it`s similar to RAID controllers cache.
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
So, with write through, there is no performance benefit of the RAM cache added in v5.x.
In write back mode, that is the only area where performance benefits can be seen, correct?
Is there any limit to the size of the RAM cache? (other than the amt of RAM in the host server -- if I load it up with 144GB of RAM, I could use, say, 96GB of RAM for the cache if I was really adventurous?). Can the cache be set to "flush" at periodic intervals? Some of our Infortrend RAID arrays have this option (e.g. every 5 seconds, 30 seconds, 1 minute, etc).
In write back mode, that is the only area where performance benefits can be seen, correct?
Is there any limit to the size of the RAM cache? (other than the amt of RAM in the host server -- if I load it up with 144GB of RAM, I could use, say, 96GB of RAM for the cache if I was really adventurous?). Can the cache be set to "flush" at periodic intervals? Some of our Infortrend RAID arrays have this option (e.g. every 5 seconds, 30 seconds, 1 minute, etc).
I understand the performance difference betwen write back and write through when a client is writing to an image file, but how does this affect reads? There are no settings for read ahead, or adaptive read ahead like on an LSI raid card. Please let me know how the two difference cache options affect read performance and operations.
-
Constantin (staff)
You will see impact in both cases, but write-through is is faster on read operations.
OK, So write through is safer and faster on reads. Write back is more risky and slower on reads, but faster on writes. I would think that unless you have a very write intensive workload that write through is the best choice, especially if your RAID card has a write back cache with a battery backup unit.
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
So with write through, I understand that writes are committed "immediately". But, how exactly does this new RAM cache feature in 5.x benefit READ operations? A little more detail would be helpful.
Agreed, more info on reads would be nice. How does the cache get populated with read data? If you have a 100% read workload would the cache get populated at all? What algorithm is used to moved frequently read data into and purged from cache? thank you.
-
Constantin (staff)
Cache is populated until with read data while it has free space, than old cached is replaced by new one.
-
tulsaconnect
- Posts: 28
- Joined: Tue Aug 12, 2008 9:43 pm
So you are saying that as data is read from the Starwind Server, it gets "mirrored" into the RAM cache in addition to getting sent on to the requesting iSCSI initiator?