Changing Run-Time Properties

From InterBase

Go Up to IBConsole - Performance Guidelines


Classic Architecture

Prior to version V4.1.0 of InterBase, the server was designed in a way that is now called the Classic Architecture. In this design, each client connection to the server spawns a separate process. Each process does I/O directly to the database files, and negotiates access to the database files by interprocess communication methods like semaphores. The parameters are contained in the system configuration file, isc_config for Unix platforms, or IBCONFIG for Windows.

Each of these server processes also keeps a cache of database pages in its own address space. The cache contains data pages, index pages, BLOb pages, and all other pages that the process reads from the database and may have to write back to the database.

The size of the cache is tunable programmatically, as an entry in the database parameter block to the InterBase API function isc_attach_database. Cache can also be specified using the CONNECT statement option CACHE.

The size is specified in database pages. By default the size is 75 pages. Increasing the cache can decrease the frequency of I/O operations that are required as the client does database operations. But this is a tradeoff with the memory requirements of the process. 60 processes that each have 300 2Kb database pages use over 35 Mb of memory. At some point, the cache can no longer be kept in physical RAM and it begins swapping out to virtual memory. When the cache pages are being swapped to the hard disk, the benefit of having a cache at all is defeated. Your InterBase cache size should be tempered with the amount of physical RAM on the machine in mind.

Also note that if you increase the page size of the database, the actual memory used in the cache is increased proportionally. The cache is configured in number of database pages, not in kilobytes. This principle holds for the Superserver cache as well.

Classic System Configuration Parameters

Parameter Factory Setting
V4_LOCK_MEM_SIZE 98304
V4_LOCK_SEM_COUNT 32 ( 25 on some platforms)
V4_LOCK_SIGNAL 16 (do not change this entry)
V4_EVENT_MEM_SIZE 3278
V4_LOCK_GRANT_ORDER 1 (on) [This parameter parameter may be included in the configuration file.]

The file also contains ANY_LOCK_MEM_SIZE, ANY_LOCK_SEM_COUNT, ANY_LOCK_SIGNAL and ANY_EVENT_MEM_SIZE. These parameters are not version specific and are reserved for future releases of the product.

These parameters are contained in the file isc_config for Unix systems or IBCONFIG for Windows based systems. The file is located in the InterBase installation directory (/usr/interbase by default) and can be accessed using a text editor.

V4_LOCK_MEM_SIZE

The size required is based on the number of users and the size and complexity of your database. If you receive a shared memory error, double the setting for V4_LOCK_MEM_SIZE.

Memory requirements are computed are based on the following:

90 bytes for each buffer, relation, database, and concurrent transaction.
36 bytes for each process attached to a database.
388 bytes for the lock manager.

On platforms where the lock table expands dynamically, this parameter does not need to be changed. On platforms where the lock table is static, you may need to increase the default setting.

If an InterBase application requires more than V4_LOCK_MEM_SIZE shared memory for locking, then InterBase will return the fatal lock manager error

not enough shared memory

V4_LOCK_SEM_COUNT

Defines how many semaphores are used by the lock table. Maximum allowed, 65,536.

  • The V4 lock manager requires 25 or 32 semaphores, depending upon the platform.
  • One semaphore is required by the event manager if applications running at your site use Events.
  • If V3 databases are being used on the server, an additional 32+1 semaphores are required.

If an InterBase application requires more than V4_LOCK_SEM_COUNT semaphores for locking then InterBase will return the fatal lock manager error

semaphores exhausted

V4_LOCK_SIGNAL

Do not change this entry. This defines the signal number used by InterBase.

V4_EVENT_MEM_SIZE

You do not need to change this entry. If the events table expands dynamically on your platform this is the starting size for the events table. If the table is static, this is the maximum size for the events table.

Superserver Architecture

Local InterBase V4.1 introduced the Superserver Architecture on Windows platforms. A version of Superserver was implemented for InterBase V4.0 on NetWare. Superserver is now included in InterBase Server V4.2 for Windows and InterBase Server V4.2 for NT. In this design, all client connections are associated with one server process. This server process keeps a database page cache for all clients to share. The parameters are contained in the system configuration file, IBCONFIG.

Cache Size

The size of the Superserver cache is tunable with the DATABASE_CACHE_PAGES parameter in the IBCONFIG file (in the directory \Program Files\Embarcadero\InterBase by default). New database attachments may specify a larger cache size programmatically, as in the Classic architecture. These may cause the Superserver cache to expand beyond 256 pages, and this is accomplished as the client attaches.

Client Map Size

A memory-mapped file is used for interprocess communication on the server. Each client attachment gets a segment of the file equal to the client map size in bytes. The file is initially 10 times the client map size. Additional clients attaching and detaching will cause the file to grow and shrink by 1 increment of the client map size. This is tunable with the SERVER_CLIENT_MAPPING keyword in IBCONFIG. This configuration takes effect when the InterBase server restarts.

Priority Class

The superserver process may be given a relative priority class, to allow it to demand more system resources. There are two options through the InterBase interface, Low (1) or High (2). This parameter is specified by the keyword SERVER_PRIORITY_CLASS in IBCONFIG. This configuration takes effect immediately.

Note:
On Windows NT, the screen saver process does not run at a reduced priority. When running a screen saver that is computationally expensive, such as the OpenGL screen savers demos, all other services running on the NT machine suffer in performance as they compete for CPU resources. Some measurements have indicated that InterBase slows to one tenth of the speed it is capable of. One should disable screen savers on database servers. Or at least configure the screen saver to be a simple black screen

Working Set

This refers to the set of RAM dedicated for the InterBase process. The minimum working set size specifies the amount of physical RAM that is guaranteed for the InterBase process. The system may swap out memory in excess of this figure. The maximum working set size specifies a threshold above which memory used by the InterBase process will be swapped out to virtual memory.

Note:
Working set is only relevant on the Windows NT version of InterBase.

Using the Windows NT Performance Monitor, a database administrator should watch for excessive Page Faults. Raise the minimum working set size in this case. If memory resources permit, set the minimum working set size to at least the amount of cache allocated for the InterBase server. Certainly the maximum should be greater than the size of the InterBase cache, so the cache is not forced to swap.

The default values are zero for both minimum and maximum. This is a special case in which the system determines the working set for the InterBase server process. Both values must be less than the amount of physical RAM on the machine. The minimum must be less than the maximum. These parameters are specified by the keywords SERVER_WORKING_SIZE_MIN and SERVER_WORKING_SIZE_MAX in IBCONFIG. This configuration takes effect when the InterBase server is restarted.

Advance To: