Shadow Copy Breaks

[Wim Van den Wyngaert]

I have a problem : the performance of the shadow copy (interbuilding) is too good. As a result, the application takes 18 instead of 3 minutes to do certain things (Sybase dbcc, no other activities on the cluster).

Is there a way to decrease the resource usage of the shadow copy (not merge !!!) ?

Max shadow copy is set to 1 (and 0 on the other member of the cluster).

Wim

[labadie_1]

You have several logicals to play with

SHAD$MERGE_DELAY_FACTOR applies to all shadow sets mounted on a node unless you also use SHAD$MERGE_DELAY_FACTOR_DSAnnnn.
SHAD$MERGE_DELAY_FACTOR_DSAnnnn applies to each shadow set specified by its virtual unit name, DSAnnnn.

If you increase the setting for either logical name, you increase the merge rate and decrease the I/O rate. Conversely, if you decrease the setting for either, you decrease the merge rate and increase the I/O rate.




see at this copy of the doc
http://www.pi-net.dyndns.org/docs/openvms0731/731final/5423/5423pro_013.html

the chapter
9.2.1 Improving Performance of Unassisted Merge Operations

[Wim Van den Wyngaert]

Gerard : 2nd paragraph : not merge but copy.

Wim

[Willem Grooters]

Wim,

I'm not familiar with shadow-copy - let alone interbuilding - but I could think of the requirement to have it done with all possible resources of network (fibe, I presume) and disk.
If your Sybase application has the same requirements - and knowing Sybase is a relational database and THUS requires a lot of resources as well - it's obvious you have a conflict. A factor 6 however is very high.
I would suggest to look for the real bottleneck: disk, controller or interconnect.

Another possibility I can think of is the disk being locked, due to the shadow-copy's requirements. That may prevent the application access the disk during shadow-copy operations.

Willem

[Volker Halle]

Wim,

during a shadow-copy, SHADOW_SERVER will be doing 127 block reads and writes as fast as it can to provide the required disk redundancy as fast as possible.

Try to find out, where the bottleneck is between the shadow-copy and your application. CPU-usage during a shadow-copy would normally be minimal, interconnect load and disk/channel load may be more significant, but it highly depends on your configuration. Start with a couple of MONITOR commands during the next planned shadow-copy.

I've recently seen a massive CPU-load (high INT-stack) on an ES47 cluster during shadow-copy due to nonpaged pool fragmentation.

Volker.

[Wim Van den Wyngaert]

Volker,

It is a FDDI interconnect and the disk thruput was about 12 MBytes per second. Sybase hardly got 2 MByte and all the rest went to the shadowing. The interconnect was charged about 8 Mbytes per second.
Seems normal to me.

It seems that the shadowing is simply "gourmand".

[Wim Van den Wyngaert]

Volker,

No pool fragmentation. 40% used and largest block is 50%.

Wim

[labadie_1]

It memory serves me, the process shadow_server is not allowed to take more than 10 % of the Cpu, even if nobody else uses the Cpu !

[Ian Miller.]

what version of VMS?

[Wim Van den Wyngaert]

CPU is not the problem. The total copy took 5 minutes of cpu in 14 hours.

It is VMS 7.3 patched until 03-2003.

Wim