Auxiliary Trace Active

Hi,

What will be the impact if we enable Auxiliary Trace Active in Diagnostics. Can we enable only when batch jobs are not running.

Regards
Noel Melvin

The impact of aux trace is that trace records are written to disk. CAS trace records are small, fixed-length binary entries, so writing them is quite efficient. Since CAS uses a rotating pair of trace output files, the total storage required is bounded.

The number of records written per time interval or operation depends on which trace flags are enabled.

The processing overhead of CAS tracing is small, and the vast majority of ES-hosted applications are I/O-bound, so the processing overhead of tracing is usually negligible. Because trace record output is efficient and goes to dedicated files (reducing contention), the I/O impact is also negligible for most workloads. The product documentation warns about potential performance impacts, but those warnings originated in the 1990s when system performance characteristics were very different. On a modern OS running on modern hardware, in a reasonable configuration, I think it's quite unlikely that a production workload would see any user-visible impact from auxiliary trace.

But it's foolish to speculate. Enable it and find out.

It's possible to enable and disable the auxiliary trace dynamically (while the region is running), but I don't offhand know of an easy way to automate that. Nor do I think it's worth doing. In particular, I don't see the benefit of enabling the trace only when batch jobs are not running. If your batch jobs are that I/O-constrained, you should be looking at fixing your I/O subsystem to provide more performance margin.

Thanks Mike, What about activating the CTF trace, KCP and SCP options and in CICS API and fcp options.

Whether the job running or accessing the ES Admin Console etc degrades.