Category: ZIM Application Server

Starts and stops the Zim Server program.

Linux Syntax

[nohup] zimserver [-k] &

Windows NT Syntax

[start] zimserver [-k] [-i] [-s [-e] [-u]

Parameters

Comments

Before starting Zim Server, ensure that the ZIM environment variable is set to point to the directory where ZIMSERVER was installed.

ZimServer must always be started with the Administrator’s (root) privileges.

Tracing and logging information is outputted to zimsvlog.zim.

After starting Zim Server, you should see a message stating that Zim Server has started or it has failed to start. In the latter case, you can check the reason for Zim Server not starting in zimsvlog.zim.

When stopping Zim Server, a message will follow indicating that Zim Server was terminated.

WARNING: Always stop Zim Server using the -k parameter. If you do it in a different way, Zim Server might not be able to finish an ongoing checkpoint of committed transactions to disk. Depending on the size of some configuration parameters, the checkpoint procedure might take several seconds after all transactions have finished and after all users have been disconnected. Even though the next time you start Zim Server it checks for unfinished checkpoints (and finishes them), if you copy or backup files from the database at this point you might get files in an intermediary and inconsistent state.

To make sure that your databases are consistent in case you mistakenly stopped Zim Server not using the correct procedure, just start Zim Server again and then stop it in the recommended manner.

UNIX

ZIMSERVER can be started by manually entering the above command or the command line can be inserted into your system’s start-up script. ZIMSERVER should always be started using NOHUP. NOHUP ensures that the Zim Server process continues to run even if you log out. The ‘&’ at the end of the command line enables you to enter more commands at your terminal after the server has been started.

If you use NOHUP, some special output from ZIMSERVER goes to a file called nohup.out located in the directory that was current when the NOHUP command was executed. As with the file zimsvlog.zim, nohup.out is always added to and can become very large. You should check its size from time to time, archive it (if you wish), and erase it. The NOHUP also allows you to close the Unix session without exiting ZimServer as well, that is, ZimServer keeps running in the background, provided that you have used the symbol “&”.

Windows

The server can be started from a shortcut on the desktop, in a text console window, or using the start command from a console window. When using any of these startup methods, the output is displayed in the startup window.

Also, Zim Server can be installed as a Windows Service using -i parameter. After installing Zim Server a Windows Service, you can control Zim Server from the Services window or from the command prompt.

net start zimserver                    To start the service from the command prompt

net stop zimserver                     To stop the service from the command prompt

PLEASE NOTE: If you start ZimServer as a service you should use the service option to stop the server instead of using the -k parameter.

To remove ZimServer from Windows services you will need to use -u parameter.

The zimsvlog.zim file

The log file zimsvlog.zim, located in the directory pointed to by the ZIM environment variable, records all events happening with Zim Server like, its start, its end, errors, tracing, and other information.

You can browse its contents using a text editor or using ZIMEXPLORE.

After some time using Zim Server, this file can become very large. You should check the size of it from time to time, archive it (if you wish) and erase it. It can be erased at any time, even when Zim Server is running. Next time Zim Server needs to log some information, the file will be recreated.

Viewing the Server Log

The Server Log utility displays the contents of the Zim Server log file: zimsvlog.zim.

The column headers in the Server Log grid are described in the table below:

Filtering the Log

Right-click on Server Log and then click on Filter to access the server log filter

The Log File Filtering dialog will pop-up. Use it to limit the number of and the types of messages displayed in the Server Log grid.

Limiting the number of lines displayed in the log file

The following drop-box options are available to limit the number of lines displayed in the log file: (Last 500 lines; Last 1000 lines; Last 1 hour; Last 24 hours; Last 7 days; and Entire Log File );

Limiting the type of messages displayed in the log file

The following options, described in the table below, are used to enable or disable the displaying of specific types of messages:

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.

This option is not used by Zim Server and might be removed in future releases.

datablock timeout milliseconds

The time milliseconds indicates how long a buffer is going to stay in memory before Zim Server can use it to make additional room for new buffers being read.

When a Zim session make a request to Zim Server to read a particular block of data, depending on the configuration option Blocks Per Read, more than one block can be read and stored in memory buffers, all in the same operation because a physical read operation brings more than one block at a time.

If, sometime later, these additional buffers are required for subsequent operations, these blocks will be found in memory thus saving physical read operations. However, because they can take space from useful blocks, they are marked to expire in the next milliseconds set by this configuration option.

This very same mechanism happens when a transaction is either committed or aborted. In these cases, if a particular buffer is no longer used after the commit or the abort, then the corresponding buffer is also marked to expire as above.

The smaller the number of milliseconds, the faster a buffer can be released from memory in case of need. This is particularly interesting for very active applications or for small number of Maximum Data Blocks.

Valid Settings

Range between 0 to 60.

checkpoint buffers buffers

The option buffers indicates how many buffers must be written to the temporary log file before performing a checkpoint that commits ongoing transactions to disk. If this limit is reached while transactions are in process, the checkpoint will happen only after all transactions have finished to guarantee atomic transactions.

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

If the number of buffers is big, ZIM Backup Server, if running, will take more time to perform the backup process.

Regardless of the number of buffers, 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.

The number of buffers should always be less than the half of the number of Maximum Data Blocks; if this happens, the number of buffers is adjusted accordingly.

Valid Settings

Range between 1 and 1000000.

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.

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 locks locks

The number of locks is the maximum number of locks that Zim Server can handle simultaneously. This means that the sum of all locks used in all ongoing transactions cannot exceed this number. Consequently, the larger the number of users, the bigger the number of locks needed, and, correspondingly, more shared memory will be required.

The utility ZimAdmin can help to monitor the number of locks actually in use. The initial line of action would be to accept the default number and then, by monitoring the usage of these locks, increase or decrease the value according to real needs.

Valid Settings

A number from 100 to 10,000,000.