Monitoring queues for Db2 Text Search index updates

You can gather monitoring information to tune the Db2® Text Search server configuration if you experience indexing performance issues.

You can monitor input and output queues by starting the Db2 Text Search server with the -monitorQueues flag. When you start the server with the -monitorQueues flag, information about the current state of the input and output queues is printed to the InputQueueSizes.csv and OutputQueueSizes.csv files. These files are stored in the ECMTS_HOME\logs directory. Each file provides the following information:
  • The time.
  • The current number of documents that are waiting to be preprocessed and indexed.
  • The number of documents that are currently being preprocessed and indexed.
  • The current queue size. The maximum queue size is a configurable parameter.
  • The total number of documents that passed through the queue, that is, the number of documents that were preprocessed and indexed since the last server startup.
  • The amount of heap memory in MB that is used by the JVM before Java™ memory garbage collection.
  • The number of threads that are used by the Db2 Text Search server.
  • An indication of the average system load for the previous minute and free physical memory, as provided by JVM.
  • The number of open operating system file descriptors. This information is available only for AIX® and Linux® systems.
  • The number of index segment merges that are currently taking place.
  • The total size (in MB) of index segment merges that are currently taking place.
Important: The CSV files are re-created each time that the server is started. If you want to store the information in these files, back them up before you restart the server.
To start the server in monitor queue mode:
  1. Stop the server.
  2. Edit the startup script in the ECMTS_HOME\bin directory.
  3. Add the -monitorQueues flag to the startup command. For example:
    "%JAVA_HOME%\bin\java" -classpath "%CLASSPATH%"
com.ibm.es.nuvo.launcher.Launcher "%CONFIG_XML%" -monitorQueues
-Xmx%HEAP_SIZE% %1 %2 %3 %4 %5 %6 %7 %8 %9 %IPv6Flag% %JVM_OPTIONS%
  4. Save the startup script and restart the server.


Use the information in the following table to troubleshoot indexing performance that is based on queue status.

Table 1. Troubleshooting indexing performance based on queue status
Queue status Troubleshooting strategy
Input queue is empty Documents are not being received from the client. Ensure that the client is pushing documents fast enough to the server.
Input queue is full, output queue is empty Check the logs for preprocessing errors and consider increasing the number of preprocessing threads. Low CPU levels (less than 60%) on servers in a large multiprocessor system can also indicate that the number of preprocessing threads must be increased. The number of preprocessing threads must not exceed the number of processors. In a distributed architecture, ensure that each preprocessing server is running and is configured correctly. For example, verify that the connection parameters (indexing server host name, port number, and token) are configured correctly on each preprocessing server. You can check the connectivity by monitoring the input queue on each preprocessing server to ensure that documents are received. You can also try to increase the number of preprocessing threads on each preprocessing server.
Both input and output queues are full Try one or more of the following strategies:
  • Increase the number of index threads.
  • Configure more frequent, shorter merges by reducing the value of the MaxMergeDocs parameter in the ECMTS_HOME\config\collections\collection_name\collection.xml file.
  • Increase the batch size. Indexing documents in small batches can degrade performance, because the index is flushed and saved to disk for every batch that is indexed.
  • Increase the BufferSize parameter in the ECMTS_HOME\config\collections\collection_name\collection.xml file.
  • Index one collection at a time.
  • Ensure that the disk speed and network connection is fast enough.