Question & Answer
Question
Some of AIX commands (errpt, topas, etc) or some processes on AIX might become very slow while using Guardium S-TAP in some evironments. Why could it happen and how to resolve it?
Cause
S-TAP uses K-TAP to intercept shared memory as a default, and it may take sometime to know if the share memory is for DB2 database access or not.
Answer
You can add the particular process which gets this issue to the blocklist, and then K-TAP will skip checking specified process and it will resolved the issue. Here is the detail steps:
1) Check if the issue is disappeared by disabling K-TAP to intercept shared memory. To confirm this, set the inspection engine parameter intercept_types=tcp in guard_tap.ini and restart S-TAP. If the issue is disappeared, we can suspect the issue is caused by K-TAP.
After the check, revert the settings to intercept_types=NULL and restart S-TAP again.
Here is a typical examples of inspection engine settings.
--------
[DB_0]
connect_to_ip=127.0.0.1
db2_fix_pack_adjustment=20
db2_shmem_client_position=61440
db2_shmem_size=131072
db2bp_path=NULL
db_exec_file=/home/db2inst1/sqllib/adm/db2sysc
db_install_dir=/home/db2inst1
db_type=DB2
encryption=0
informix_version=9
instance_running=1
intercept_types=NULL
load_balanced=1
port_range_end=50000
port_range_start=50000
real_db_port=50000
tee_listen_port=NULL
unix_domain_socket_marker=NULL
networks=0.0.0.0/0.0.0.0
exclude_networks=
--------
2) If the previous steps works fine, identify the process that is causing the hang issue, and add the process to the blocklist_shmem_ops_by_proc parameter in guard_tap.ini, and restart S-TAP. Here is an example of guard_tap.ini.
--------
[TAP]
blocklist_shmem_ops_by_proc=errpt
--------
This will stop K-TAP from intercepting shared memory of errpt. You can safely add this process in the blocklist because it shouldn't be accessing DB2 shared memory.
If it doesn't resolve the issue, please proceed to the next step.
3) Check if the S-TAP is running as a guardium user, which means tap_run_as_root=0 in guard_tap.ini. If yes, add the DB2 user to guardium group to see if the problem can be resolved. Here is the detail steps:
3.1 Stop DB2
3.2 Add the DB2 user (ususally db2inst1) to the guardium group by "chgrpmem -m + db2inst1 guardium" command on AIX.
3.3 Restart DB2
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21678970