Fast Cache - Impact on Random Write performance

It would be interesting to see if your getting any forced flushing due to the reduction in DRAM.

yep, SPA is hovering around 99%

If you are using XenServer 5 (Boston) make sure you have the latest service pack / patches installed.

We've seen some weirdness in the I/O behaviour in the initial releases

Rainer

Strebel wrote: It would be interesting to see if your getting any forced flushing due to the reduction in DRAM.

If you are you should look at adapting the watermarks

thanks Rainer, customer is still on 4.x . What i am doing here is generating workload with IOmeter so virtualization platform is not in the picture.

Baif,

i have specific application and specific workload that i need to address, i don't have time to play "what if's". Sorry

LOL.

I think FAST VP with Tier0 is the best way absobing this kind of random write in this size of write size...

Do you think you can run different tests on it. Really wanna see how FAST Cache works with different type of apps/filesystems.

You may check your NTFS volume setttings.

• IOzone NTFS, SQLIO with NTFS with different block settings.
• And I wanna know how does FAST Cache work with EXT4/XFS on Linux, with IOMeter/IOZone with different block setttings.

The test area is small and you're comparing FAST cache on performance with 100% cache hit performance.

I'll explain;

2 * 5GB LUNs so all writes will be cache hits and just stay in cache (eventually as his reads should be hitting that data at some point after the start of the test).

Any I/O causing triggers to promote to FAST cache would expect to see a benefit only if you were disk bound and with 10GB total test area, you'll never see that.

Your logic dictates that 4 drives in FAST Cache should be able to boost the load, but that equates to 20K+ IOPs per drive (flash drives won't do 20K+ in predominant write profiles).

So the underlying issue is that you're comparing FAST cache affected load to cache only hits and with promotion logic doing what it does, you can only ever show a negative effect with that test.

To understand and realise FAST cache benefits you must have disk bound activity i.e. write cache flushing and disk utilization occurring. SP DRAM Cache is inherently faster than SSD's.

Another way of looking at it;

You have a 180 disk pool of R1.

you have 10GB of user space that should equate to 10 slices, each serviced from a 4+4 RG, thus 80 drives (I assume we understand pool slice allocation i.e. pools comprise private RG's, etc).

So now that 45K IOPs, if it really were serviced by 80 drives would work out like this;

45K at 90% random and 90% writes = 36,450 writes = 72,900 disk IOPs (R1).

Add the 10% random reads of 4,050 = 76,950.

So if disk bound, we’d expect nearly 1000 IOPs per drive in your pool for those that are active.

To conclude – your test area is small and you're comparing FAST cache on performance with 100% SP write cache hit performance.

I do not know why your FAST cache stats for the pool are showing zero. Would like to see the nar files to see if any of your physical disks in the pool are doing anything other than sniffer…. And so on.

Just to add -- I am expecting your small test size is resulting in write cache rehits of 100% for those LUNs. That would also show read hits being high as well as those will be serviced from the data in write cache.

I hope that helps.

When you are running out of SP cache.

No worries, hopefully ksnell resolves your concerns and FAST VP helps in long term.

ksnell wrote: So the underlying issue is that you're comparing FAST cache affected load to cache only hits and with promotion logic doing what it does, you can only ever show a negative effect with that test.

So if my workload is so small and everythign is serviced by DRAM, how's enabling Fast Cache decreases my performance in half ?

Thanks

where did you get FAST-VP from ?

That really depends on your access locality –

Fast VP doesn’t relocate very frequently – often customers set it to just during the night whereas Fast Cache reacts quicker

Rainer

15 hours to "warm up" should be long enough ..don't you think ?

This is not artificial workload, this workload currently exists on DMX4, stats are gathered from SPA (Symmetrix Performance Analyzer).  Trust me, i am not making this up.