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.
- Agent crashes
- Automatic rescan of all nodes in a domain
- Bandwidth consumption estimate
- Basic database tuning
- Can I customize the reports in SysOrb?
- Disabling specific checks
- Does SysOrb support SNMP traps?
- Explanation of the score keeper strategy.
- How does HTTP Netcheck work in SysOrb?
- How to automatically update alert group on all nodes to “As domain”
- How to backup SysOrb database
- How to change time interval value of agent_checkin_delay
- How to move the SysOrb server to a new server
- How to quickly set downtime on an agent
- I cannot get all of the "performance counters/cache" entries to appear in SysOrb what should I do?
- Migrating MIB information from one SysOrb installation to another
- Migrating the configuration of a Windows SysOrb server from 32 to 64 bits
- No empty blocks in meta database.
- Script to get a list of nodes which have no AlertGroup
- SysOrb agent is not checking in to the Sysorb server
- SysOrb agent stops checking in from a windows server with very long system uptime
- SysOrb server shuts down unexpectedly
- System uptime no longer updates on windows
- Unable to monitor hardware (fans, disks, temperatures etc.) on Windows
- Upgrading SysOrb on Windows
- Uploading a SysOrb database to Evalesco
- What does KiB and MiB mean?
- What is IPMI ?
- Windows agent late for check-in every hour
Basic database tuning
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.
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.
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.
