Handling high-volume publish/subscribe activity on z/OS

Brokers that handle large numbers of retained subscriptions or publications can use up all the IRLM storage that is allocated by default for DB2 locks. This might cause problems when you try to restart the broker.

The following actions might help stop this happening.

  1. Tune the publish/subscribe topology:
    1. Balance execution groups across more brokers; this means that fewer execution groups need to start at the same time and have concurrent locks for the same DB2 subsystem.
    2. Put the brokers in publish/subscribe collectives; this reduces the number of subscriptions in a single broker table and reduces the amount of concurrent access to DB2. See Publish/subscribe topologies for more information about this.
  2. Increase the IRLM storage that is available:
    1. Set the value of MAXCSA so high that the ECSA that is required by the IRLM never reaches this value. Because IRLM gets storage only when it needs it, choose a value that is higher than you expect IRLM to need.
    2. If you are unable to choose a value of MAXCSA sufficiently high that it cannot be exceeded by the ECSA that is required by the IRLM, use the option PC=YES on the START irlmproc command. This causes the IRLM to place in its private address space the control block structures that relate to locking. There is more information about this in the DB2 Redbook DB2 UDB for OS/390 Version 7 Performance Topics, SG24-5351.
Note: There might be a slight (approximately 1 to 2 percent) performance degradation when you run with PC=YES. See DB2 Universal Database for OS/390 and z/OS Version 7 Administration Guide, SC26-9931 for more information.
Related tasks
Resolving problems when using publish/subscribe