​

One of our S-TAPs sees a high amount of shared memory traffic that cannot be ignored. We receive errors resembling this technote:

LOG_NOTICE MSG(469) MODULE(1) SEV(2) COUNT(1) shmem reader_worker: bucket 3, Number of dropped packets: 7048 - 307463747 bytes 2018-10-08 13:26:22.0

One documented resolution is to increase the shared memory max size. When we changed the value from the default 2GB to 3GB the S-TAP stopped sending all traffic to the Collector even after restarting the S-TAP. Does changing the exit_lib_shmem_size parameter require the database instance/server to reboot as well?

Reverting the change has had no effect and traffic is still not being sent to the Collector.

------------------------------
Chase Walkup
------------------------------

Based on my own findings, you need to restart DB2 in order to get the changes to apply.

My theory is since the Exit is linked directly with DB2 the changes are not called for until the current running DB2 Exit process is released. Once DB2 is restarted the Exit is called with the updated shared memory parameter and traffic monitoring will be restored. This ​contradicts the technote for this issue which suggests an STAP restart will be sufficient to apply the changes.

If anyone has any other experiences or comments please let me know.

------------------------------
Chase Walkup
------------------------------