|
|
|
The Ingres client-server architecture allows multiple users access to databases through connections to one or more DBMS Server processes. The DBMS Server (iidbms) is a multi-threaded daemon process that performs asynchronous disk input and output. The number of users connected to a server is limited by hardware or the operating system.
Since it is unlikely that the default DBMS server configuration suits all users' requirements, the DBMS Server is usually configured to improve performance in a particular configuration. For a selected DBMS server definition, its buffer caches can be configured as well as other parameters and derived parameters.
DBMS servers can be configured to fit specific needs. For example, you can:
Some elements of the DBMS Server are described as facilities.
Note: Ingres preallocates most of the resources it requires. It may use hundreds of megabytes of virtual memory and allocate hundreds of thousands of handles; the use of these resources depends on the number and size of the page caches enabled.
For instructions on configuring DBMS server parameters, see the following topics in Configuration Manager online help:
|
|
|
The fast_commit option, which is derived DBMS Server parameter, allows the server to execute commits without forcing data pages to the database. This reduces I/O in the server and improves response time.
Without fast commit, all update transactions must do the following when a commit is executed:
This ensures that the data is committed and the data in the database has been written to disk when a system crash occurs immediately following a commit.
With fast commit, a server can perform a commit by writing a commit record to the log file and forcing it to disk. The actual data pages are not written to the database disk until an optimal time to do so is reached. If necessary, the committed transactions can be recovered from the log file that was written to disk.
Fast commit can greatly improve transaction response time and throughput and greatly reduce direct I/O to the database. All update transactions gain some benefit from using fast commit because control is returned to the application while database writes are processed asynchronously. Applications that tend to update the same group of records many times gain a big increase in throughput when using fast commit because writes to the database are delayed until many transactions have actually been committed. This allows the system to write out many updates with few I/O operations.
However, using fast commit can also increase recovery times. If the system crashes, all committed transactions that have not yet had their data written to the disk must be recovered. To control this recovery time, adjust the consistency point frequency.
|
|
|
The dmf_write_behind option, which is a DBMS Cache parameter, allocates server threads that asynchronously write modified data pages to disk. The write behind threads are controlled by the dmf_wb_start and dmf_wb_end thresholds that were defined at server startup time. Both these thresholds are derived DBMS Cache parameters.
By allowing transactions to commit without waiting for data to be flushed to disk, fast commit can significantly improve response time. However, the data page caches of fast commit servers tend to become filled with modified pages. The write behind threads control the number of modified pages by asynchronously writing them to disk.
If write behind threads are not used, a server quickly reaches its modified page limit (specified by dmf_modify_limit). When that happens, transactions begin to do synchronous writes to free up space in the cache, negating some of the benefits of using fast commit. For this reason, if you configure a server with fast commit, you must also specify write behind to get the full performance benefits of fast commit.
For two sessions to have concurrent access to a database using fast commit, each session must access the database through the same DBMS Server or through servers connected to a common buffer. To be connected to a common buffer, the server must use the cache_sharing parameter. When a server configured with the fast_commit option opens a database, it locks the database so that no other server (except a server using the same buffer cache) can access the database.
Note: You can use the dmf_write_behind option even if you are not using the fast_commit option; write behind threads can write to the database disk even if fast commit is not specified.
The number of write behind threads used to configure the DBMS Server depends on the system's I/O requirements. The number of writes per second each write behind thread can process depends on the speed of the disk drives. You must configure enough write behind threads to keep up with the expected I/O rate to the database.
Generally, a good rule is to allocate a write behind thread for each disk on which the databases are stored. Adding more write behind threads than disk devices does not increase the system's I/O throughput. A default installation allocates two write behind threads, which is sufficient for most application mixes.