本篇內(nèi)容主要講解“怎么理解PostgreSQL Locks中的Lock Manager Internal Locking”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“怎么理解PostgreSQL Locks中的Lock Manager Internal Locking”吧!

張家口網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計等網(wǎng)站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)于2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。

一、Lock Manager Internal Locking

Lock Manager Internal Locking
-----------------------------
內(nèi)部鎖機制
Before PostgreSQL 8.2, all of the shared-memory data structures used by
the lock manager were protected by a single LWLock, the LockMgrLock;
any operation involving these data structures had to exclusively lock
LockMgrLock.  Not too surprisingly, this became a contention bottleneck.
To reduce contention, the lock manager's data structures have been split
into multiple "partitions", each protected by an independent LWLock.
Most operations only need to lock the single partition they are working in.
Here are the details:
在PG 8.2或更舊的版本中,共享緩存中的數(shù)據(jù)結(jié)構(gòu)通過一個單一的LWLock(LockMgrLock)保護;
涉及這些數(shù)據(jù)結(jié)構(gòu)的所有操作必須持有LockMgrLock獨占鎖.不用說太多,這會成為爭用的瓶頸.
為了減少爭用,鎖管理器數(shù)據(jù)結(jié)構(gòu)已拆分為多個"partitions",每一個分區(qū)使用獨立的LWLock保護.
大多數(shù)操作只需要鎖定其中一個分區(qū),下面是實現(xiàn)細節(jié):
* Each possible lock is assigned to one partition according to a hash of
its LOCKTAG value.  The partition's LWLock is considered to protect all the
LOCK objects of that partition as well as their subsidiary PROCLOCKs.
* 只需要授予屬于LOCKTAG哈希值的某個分區(qū)的鎖,分區(qū)的LWLock用于保護該分區(qū)的所有LOCK對象.
* The shared-memory hash tables for LOCKs and PROCLOCKs are organized
so that different partitions use different hash chains, and thus there
is no conflict in working with objects in different partitions.  This
is supported directly by dynahash.c's "partitioned table" mechanism
for the LOCK table: we need only ensure that the partition number is
taken from the low-order bits of the dynahash hash value for the LOCKTAG.
To make it work for PROCLOCKs, we have to ensure that a PROCLOCK's hash
value has the same low-order bits as its associated LOCK.  This requires
a specialized hash function (see proclock_hash).
LOCKs和PROCLOCKs被組織為存儲在共享內(nèi)存中哈希表以便不同的分區(qū)使用不同的哈希鏈,
這樣不同分區(qū)中的對象就不會出現(xiàn)沖突,通過dynahash.c's "partitioned table"機制實現(xiàn).
只需要確保分區(qū)號從LOCKTAG的dynahash哈希值的低位中獲取即可.
對于PROCLOCKs,必須確保PROCLOCK的哈希值有與LOCK有相同的低位.這需要特別的哈希函數(shù)(proclock_hash)
* Formerly, each PGPROC had a single list of PROCLOCKs belonging to it.
This has now been split into per-partition lists, so that access to a
particular PROCLOCK list can be protected by the associated partition's
LWLock.  (This rule allows one backend to manipulate another backend's
PROCLOCK lists, which was not originally necessary but is now required in
connection with fast-path locking; see below.)
以前的做法,每一個PGPROC都有一個單獨的PROCLOCKs鏈表.現(xiàn)在已拆分為每一個分區(qū)一個鏈表,
這樣的好處是訪問一個PROCLOCK鏈表可通過相關(guān)的分區(qū)LWLock保護.
(這個規(guī)則允許一個后臺進程可管理另外一個后臺進程的PROCLOCK鏈表,這個事情本來是不需要做的,
但現(xiàn)在在使用fast-path鎖的連接時需要)
* The other lock-related fields of a PGPROC are only interesting when
the PGPROC is waiting for a lock, so we consider that they are protected
by the partition LWLock of the awaited lock.
PGPROC中與鎖相關(guān)的域只在PRPROC等待鎖才會變得有用,因此我們考慮通過分區(qū)LWLOCK中awaited lock來進行保護.
For normal lock acquisition and release, it is sufficient to lock the
partition containing the desired lock.  Deadlock checking needs to touch
multiple partitions in general; for simplicity, we just make it lock all
the partitions in partition-number order.  (To prevent LWLock deadlock,
we establish the rule that any backend needing to lock more than one
partition at once must lock them in partition-number order.)  It's
possible that deadlock checking could be done without touching every
partition in typical cases, but since in a properly functioning system
deadlock checking should not occur often enough to be performance-critical,
trying to make this work does not seem a productive use of effort.
對于普通的鎖請求和釋放,鎖定包含目標(biāo)鎖的分區(qū)就已經(jīng)足夠了.
通常來說,死鎖檢測需要訪問多個分區(qū).簡單來說,我們只要按分區(qū)順序鎖定相關(guān)的所有分區(qū)即可.
(為了避免LWLock死鎖,設(shè)定的規(guī)則是所有需要鎖定一個以上分區(qū)的后臺進程必須一次過按順序所有所有分區(qū))
在典型情況下,不需要訪問每一個分區(qū)進行死鎖檢測是可以做到的,但因為在一個正常運行的系統(tǒng)中,
死鎖檢測不應(yīng)經(jīng)常發(fā)生,因此不會對性能造成較大的影響.
A backend's internal LOCALLOCK hash table is not partitioned.  We do store
a copy of the locktag hash code in LOCALLOCK table entries, from which the
partition number can be computed, but this is a straight speed-for-space
tradeoff: we could instead recalculate the partition number from the LOCKTAG
when needed.
后臺進程的內(nèi)部LOCALLOCK哈希表沒有分區(qū).
我們確實在LOCALLOCK表條目中存儲了locktag哈希值的副本,分區(qū)號可以計算,這是一個以空間換時間的考量:
我們可以從LOCKTAG重新計算分區(qū)號.

到此，相信大家對“怎么理解PostgreSQL Locks中的Lock Manager Internal Locking”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

本文名稱：怎么理解PostgreSQLLocks中的LockManagerInternalLocking
網(wǎng)站地址：http://sd-ha.com/article22/iecdjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)站策劃、品牌網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè)、虛擬主機、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)