Changing Run-Time Properties
Go Up to IBConsole - Performance Guidelines
- Classic Architecture
- Classic System Configuration Parameters
- Superserver Architecture
- Cache Size
- Client Map Size
- Priority Class
- Working Set
Contents
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
InterBase includes the Superserver Architecture on Windows platforms. 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.
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.
Working set is only relevant on the Windows version of InterBase.
Using the Windows 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.