High latencies since we've activated FAST II

have you looked in analyzer and see what's going on around that time ? It could be completly unrelated to FAST.

no.

relocation runs during nightly hours and the high latencies are reported around noon.

it's not around the time your relocation runs ? I always see service times and CPU utilization go up when relocation runs.

yes we did.

created a heat map with the support. it shows for one day one traditional RAID group being overutilized by one LUN - but not high load on both SPs and ~20% free cache on both SPs. on the other day there was no load on this LUN but latencies rised at exactly the same time again.

how can we determine when the internal rollup jobs for statistics collection for autotiering is running?

check the version of flare you run - if it is release 30 patch 512 or lower, please upgrade to latest flare patch 522. There are some fixes for FAST cache enabled on auto-tiered Pools that will help. Contact service to schedule a flare upgrade for this and mention the 1200ms response times.

glen

Hi Glen,

FLARE was updgraded yesterday to .522

Let's see if this will solve our problem.

Regards,

Daniel

Just ab FYI - I worked a case where the workload was in constant flux for about two months - adding, removing, changing, etc. During this time performance was not real good. Once the configuration was stable, it took about 3-4 weeks and then performance improved until they hit a stable point and performance remained constant from that point on. So it may tak a while to settle down. Watch the amount of data relocations each day in the Tiering section - you should see alot to to move at first, then as time passes, the amount of data to move up and down starts to decrease. If you're seeing TB's to move up and down, you're changing too much.

Also, be careful with backups running at the same time you have tiering scheduled.

glen

Thanks

I never even thought about auto tiering and backups running at the same time.

For me, the troubleshooting clue would be :

(1) Enable data logging to monitor the box since it would record any possible perf issue. You may take a look at NAR to match the exact time frame that the issue happened. In case the issue could be not related to FAST VP.

(2)check FAST relocation running status to determine if it were running during issue time.

Regards

-Steve

Hi, Any response to Flare upgrade? I'm in the same situation. Thank you,

status so far:

- backup and auto tiering does (and did) not run at the same time

- FLARE has been upgraded last Thuesday to patch level 522

- that brought us only very small improvements since problems seem to be caused by high load on mirrored volumes

- high latencies are observed not in the timeframe where relocation runs

Are there any Mirror View issues know we have to be aware of?

We started moving to a pool concept within one array. That brought us to the situation where we needed to extend the pools with disks which have been freed by migration their LUNs to the pools etc. Without a relocation or restriping process were are stuck in some LUNs located only on the very small number of fresh disks added to the pool shortly before the LUN has been migrated to the pool...

In our opinion the only way would bee to migrate all data off the array and to build pools with their final capacities and then move back all data to the array. Does anyone would like to share his thoughts on that problem?

Best regards,

daniel

We do not have FAST Cache enabled. How can I access emc266584?

Search "emc266584" on "Search Support" on Powerlink.