This documentation supports the 20.02 version of Remedy Action Request (AR) System.

To view an earlier version, select the version from the Product version menu.


Setting the Preload Tables Configuration option

The AR System server loads the cache from the database at the following times:

  • (All servers) At server startup
  • (Non-administrative servers in server groups) At runtime whenever the administrative server in a server group signals that it made a change to the cache

The Preload Tables option allows the server to make better use of system resources, such as multiple CPUs and network bandwidth, when loading the cache during server initialization and in server group operations. Using the Preload Tables option, can greatly reduce server startup time and the time required for cache reloads in a server group, but it requires that larger amounts of memory are available to the AR System server. This option preloads metadata from database tables into the server cache. The metadata includes field definitions and display properties.

Setting preload threads and preload segments

When the Preload Tables Configuration option is off, a single thread loads information directly from the database into the cache.

When the Preload Tables Configuration option is on, the server uses multiple threads running in parallel (preload threads) to load data in segments from database tables into memory.

Each preload segment represents one or more schemas (forms). For example, if you have 3,000 schemas and you configure 300 preload segments, each segment represents 10 schemas. In that case, a preload thread reading a segment of the field definitions table would process field definitions for 10 schemas.

Because all forms do not have the same amount of data, configuring multiple preload segments for each preload thread enables threads to balance their load effectively. For example, if you configure only one segment per thread and some threads finish before others, the finished threads have no more work to do. But if you configure multiple segments per thread, as a thread finishes loading one segment, it can begin loading another.

Each thread uses a separate connection to the database. Any thread can load any segment. When a thread finishes loading a segment, it begins loading another segment. When all segments have been loaded, the thread terminates.

After the segments are loaded, the server populates the cache by reading the information from memory instead of directly from the database.

You can configure the server to use preload threads at either of these times:

  • Only at server startup
  • Whenever the server loads its cache from the database

To configure preload threads, use the Preload Tables Configuration option on the Advanced tab of the Server Information form.

Important

After you start AR System server, the server ignores the value that is defined for the number of threads in the Num-Preload-Threads parameter and instead starts with 10 threads. The server also ignores the value that is defined for the number of segments in the Num-Preload-Schema-Segments parameter and instead starts with 150 segments.

The Preload Tables Configuration option is on by default for 64-bit UNIX or Linux servers. It has the following default settings:

  • Preload Tables at Init Only — No
  • Number of Preload Threads — 20
  • Number of Preload Segments — 300

To turn this option off, set Number of Preload Threads to 0.

This option is off by default for Windows servers.

Note

If you configured the Preload Tables Configuration option before applying patch 001, the patch installation does not change your settings.

Determining the optimum preload settings

Using preload threads can greatly reduce server startup time, but it temporarily increases memory consumption.

If you use preload threads, start with the following settings:

  • Ten preload threads
  • One preload segment for every three schemas (forms) on the server

To determine the optimum settings in your environment, vary the number of preload threads and segments to find the configuration that produces the fastest cache load time. Adjusting the number of preload segments balances the load between the preload threads.

Such testing also helps identify the amount of preload memory required in addition to cache memory.

Note

Initial testing of this feature at BMC Software indicates that a Unicode server with the full ITSM suite and all language packs installed consumes about 500 MB more memory at initial cache load when it uses preload threads than when it does not use preload threads.


When determining whether to use preload threads and how to configure them, consider the following factors:

  • The amount of memory available to the AR System server at startup and at runtime.

    Best practice

    • We recommend that servers with 64-bit address spaces and plenty of memory be configured to use preload threads anytime the cache is loaded from the database (Preload Tables At Init Only = No).
    • We recommend that servers with limited memory, such as Windows servers with 32-bit address spaces, be configured to use preload threads only when the cache is initially loaded from the database (Preload Tables At Init Only = Yes).
    • In the case of extremely limited memory, configure the server not to use preload threads

  • Whether the server is part of a server group. Non-administrative servers in a server group load the cache from the database whenever server object changes occur. These servers derive the most benefit from using preload threads for all cache loads.
  • The number of database connections available. Each preload thread uses one connection to the database.
Was this page helpful? Yes No Submitting... Thank you

Comments