This documentation applies to the 8.0 version of Remedy Action Request System, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Tuning FTS for performance and stability in a server group

You can obtain a considerable increase in performance, reliability, and FTS system stability by using the preferred method of configuring BMC Remedy Full Text Search (FTS) in a server group instead of the previous deprecated method explained in Configuring full text search for a server group. This method is applicable from BMC Remedy AR System 7.6.04 versions and later.

In the previous deprecated method for configuring FTS for a server group, each instance of the FTS plug-in resides locally on its instance of the BMC Remedy Action Request (AR) System server. They all point to a central network location at which the index resides. All instances of the FTS plug-in must communicate with the index files over the network, which creates a performance bottleneck.

The AR System server can communicate with an AR System plug-in located in any location on the network. They need not be local to one another. To communicate, the AR System server makes remote procedure calls (RPCs) to the configured plug-in server.

However, you can greatly increase performance by placing all instances of the FTS plug-in and the index files local to each other. In this arrangement, the index-intensive activity happens locally instead of over a network. Each AR System server then makes an RPC call to the appropriate FTS plug-in over the network, which is much less intensive and does not depend on disk activity.

If the AR System server or the Primary FT Indexer server goes down, the entire FTS goes down. The Readers cannot search the data directly, due to file system unavailability.

Use the following configuration to achieve optimal performance and stability.

Configuring FTS in a server group for performance and reliability

Note

Perform the following steps to configure your BMC Remedy AR System 8.0.00 or previous configurations to upgrade to use the two FTS plug-ins configuration.

To configure FTS in a server group for performance and reliability, use two instances of the FTS plug-in on the FT Indexer server (Primary) in the server group, and place the FTS index on the FT Indexer server's local drive. Designate the two plug-in instances as primary (Writer) and secondary (Reader). The writer instance is connected to the Primary FT Indexer server whereas the reader instance runs on the Primary FT Indexer server but on a separate port. All servers except the Primary FT Indexer server should connect to this instance. The Primary FT Indexer server should connect to the Primary/Writer instance of the FTS plug-in alone.

To convert an old FTS configuration to use the two-plug-in configuration

Note

Perform these steps after the servers are shut down or according to the change controls implemented in your environment.

  1. Select a server to be designated as a primary FTS server and ensure that:
    • The Collection directory is available on a local drive on this server.
    • Both instances of the FTS plug-in are running on this server.
  2. Configure the port numbers for the two plug-in instances.
    For the primary plug-in instance, assign 9998, and for the secondary instance, assign 9988.
  3. Ensure that the Conf and FTSCollection directories are on the local drive and that they have sufficient disk space, approximately six times more than their existing size.
  4. Ensure that the system has sufficient memory to run all the FTS plug-ins, approximately 2.5 GB to 3 GB per instance.
  5. Prepare the new FTS plug-in instance directories on the designated primary FTS server.
    The FTS plug-in server is located in the .../pluginsvr/fts directory. Create the following subdirectories under the ftsdirectory:
    • ../fts/core
    • ../fts/primary
    • ../fts/secondary
    1. Copy the two JAR files (ftspluginVerNum.jar and tika-app-0.6.jar) located in the fts directory to the new core directory. (VerNum represents the release version number.)
    2. Copy the two XML files (pluginsvr_config.xml and log4j_pluginsvr.xml) located in the fts directory to the new primary and secondary directories.
    3. Edit the ../primary/pluginsvr_config.xml and ../secondary/pluginsvr_config.xml files to ensure that the paths reflect the new locations of the JAR files, the collection and conf directories, and the stop file (arsfts.stp).

      Note

      Ensure that the stop file exists in the ftsconfiguration/conf directory. The stop file is a list of words that are ignored by full text search and is configurable.

    4. Edit the port number in the ../secondary/pluginsvr_config.xml file and assign 9988 as the port number.
    5. If threads for the FTS plug-in server are modified from the default settings, revert the number of threads to their out-of-the-box default values in both primary and secondary pluginsvr_config.xml files. (By default, 5 core threads and 2 selector threads are available.)
    6. Edit both the ../primary/log4j_pluginsvr.xml and ../secondary/log4j_pluginsvr.xml files to append -primary and -secondary to the output files names. For example:

      <appender name="PluginLog">
        <param name="File" value="C:/Program Files/BMC Software/ARSystem/ARServer/Db/arftsplugin-primary.log"/>  
      <appender name="FTSLog">
        <param name="File" value="C:/Program Files/BMC Software/ARSystem/ARServer/Db/arfts-primary.log"/> 
      
  6. Edit the Full Text Indexer rankings in the Server Group Operation Ranking form to rank only the selected primary FTS Server for FTS. For more information, see Setting failover rankings for servers and operations.
  7. If you did not shut down the AR System servers at the beginning of this procedure, all the AR System servers must be shut down now.
  8. If the Collection and conf directories are not local to the primary FTS server, copy these files to the primary FTS server.
    If you are planning for a re-index, you can skip this step.
  9. On the primary AR System server, edit the ar.conf/ar.cfgfile as follows:
    1. Change the paths of the Full-Text-Configuration-Directory and Full-Text-Collection-Directory settings to reflect the correct paths.
    2. Ensure that no entry exists for the Private-RPC-Socket: 390602 setting or that it is commented out.
  10. On each AR System server except the designated FTS Indexing server, perform the following steps:
    1. Comment out the entry of the armonitor.conf/armonitor.cfg line that starts the FTS plug-in locally.
    2. Edit the plug-in alias in the ar.conf/ar.cfg file to use the primary FTS server name and the new port selected for the secondary FTS plug-in instance.
    3. Edit the ar.conf/ar.cfg file by changing the paths for Full-Text-Configuration-Directory and Full-Text-Collection-Directory to reflect the correct paths (that is, the same as edited in pluginsvr_config.xml files for these two items)

      Note

      These will be the same values on the primary server. These values are what the primary server sees and not the local server.

    4. Ensure that no entry exists for the Private-RPC-Socket: 390602 setting or that it is commented out.
  11. On only the designated primary FTS server, edit the armonitor.conf/cfg file to do the following:
    1. Fix the FTS path by appending /primary to the /fts, followed by a semicolon and the new full path to the core directory. For example, /fts/primary.
    2. Copy this line and change /fts/primary to fts/secondary.
  12. If a copy operation was started in step 8, ensure that it is completed before continuing.
  13. Restart only the primary FTS server, ensure that is running and processing the ft_pending records, if any.
  14. Restart the AR System servers.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments

  1. Jan Sierens

    What is the impact if the primary server goes down?

    Jul 31, 2014 07:25
    1. David Baldwin

      Restate:  What is the impact if the primary server goes down?

      In versions other than 7.6.04 SP5 and 8.1 SP1(and later) and assuming best practices is implemented, indexing requests will queue up till the primary server is brought back up.

      In 7.6.04 SP5 and 8.1 SP1(and later) if HA (high availability) has been implemented, the redundant/backup/2nd indexing server will take over till the primary is back up.

       

      Jul 31, 2014 09:15