Change Qserver Memory Setting

A possible factor causing performance issues is the occurrence of full GCs. The full GCs can be seen in the qserver.gc.log files. To avoid occurrences of full GCs the maximum heap size used by the qservers (Xmx value) needs to be increased by adjusting the Fredhopper Memory Settings.

The current Xmx value can be seen in the qserver.log in the JDK options line, like for example:

JDK options: (...) "-Xmx1500m" (...)

The Fredhopper Deployment Agent set-option command can be used to change memory and port configuration settings. For example, the following command will assign 4G memory to the query server:

bin/deployment-agent-client set-option <INSTANCE> "qserver_memory=4000"

More details are available in the article about the customization points.

The total configured memory of the FAS processes together should not exceed the total available memory in the machine. Considering a live server with 8G RAM, then reserve 1G for the OS and the qserver can get the remaining 7G. On an indexer the situation is slightly different, as on different moments, different processes are active. Either the data manager runs (so can get assigned a lot of RAM), or the xmlloader+treebuilder+searchindexer+syncserver+qserver run. Usually the defaults are OK for the indexer.

The amount of memory needed for a qserver depends on:

• The number of items, attributes and attribute values as these build static structures that are persistent for the qserver life time.
• The number of queries since startup, as queries are handled by Java threads and for each thread there are internal structures that use memory.
• The number of concurrent queries. Queries that run at the same time are handled by different threads each having their own memory space.
• Garbage collector, as this process removes obsolete objects. Caches and static data however cannot be removed. Its activity can be followed in qserver.gc.log. The occurrence of many "Full GC's" in a short time is a sign that the qserver needs more memory.