@Sridhar246: I have 4 storage pools, only two of them have FAST cache enabled. but those two pools are hosting >200LUNs.
@Brett@S: thanks for the tip. Actually I did a live-chat yesterday with EMC, but I got response from Agent
Agent : "They have introduced new future in VNX second generation to flush the data immediately to backend."
Agent : "So it will always shows as 0 % in VNX second generation."
Franky speaking - I'm not buying it. IF all data is always immediately flushed to the backend what about READ hits - it would always be 0 which does not make any sense. Plus when sending a lot of data to VNX I think it is not using FAST cache at all.
I believe this is a known limitation when using pool LUNs as opposed to traditional LUNs. Try:
naviseccli -h {SP} getlun -fastcache
and you will notice that for all your pool LUNs the data is "N/A". Traditional LUNs/MetaLUNs will show performance data as expected. See the "Known Problems and Limitations section of the "VNX Monitoring and Reporting Release Notes".
FAST Cache is enabled at the Pool level and not the LUNs in the Pool. When you enable FAST Cache on a Pool, all the LUNs in the Pool will use FAST Cache.
For reporting, you will only see FAST Cache statistics for the Pool and not the individual LUNs in the Pool.
I was just looking through the statistics in MnR which I finally got around to setting up for my VNX5200, and I noticed the exact same thing. Looking into it, I have FAST Cache enabled for my storage pools, but I see nothing for the LUNs themselves. If it is as glen mentioned, then that would make sense that I do not see the stats for the LUNs.
Anyway, sifting through the different report options, in MnR, everything is 0 of course, except for FAST Cache / FAST Cache SSD Utilization, and the two FAST Cache reports for the SP level (Systems -> Summary -> Array Summary -> -> Block, -> -> FAST Cache). These reports show that the FAST Cache is being used at least.
My array is being upgraded from 5.33.0.5.051 to .081 tonight, so I will have to see if that makes a difference.
Please expand about what you mean by "having the same issue"?
At the Pool level FAST Cache statistics are only visible for the Pool and not Pool LUNs. If you open a NAR file and in the Pool tab, select a Pool - that should show six values that you can look at. Select the Read and Write cache hit Ratio selections and you should see something.
At the SP level FAST Cache statistics are:
FAST Cache Dirty Page (%)
FAST Cache MB/s Flushed (MB/s)
On the VNX2 the FAST Cache Dirty Pages will only show the Dirty Pages as they come in, normally you would just see a short spike. Dirty Pages are cleaned almost immediately, so you will not see Dirty Pages staying high (as in the VNX1).
You can use the CLI command:
naviseccli -h SP cache -fast -info
This will show the "current" state of the Dirty Pages - as cache is cleaned very quickly, this is normally very small.
A better way to see if FAST cache is working is to look at the flushed numbers - if you see anything, that's an indication what it's working.
Thanks. As this topic started we are seeing percentage of fast cache dirty pages as zero and we have all the hard disk utilized 100%. All Hard disk are hitting to a maximum of 150 iops for a 10k rpm disk. I am seeing the MB's flushed in the output. Our environment consist of 70% read and 30% write. It is all 4k blocks random IO and there seems to be a write latency in application. I checked the analayser output, there is no value for fastcache hit %.We raised a case with EMC. They got back stating that performance looks good and fast cache is working properly. They found 000 (out of order ) frames in the SP's and that should be due to a bug on the CISCO UCS. Let me try to check, if i can get further information.
"Franky speaking - I'm not buying it. IF all data is always immediately flushed to the backend what about READ hits - it would always be 0 which does not make any sense. Plus when sending a lot of data to VNX I think it is not using FAST cache at all."
To reply to this and to add to what Glen is saying - the dirty pages in Fast Cache on a VNX2 array flush down very quickly. It is quite normal to see dirty pages at 0% or very close to it. Rarely do I see anything higher than a couple of percent in the nar files I look at.
This doesn't mean that there is no data in Fast Cache. There is plenty of data in there. What it means is that there is no "dirty" data in there, meaning data that needs to be committed to disk. The data that comes in to Fast Cache will quickly be written down to disk flushing out the dirty pages. That data will most likely still remain in Fast Cache so long as it meets the criteria and is getting frequently accessed. That's why you will see read hits and other metrics still being met by Fast Cache like Glen mentions. When it no longer meets that criteria it will be removed from Fast Cache.
But the statistic you are looking at specifically is dirty pages and those dirty pages are quickly being written down to disk so there are very few dirty pages actually in Fast Cache.
Glen is also correct that you can only see statistics for Fast Cache at the Pool level. You should see hits at the Pool level for Fast Cache.
Sridhar246
115 Posts
0
February 12th, 2015 12:00
Do you have storage pools? If yes, is fast cache enabled for all the pools?
brettesinclair
2 Intern
•
715 Posts
0
February 12th, 2015 14:00
If you're not seeing any hits through M&R or through analyzer, I would be opening an SR.
There may be a bug, or you may be advised to schedule an OE upgrade or other.
Even if you have searched support and not found anything, there are often kb's that are not visible to customers. Support can help.
tomekp1
9 Posts
0
February 13th, 2015 00:00
Hi
@Sridhar246: I have 4 storage pools, only two of them have FAST cache enabled. but those two pools are hosting >200LUNs.
@Brett@S: thanks for the tip. Actually I did a live-chat yesterday with EMC, but I got response from Agent
Agent : "They have introduced new future in VNX second generation to flush the data immediately to backend."
Agent : "So it will always shows as 0 % in VNX second generation."
Franky speaking - I'm not buying it. IF all data is always immediately flushed to the backend what about READ hits - it would always be 0 which does not make any sense. Plus when sending a lot of data to VNX I think it is not using FAST cache at all.
brettesinclair
2 Intern
•
715 Posts
0
February 13th, 2015 03:00
OK,based on that, I would check the Hits/misses/ratios in analyzer.
If you're seeing no hits, then I would suggest something is NQR and escalate to your TAM for further investigation/analysis.
Noogz
21 Posts
1
February 13th, 2015 04:00
I believe this is a known limitation when using pool LUNs as opposed to traditional LUNs. Try:
naviseccli -h {SP} getlun -fastcache
and you will notice that for all your pool LUNs the data is "N/A". Traditional LUNs/MetaLUNs will show performance data as expected. See the "Known Problems and Limitations section of the "VNX Monitoring and Reporting Release Notes".
Aleite
27 Posts
0
February 13th, 2015 05:00
have same issues with 5600. using 10 disks in FastCache (1TB)
Its Enabled for the two pools we have.
showing N/A for dirty pages
Size (GB): 917
State: Enabled
Current Operation: N/A
Current Operation Status: N/A
Current Operation Percent Completed: N/A
Percentage Dirty SPA: 0
MBs Flushed SPA: 19204076
Percentage Dirty SPB: 0
MBs Flushed SPB: 25112868
showing N/A for the Luns
LOGICAL UNIT NUMBER 10
FAST Cache : N/A
FAST Cache Read Hits: N/A
FAST Cache Read Misses: N/A
FAST Cache Write Hits: N/A
FAST Cache Write Misses: N/A
Will investigate with analyzer as per Brett@S suggested.
Will check the release note for patch 81...
kelleg
4 Operator
•
4.5K Posts
2
February 16th, 2015 10:00
FAST Cache is enabled at the Pool level and not the LUNs in the Pool. When you enable FAST Cache on a Pool, all the LUNs in the Pool will use FAST Cache.
For reporting, you will only see FAST Cache statistics for the Pool and not the individual LUNs in the Pool.
glen
kwohlgemuth
1 Message
0
March 13th, 2015 07:00
I was just looking through the statistics in MnR which I finally got around to setting up for my VNX5200, and I noticed the exact same thing. Looking into it, I have FAST Cache enabled for my storage pools, but I see nothing for the LUNs themselves. If it is as glen mentioned, then that would make sense that I do not see the stats for the LUNs.
Anyway, sifting through the different report options, in MnR, everything is 0 of course, except for FAST Cache / FAST Cache SSD Utilization, and the two FAST Cache reports for the SP level (Systems -> Summary -> Array Summary -> -> Block, -> -> FAST Cache). These reports show that the FAST Cache is being used at least.
My array is being upgraded from 5.33.0.5.051 to .081 tonight, so I will have to see if that makes a difference.
rsrini1
2 Posts
0
May 18th, 2015 16:00
I am having the same issue with the VNX 5600 running in 05.33.000.5.079, did you find solution after the upgrade. ?
brettesinclair
2 Intern
•
715 Posts
0
May 19th, 2015 01:00
Have you checked it in analyzer/mitrends/m&r ?
What symptoms do you have ?
kelleg
4 Operator
•
4.5K Posts
0
May 19th, 2015 07:00
Please expand about what you mean by "having the same issue"?
At the Pool level FAST Cache statistics are only visible for the Pool and not Pool LUNs. If you open a NAR file and in the Pool tab, select a Pool - that should show six values that you can look at. Select the Read and Write cache hit Ratio selections and you should see something.
At the SP level FAST Cache statistics are:
FAST Cache Dirty Page (%)
FAST Cache MB/s Flushed (MB/s)
On the VNX2 the FAST Cache Dirty Pages will only show the Dirty Pages as they come in, normally you would just see a short spike. Dirty Pages are cleaned almost immediately, so you will not see Dirty Pages staying high (as in the VNX1).
You can use the CLI command:
naviseccli -h SP cache -fast -info
This will show the "current" state of the Dirty Pages - as cache is cleaned very quickly, this is normally very small.
A better way to see if FAST cache is working is to look at the flushed numbers - if you see anything, that's an indication what it's working.
glen
rsrini1
2 Posts
0
May 19th, 2015 08:00
Thanks. As this topic started we are seeing percentage of fast cache dirty pages as zero and we have all the hard disk utilized 100%. All Hard disk are hitting to a maximum of 150 iops for a 10k rpm disk. I am seeing the MB's flushed in the output. Our environment consist of 70% read and 30% write. It is all 4k blocks random IO and there seems to be a write latency in application. I checked the analayser output, there is no value for fastcache hit %.We raised a case with EMC. They got back stating that performance looks good and fast cache is working properly. They found 000 (out of order ) frames in the SP's and that should be due to a bug on the CISCO UCS. Let me try to check, if i can get further information.
Joshua_Fawcett
35 Posts
0
May 19th, 2015 09:00
"Franky speaking - I'm not buying it. IF all data is always immediately flushed to the backend what about READ hits - it would always be 0 which does not make any sense. Plus when sending a lot of data to VNX I think it is not using FAST cache at all."
To reply to this and to add to what Glen is saying - the dirty pages in Fast Cache on a VNX2 array flush down very quickly. It is quite normal to see dirty pages at 0% or very close to it. Rarely do I see anything higher than a couple of percent in the nar files I look at.
This doesn't mean that there is no data in Fast Cache. There is plenty of data in there. What it means is that there is no "dirty" data in there, meaning data that needs to be committed to disk. The data that comes in to Fast Cache will quickly be written down to disk flushing out the dirty pages. That data will most likely still remain in Fast Cache so long as it meets the criteria and is getting frequently accessed. That's why you will see read hits and other metrics still being met by Fast Cache like Glen mentions. When it no longer meets that criteria it will be removed from Fast Cache.
But the statistic you are looking at specifically is dirty pages and those dirty pages are quickly being written down to disk so there are very few dirty pages actually in Fast Cache.
Glen is also correct that you can only see statistics for Fast Cache at the Pool level. You should see hits at the Pool level for Fast Cache.