When Blueworx Voice Response slows
down, check the following:
- Is the AIX operating environment set up correctly?
- Blueworx Voice Response requires
two AIX resources to run quickly: page space (for swapping software
into and out of memory) and processes. The parameters that control
how much page space the system can use and how many processes it can
start might not be set correctly. Use the information provided in Analyzing the problem to determine how much page space
is defined and the maximum number of processes the system can start.
The
system should have a minimum of 100 MB of page space. Use the information
given in Blueworx Voice Response for AIX:
Installation to increase the amount of page space.
The
optimum value for the maximum number of user processes parameter differs
from system to system. Generally, you should set the maxuproc parameter
to a number equal to 150, +1 for every telephone channel to which Blueworx Voice Response is connected
and +3 for each 3270 session that is defined. For example, if your
system has 24 telephone channels and 24 3270 sessions, maxuproc must
be set to at least 246. When you have determined the minimum acceptable
number, round it up to the nearest hundred. Then use the information
provided in Blueworx Voice Response for AIX:
Installation to reset the maxuproc parameter.
- Is enough disk space available?
- Blueworx Voice Response requires
a minimum amount of free disk space to avoid performance problems.
Ensure that your system has enough disk space in /home for your applications,
and that you have enough space in /var (see “Ensuring you have
enough space for the new software” in Blueworx Voice Response for AIX:
Installation.)
Use the information provided in Analyzing the problem to find out whether your system
has enough free disk space. If there is not enough, clean up the file
systems and recover disk space. If you still do not have enough space
available, you might need to get additional disk space on the system.
For
more information on managing disk space, see Blueworx Voice Response for AIX:
Managing and Monitoring the System.
- Is there enough real memory (RAM) available?
- Without adequate available memory, Blueworx Voice Response runs
very slowly. The more RAM that is available, the more quickly the
system responds. For example, a system with 48 channels and no 3270
sessions needs at least 128 MB of RAM. A system with 72 channels and
the same number of 3270 sessions should have at least 256 MB of RAM
for optimum performance.
To find out how much RAM is on your system,
log on as root, type lsdev -C | grep mem, and press Enter.
If you do not have enough RAM, you may have to add more.
Always
ensure that the amount of page space that is defined exceeds the amount
of RAM fitted in the Power System. Otherwise,
you might not be able to access all the RAM.
- Are there enough buffers?
- Blueworx Voice Response uses
buffers for voice segments and other state table components. It also
uses them to pass data backwards and forwards between internal processes
and servers. You need enough buffers to handle the permitted number
of simultaneous calls. The number of buffers is affected by the number
of state tables, prompts, and servers that are in use and by the number
and type of voice segments (compressed and uncompressed). Symptoms
that indicate insufficient buffers include the system running slowly,
and the system not handling or answering calls correctly.
Use the
information provided in Blueworx Voice Response for AIX:
Configuring the System to redefine the number of buffers.
- Are buffers released quickly enough?
- Blueworx Voice Response releases
buffers that are holding voice segments according to how long the
segment has been in memory since it was last requested. If the parameter
that controls this timeout is set too high, Blueworx Voice Response might
not be able to release the buffers quickly enough.
Use the Configuration —>
System Configuration —> Application
Server Interface menus to find out the value of the Time
in Cache parameter and reset it.
- Is the DB2® buffer large enough?
- If the DB2 indexes have grown too large to be held in the DB2
buffer, Blueworx Voice Response has
to access the hard disk every time it needs to look up information
in the database. This is far slower than accessing the buffer directly,
and can cause long delays. This problem is most likely to occur on
voice messaging systems or systems that have large numbers of Blueworx Voice Response objects.
As
dtuser,
type the following commands to increase the size of the DB2 buffer
pool:
db2 connect to dtdbv230
db2 alter bufferpool ibmdefaultbp size n
where
n is
the new size of the buffer pool in 4 KB units. The default is 1000
(4 MB).
Try increasing the buffer to 32 MB (n=8000)
at first, or to 128 MB (n=32000) if more space is needed.
- Is the database manager timing out too quickly?
- When the process that retrieves information from the database
times out too quickly, other processes that require the information
(such as voice applications) cannot complete their tasks. However,
they keep trying to access the database and failing, thus using system
resources and slowing down the system.
You should set the database
timeout parameter, DBIM Time Out, to a value of 240 seconds. Use the
information provided in Blueworx Voice Response for AIX:
Configuring the System to check the value of this performance
parameter, and reset it if necessary.
- Is there a deadlock between Blueworx Voice Response and DB2?
- The following are common causes of deadlock problems:
- Runstats are not being run regularly on the database server.
If db2_runstats script is not run periodically, the database queries
become slower, and eventually lead to deadlocks. The script should
be set to run when 25% of the data in the database has been changed.
It is particularly important to run it when a high number of subscribers
are added to the database, or when a significant change is made.
- Ensure that DB2_RR_TO_RS is set to ON. To check this, enter the
following commands:
- Login as root
- su - dtdbbvr
- db2set
If the value is not set to ON, enter DB2_RR_TO_RS=ON to
set it. Then log in as dtuser and enter the following commands to
get the value to take effect:
- db2stop force
- db2start
- Are you using SSI?
- If you are using single system image:
- Use the monitoring tools to ensure that the network is not overloaded.
See the section about monitoring the performance of a single system
image in Blueworx Voice Response for AIX:
Configuring the System.
- Use the standard AIX monitoring tools to ensure that the server
(the database server or the voice server) is not overloaded.
- Use the DTmon -f command to check performance statistics. For
information about the DTmon command, see Blueworx Voice Response for AIX:
Managing and Monitoring the System.
- Is the var file system filling up
- By default, when the JVM experiences a problem, a javadump file
is created in the /var/dirTalk/DTBE/native/aix directory.
To stop the var file system filling, it may be necessary to configure
the system so that the javadump files are generated in a different
location. To do this, export the following environment variable:
IBM_JAVACOREDIR=path to javadump
where path
to javadump is the new location. For a Blueworx Voice Response installation,
this variable should be set in $VAE/sw/environ/.vaeprofile.user