IBM Application running on a DB2 client performs poorly due to low level semget calls issued by DB2 - United States db2trc alloc; semget TECHNOTE (TROUBLESHOOTING)

PROBLEM(ABSTRACT)
 This document provides troubleshooting information for the situation where an application running on a remote DB2 client performs poorly. In particular, it describes a scenario where performance is poor because of failed semget() calls to the operating system.


CAUSE
DB2® Universal Database™ (DB2 UDB) has an internal trace facility called "db2trc". This trace facility acquires Inter Process Communication (IPC) resources (both semaphore and shared memory). Even though a DB2 trace is not turned on, it may issue semget() calls to the operating system. These calls will fail, though, since no IPC resources were acquired.

RESOLVING THE PROBLEM
The trace facility has an "alloc" option that can allocate necessary IPC resources. When you issue db2start, internal functions equivalent to command db2trc alloc are automatically issued, and when you issue db2stop, the trace segment will be removed if no one is using it.

Since a DB2 client does not necessarily have the ability to perform the db2start command, no IPC's will be automatically allocated for the trace facility, and hence the problem.

The solution is to issue the following command at the DB2 client:

db2trc alloc

This will then create the necessary IPC resources, and prevent the semget() calls from failing (since the semget() call now has IPC resources that it can use). The potential performance problem will thus be avoided.

The failed semget() operations are more of a concern for Solaris Operating Environment, Linux®, HP-UX and AIX® operating systems, in terms of performance implications. Windows® will not have this problem due to its specific architecture.

The db2trc alloc command should be invoked every time the client is restarted, and therefore it is recommended to add this command to a startup script.

Note: To determine if the application is issuing semget() calls, the best course of action would be to take a "truss". Please read your operating system manuals on how to perform and read a truss.

RELATED INFORMATION
 IC85712 (AIX) [http://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1IC85712]
FP5: db2trc command has been improved for clients (Linu [http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.wn.doc/doc/c0059466.html]
v10.5 IT17501 [https://www-01.ibm.com/support/entdocview.wss?uid=swg1IT17501]
v11.1 IT17518 [https://www-01.ibm.com/support/entdocview.wss?uid=swg1IT17518]
How do I resolve a performance issue with my applicaiton running on a DB2 client as a result of low level segement calls issued by DB2? Currently experiencing a performance issue with an application running on a DB2 client, the stack traces reveals that multiple segment() calls are being issued by DB2 and they are failing. What can be done to resolve this issue? 
The solution is to issue the following command at the DB2 client:

db2trc alloc

This will then create the necessary IPC resources, and prevent the semget() calls from failing (since the semget() call now has IPC resources that it can use). The potential performance problem will thus be avoided.

The failed semget() operations are more of a concern for Solaris Operating Environment, Linux®, HP-UX and AIX® operating systems, in terms of performance implications. Windows® will not have this problem due to its specific architecture.

The db2trc alloc command should be invoked every time the client is restarted, and therefore it is recommended to add this command to a startup script.