Shared Memory Explorer

Overview

Shared memory is used by Testimony to achieve near zero impact upon the production systems during the recording phase. Therefore, it is important to be able to monitor the shared memory in the system being recorded, This can be achieved in the source system via ST02, however, access to the source system is not always possible. The Shared Memory Explorer solves this issue. The Shared Memory Explorer has the added advantage of being able to see all app servers on the one system as well as the objects contained in each app server’s shared memory, It details the memory availability and usage as well as the maximum objects available and their usage. Shared memory parameters would have been checked and adjusted as a part of the installation of Testimony. The recommended settings for the shared memory parameters are here. These might vary based on the usage of the source system.

Monitoring

The Shared Memory Explorer is found under the ‘Configuration’ tray if using the Administrators UI profile. This is the recommended method for monitoring the shared memory of a system being recorded, primarily because it offers one view of all the application servers on a source system. The usage of shared memory is expected to rise and then fall back every minute as the data is saved to the database. Memory climbing without being cleared out every minute should be investigated firstly before checking the recording job /BTI/AUT_SAVE_BTRAN_PERIODIC is running on the source system and if shared memory continues to climb consider stopping the recording.

Testimony has a fail safe and if the shared memory is exhausted, Testimony will start to save directly to the database. However, the general parameter ALLOWED_DB_WRITES is used to determine how much data can be written directly to the database before the recording aborts. The recommendation for this parameter is 1000 database writes per minute before aborting.

Shared memory is displayed as below. To view the objects on each app server, double click the row. The used objects should not get to within 10% of the max objects and the free memory should not get to below 1000 kb. If they do, you should consider stopping the recording and reviewing if there are large objects you should be excluding or reviewing or if the shared memory settings should be boosted.

Stopping a Recording

*Note you should use the Recording Status tab to stop a recording the stop option here is for emergency use or for the cleanup of shared memory.

This is an emergency stop, but it also requires the RFC to be operational between the central and source systems. The stop button can be used to abort the recording. Selecting the purge database checkbox option will remove all of the recorded data from the BTI tables and clean up any data in the shared memory of the source system. Note that you won’t be able to use the data recorded for a playback if you purge the system of BTI data.