2 Intern

 • 

1.3K Posts

September 24th, 2011 11:00

can u run the `symcfg list -v -sid xxx` and report the cache size,available cache slots, and the max slots against system, DA  and device .

what percenatage does `disk director utilization` reports? is there a huge change compared to a normal day?

WP tracks on devices is depened on `Max # of Device write pending slots` not the max # of DA one. ideally device WP limit is 4% of available cache slots. So if you have around 20 devices which is hitting the limits then you your system WP limit will be easiliy reached

r u doing any migration or huge change on source srdf copy is active?

looks like you were trying to say both system and device WP limits shows 50%; what exact matric are you selected in the graph?

1 Rookie

 • 

22 Posts

September 25th, 2011 04:00

Metrics plotted on graph were both from system - max wp limit and number of write pending tracks.

the second metric was hitting approx 50% and topping off indicating to me it could not got any higher.

The DA write pending limit from a symcfg list -v was at a similar number to the total for number of wp tracks from the symstat which is why I was querying if these stats directly correlate.

1.3K Posts

September 25th, 2011 06:00

By the way, there is no DA WP limit.  The only WP limits are at the device level and at the system level.

2 Intern

 • 

1.3K Posts

September 25th, 2011 06:00

my system reports DA limit as zero (5874.248.194) , that could mean no WP limit

LEOG, can you post the symstat command you are exactly using?what code are you at?

1.3K Posts

September 25th, 2011 06:00

At 50% of the system MAX WP, the DA goes into what is called "priority destage".  Before that point, destage has a lower priority than front end reads.  Above 50% it becomes the same.  So it isn't that uncommon for a system that is being pushed hard with writes to sit at the 50% level, but that isn't the WP limit.  However a little more write load could push the system to the 80% WP limit.

1.3K Posts

September 25th, 2011 07:00

One more thing.  The only ways to lower the WP counts are to slow writes into the system (decrease workload), or to speed up the destage by adding disks and/or DAs or changing the protection type to one with less backend writes per host write.

1 Rookie

 • 

22 Posts

September 25th, 2011 09:00

Symstat command is symstat without any switches.

Enginuity is 5773.160.111.

1 Rookie

 • 

22 Posts

September 25th, 2011 09:00

I've not got access to the array at the moment but definatley got a figure for Max # of DA Write Pending Slots       when running the command symcfg list -v.

Looked at some stats from the array and there appears to be a lot more reads on the array at the same time if these are random and read misses it will increase the backend contention and slow the reads down if wp then goes to 50% it would slow down the reads also as the destage would have equal priority.

1.3K Posts

September 26th, 2011 03:00

As far as I know, the DA WP limit has not been enforced or used for a long time.  In most systems the activity on the DAs is pretty well balanced so even if it was, the system limit would be reached first.

2 Intern

 • 

1.3K Posts

September 27th, 2011 06:00

where do you see this 20:80 is controlled?

1.3K Posts

September 27th, 2011 06:00

100% of the user cache can be used for read data.

Up to 80% of the user cache can be used for writes (System maximum WP limit)

At 50% of the maximum system WP limit, the writes have the same priority as reads. This is controlled by the DA destage algorithm.  It is not a user defined parameter.  Because writes increase in priority, the response time of reads the host is waiting for could increase.

No Events found!

Top