Knowledge Base

Knowlegebase articles

Welcome to SysOrb knowledge base. Her you will find detailed explanation on questions regarding SysOrb. The list is under continues development and new articles will be added. You can follow the links below or enter a "key word" to search all of the articles.

Basic database tuning

Symptoms: 

The SysOrb web interface responds slowly. Node class updates, grid synchronization, report generation and other database intensive operations either take too long, or cause unacceptable web interface performance.

Cause: 

The SysOrb database has a fixed (but configurable) size cache, to help it more quickly access database objects without having to go through the operating system to access the database files on disk or in the operating system cache. The size of the cache is a tradeoff; a too small cache will not give acceptable caching effect (poor hit rate and no performance benefit), a too big cache will use up too much system memory and cause other parts of the system to be paged out to disk again causing unacceptable system performance.

SysOrb installations vary greatly in size and complexity; if you run a larger SysOrb installation it is quite likely that the default database caching parameters are too conservative. You may not be getting the caching performance that you could expect.

Resolution: 

First, we must establish the current cache hit rate. It makes no sense to change variables without knowing their potential effect. In order to read out metrics from the SysOrb Server, we must use the command line tool named "sysorb-tool" which is installed under the SysOrb Server installation directory. This tool is available on all supported SysOrb Server platforms and its use is identical. It is assumed in the following, that the administrator has a command line with access to the sysorb-tool command. It is further assumed that the login name of the administrator is "admin"; this must be changed in the command line examples accordingly.

Run the command:

 sysorb-tool -l admin mm dbms.buffercache.hits dbms.buffercache.misses  dbms.objcache.hits dbms.objcache.misses
 Password: 
 Got 4 metrics
 -       -       -       -
 239     117      2864    0
 109     57       1462    0
 894     70       11857   1
 825     809      5955    0
 359     900      3039    0
 1238    1106     13833   1
 622     1158     4939    0
 91      903      1458    0
 11967   508      35594   0
 979     51       9223    0
 11509   44       25479   0
 651     98       9084    0

You must press Control-C to stop the sysorb-tool printout.

There are two different caches in the SysOrb object database. The first two columns represent hits and misses in the first cache (named the "buffercache"), the last two columns represent hits and misses in the last cache (named the "objcache"). From the above output it is very clear that there are many misses compared to the number of hits in the first of the two caches. It would therefore be beneficial to increase the size of this first cache, the "buffercache".

These cache configuration options are either found in the configuration file "server.conf", or, on Windows platforms, in the registry under "HKEY_LOCAL_SYSTEM\Software\SysOrb\SOServer". If a registry key is missing, simply create a new "String", name it as the configuration option and edit it to contain the value desired - look at the other keys already there, if in doubt. In the following we shall simply refer to configuration options by their name and value.

The size of the "buffercache" is controlled by the configuration option named "dbms_buffer_blocks". This option is by default set to 4099, which means the database will hold 4099 8KiB blocks (32MiB total) of data. If the main.odb file is many times larger than this, it is quite likely that the size of the dataset that is frequently worked on by the database is a greater than these 32 megabytes. Our sysorb-tool diagnostics above indicate that this is indeed the case. We could try simply dobuling the size of this cache. To do this, create (or edit) the configuration option named "dbms_buffer_blocks" and set it to 8191 instead of 4099, thus effectively doubling the size of the cache. After this change, the SysOrb Server service must be re-started.

After such a change, we should once again inspect the performance metrics. Let the server run for a while to give it a chance to "warm" the caches. All caches will have near 0% hit-rate when a system is just starting up - monitoring the performance of the SysOrb Server caches (or any other cache for that matter) therefore makes no sense in the first few minutes after a system has been restarted. Like in the previous example, we inspect the hit rate of both caches:

 sysorb-tool -l admin mm dbms.buffercache.hits dbms.buffercache.misses  dbms.objcache.hits dbms.objcache.misses 
 Password:
 Got 4 metrics
 -       -       -       -
 772     0       5551    0
 11758   0       27500   0
 818     0       9312    0
 1554    0       20063   0
 87      0       480     0
 11714   0       25429   0

Problem solved. There are now no misses in the buffercache. It is important to acknowledge that it is perfectly normal to have cache misses. It is very unusual that the 'misses' column shows 0 for so long; however, the amount of misses should be in 0-10% range, not close to (or above) the number of hits.

If instead it was the second cache, the "objcache", that was too small, the configuration option "dbms_cache_size" would have to be increased. This option is set to 50000 (fifty thousand) by default. In order to increase this cache, again try simply doubling this number. This configuration option is not present by default in either the registry (on Windows) or the server configuration file (on UNIX and Linux systems). Like with the other configuration options, the SysOrb Server service must be re-started when this option is set.