Category: Zim Server Configuration

pending sleep milliseconds

When an object requested by some operation being performed by Zim Server is not available (for instance, locks, blocks, etc.), the request goes to a list of pending objects and stays in the list until the object request can be satisfied.

In this list, the object availability is checked every number of milliseconds.

If you want to minimize this delay, that is, to try making this object as soon as possible available for processing, set the value to 1. However, this will increase the consumption of CPU because Zim Server needs to check more often the availability of the resources needed and will also increase the level of competition between objects trying to get in the list with objects trying to get out the list. If your application performs well with a lower value (like the suggested of 1), than this should be your choice for this option.

This configuration options becomes more sensitive as the number of users in the system increases.

Valid Settings

Range between 1 to 999.

scatter table links nn

Number of links to blocks participating in transactions. This is the real size of the larger transaction possible in blocks for transactions that write blocks. For transactions that read blocks, these links can be reused within the same transaction.

After finishing the transaction, either by a normal commit or by aborting the transaction, these links can be reused by other transactions.

When running a Zim application, there are two possible situations:

1) a load session that creates large files. Usually, it is ran with a single user and occasionally when loading lots of data. These sessions require a large number of scatter table links;

2) normal sessions performing processing not considered as “bulk” processing. These sessions require a relatively small number of links.

The number nn must be greater than the number of Maximum Data Blocks.

Valid Settings

A number from 50,000 to 30,000,000.

checkpoint transactions nn

This option indicates how many transactions must be committed to the temporay log file before performing a checkpoint that commits ongoing transactions to disk.

The smaller the number of transactions, less efficient will be the overall performance of the system, but the databases involved will be more often updated.

If the number of transactions is big, ZIM Backup Server, if running, will take more time to perform the backup process. Also, depending on the number of buffers updated in each transaction, the temporary log file size can vary significantly.

Regardless of the number of transactions, in case of a disk crash, ZIM server will automatically recover all consistent transactions present in the temporary transaction file.

A checkpoint is triggered whenever the number of checkpoint transactions or the number of checkpoint buffers happens first.

Valid Settings

Range between 1 and 100000.

pending timeout cycles

When an object requested by some operation being performed by Zim Server is not available (for instance, locks, blocks, etc.), the request goes to a list of pending objects and stays in the list until the object request can be satisfied.

In this list, the object stays for the number of cycles until either the request is satisfied or the current transaction requesting the object is deadlocked. A cycle is a processing unit within the mechanism that controls the pending objects and it is usually a couple of milliseconds.

If you want to minimize this delay, set the value to a low number. Note, however, that the lower this number, the greater the chance Zim Server would deadlock again because the very small time frame associated to each cycle which might not find the resource available yet.

Valid Settings

Range between 0 to 1000000.

maximum data blocks blocks

This is the number of real blocks of data kept in memory at a given time by Zim Server to process transactions.

The bigger the number, the faster transactions will be because more data will be available all the time. Its number depends only on the available shared memory.

If users request more blocks of data in a single transaction than is possible to accommodate in memory, Zim Server saves least used blocks on disk and bring them back if they are again needed.

When a transaction finishes, blocks of data used in this transaction still remain in memory until they are reused or until their space is used by other blocks from other transactions.

Valid Settings

A number from 100 to 10,000,000.

maximum tables files

The number files indicates the maximum number of Zim files that Zim Server can process simultaneously for all databases.

Usually (but not always), a good indication for the maximum files in a particular database is to use the highest Zim file number (that is, ZIM0150, ZIM2010, etc.). In this case, 150 or 2010 can be the maximum files.

As an example, if Zim Server is currently controlling two databases, and one of them has 300 tables and the other one has 500 tables, then this configuration option must specify at least 800 files (a good number would 1000 in this case). By tables, it is meant entity sets and relationships with fields.

Valid Settings

A number from 100 to 32,000.

object timeout seconds

This time indicates how long Zim Server has to wait to acquire control over some objects (locks, buffers, etc.) that are not available in memory before deadlocking the current transaction.

The number of seconds is big enough to wait for the object to sleep, go to a pending list if necessary, and then be available for the transaction.

If you want to minimize this delay, set the value to 1. However, this will increase the consumption of CPU because Zim Server needs to check more often the availability of the resources needed. If your application performs well with a lower value (like the suggested of 1), than this should be your choice for this option.

Valid Settings

Range between 0 to 60.

scatter table entries nn

Maximum number of entries pointing to lists of blocks currently in use. Each entry corresponds to a block (located in memory) used by a particular user.

Each block is described by the configuration option Scatter Table Links. Every time a user uses a block, a table entry is used. Therefore, if more than one user are using the same block, each user allocates one table entry, but all of them point to the same table link.

The number nn must be greater than the number of Scatter Table Links.

Valid Settings

A number from 50,000 to 30,000,000.

quick locks locks

To set a lock on a specific block of data, Zim Server resorts to two levels of locking: first, it tries to set a very fast lock held on a small table of locks. This is the quick locks table with the size of locks. Then, if not possible, Zim Server uses secondary locks (refer to Secondary Lock Groups and Secondary Lock Group Size).

A quick lock table is maintained for each lock specified in Maximum Locks and keeps track of which users are responsible for each lock.

Valid Settings

A number from 5 to 100.

files per transaction files

This configuration option manages the number of files that a single transaction can handle within its scope. The parameter files actually indicates how many entity sets and relationships with fields can be processed in the same Zim command for implicit transactions or for all commands within the boundaries of a TRANSACTION and ENDTRANSACTION/QUITTRANSACTION commands.

If using roles defined over either an entity set or a relationship with fields, the roles and their corresponding real objects are counted only once.

Valid Settings

Range between 5 to 100.