Start a Conversation

Unsolved

This post is more than 5 years old

490

April 22nd, 2010 13:00

SNAPVIEW performance issue

I had an issue this morning after trying to access a set of SNAP luns on an alternate server. After adding a host to the SNAP storage group and starting to mount the SNAP LUNs my production hosts started to have issues. Each LUN started to queue, some of them the queue was double the active IO. I still had alot of free space in the resurve pool. The only thing I noticed was dirty page % was over 90%. This is the first time we tried to access a SNAP and the source LUNs at the same time. We would normally be moving the server to the new SNAP SG for testing.

Anyone have any thought?

2 Intern

 • 

20.4K Posts

April 23rd, 2010 07:00

you started seeing problems during the mount process before you even had a chance to use them ?

April 23rd, 2010 10:00

Dirty pages are from write cache filling up, due to busy spindles. In the case of a snapshot data is being written (or deleted) from either the production LUN or it's snapshot. Things to check is production LUN, snapshot, and snapcache performance during that time. Although you have plenty of space in snapcache, what is the utilization of the snapcache spindles?

We perform multiple snapshot/mounts a night. I have review the last 7 days of our NAR data and have not seen any increase on dirty pages during the mount process.

If you like please share your NAR data with the group.

No Events found!

Top