Berkeley DB Reference Guide: Configuring locking: sizing the system

Berkeley DB Reference Guide:
Locking Subsystem

Configuring locking: sizing the system

The lock system is sized using the following three methods:

(락시스템은 다음 세개의 메소드로 크기를 조정한다.)

DB_ENV->set_lk_max_locks
DB_ENV->set_lk_max_lockers
DB_ENV->set_lk_max_objects

The DB_ENV->set_lk_max_locks, DB_ENV->set_lk_max_lockers, and DB_ENV->set_lk_max_objects methods specify the maximum number of locks, lockers, and locked objects supported by the lock subsystem, respectively. The maximum number of locks is the number of locks that can be simultaneously requested in the system. The maximum number of lockers is the number of lockers that can simultaneously request locks in the system. The maximum number of lock objects is the number of objects that can simultaneously be locked in the system. Selecting appropriate values requires an understanding of your application and its databases. If the values are too small, requests for locks in an application will fail. If the values are too large, the locking subsystem will consume more resources than is necessary. It is better to err in the direction of allocating too many locks, lockers, and objects because increasing the number of locks does not require large amounts of additional resources.

(DB_ENV->set_lk_max_locks, DB_ENV->set_lk_max_lockers, and DB_ENV->set_lk_max_objects 은 락,락커,락걸린 오브제트의 최대수를 설정한다.락의최대수는 시스템에서 동시에 요청될수 있는 수이다.락커의 최대수는 동시에 락을 요청가능한 락커의 최대수다.락오브젝트의 최대수는 동시에 락될수있는 최대수이다.적당한 값을 애플리케이션에서 필요한 값으로 설정하라.만약 값이 너무 작으면 락요청은 실패하게 된다.값이 너무크면 리소스를 너무 많이 사용하게 된다.값이 큰거보다는 작은것이 더욱 좋다.왜냐하면 추가적인 락요청은 리소스가 들지 않기 때문이다. )

The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety. However, in some large applications, finer granularity of control is necessary in order to minimize the size of the Lock subsystem.

(락,락커,락오브젝트의 수를 결정하는 추천방법은 애플리케이션을 스트레스테스트하면서 락시스템의 통계를 보고 두배의 값을 사용하는것이 안전하다.)

The maximum number of lockers can be estimated as follows:

(락커의 최대수는 다음과 같을 수 있다.)

If the database environment is configured to use transactions, the maximum number of lockers needed is the number of simultaneously active transactions and child transactions (where a child transaction is active until its parent commits or aborts, not until it commits or aborts).
If the database environment is not configured to use transactions, the maximum number of lockers needed is the number of simultaneous non-cursor operations plus an additional locker for every simultaneously open cursor or database handle.

The maximum number of lock objects needed for a single database operation can be estimated as follows:

For Btree and Recno access methods, you will need one lock object per level of the database tree, at a minimum. (Unless keys are quite large with respect to the page size, neither Recno nor Btree database trees should ever be deeper than five levels.) Then, you will need one lock object for each leaf page of the database tree that will be simultaneously accessed.
For the Queue access method, you will need one lock object per record that is simultaneously accessed. To this, add one lock object per page that will be simultaneously accessed. (Because the Queue access method uses fixed-length records and the database page size is known, it is possible to calculate the number of pages -- and, therefore, the lock objects -- required.) Deleted records skipped by a DB_NEXT or DB_PREV operation do not require a separate lock object. Further, if your application is using transactions, no database operation will ever use more than three lock objects at any time.
For the Hash access method, you only need a single lock object.

For all access methods, you should then add an additional lock object per database for the database's metadata page.

Note that transactions accumulate locks over the transaction lifetime, and the lock objects required by a single transaction is the total lock objects required by all of the database operations in the transaction. However, a database page (or record, in the case of the Queue access method), that is accessed multiple times within a transaction only requires a single lock object for the entire transaction.

The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.

Berkeley DB Reference Guide:Locking Subsystem

Configuring locking: sizing the system

Berkeley DB Reference Guide:
Locking Subsystem