怎么理解PostgreSQL Locks中的Fast Path Locking

這篇文章主要講解了“怎么理解PostgreSQL Locks中的Fast Path Locking”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么理解PostgreSQL Locks中的Fast Path Locking”吧！

PG提供的系統(tǒng)表pg_locks中有一個(gè)字段:fastpath,用以表示是否fastpath,那fastpath指的是什么呢?

一、Fast Path Locking

Fast Path Locking
-----------------
Fast path locking is a special purpose mechanism designed to reduce the
overhead of taking and releasing certain types of locks which are taken
and released very frequently but rarely conflict.  Currently, this includes
two categories of locks:
Fast path locking用以減少那些需要經(jīng)常獲取和釋放但又很少出現(xiàn)沖突的鎖類型的獲取/釋放負(fù)載.
當(dāng)前的做法,包括2種類型(category)的鎖:
(1) Weak relation locks.  SELECT, INSERT, UPDATE, and DELETE must acquire a
lock on every relation they operate on, as well as various system catalogs
that can be used internally.  Many DML operations can proceed in parallel
against the same table at the same time; only DDL operations such as
CLUSTER, ALTER TABLE, or DROP -- or explicit user action such as LOCK TABLE
-- will create lock conflicts with the "weak" locks (AccessShareLock,
RowShareLock, RowExclusiveLock) acquired by DML operations.
(1)弱關(guān)系鎖.SELECT,INSERT,UPDATE和DELETE必須在relation上獲取鎖,
這些relation是在內(nèi)部使用的各種系統(tǒng)目錄(數(shù)據(jù)字典).
許多DML操作可同一時(shí)間在同一個(gè)表上進(jìn)行并行操作;只有DDL操作,比如CLUSTER,ALTER TABLE,DROP
或顯示的用戶操作如LOCK TABLE會(huì)與需要通過DML操作而獲得的"weak"鎖(AccessShareLock,
RowShareLock, RowExclusiveLock)出現(xiàn)沖突.
(2) VXID locks.  Every transaction takes a lock on its own virtual
transaction ID.  Currently, the only operations that wait for these locks
are CREATE INDEX CONCURRENTLY and Hot Standby (in the case of a conflict),
so most VXID locks are taken and released by the owner without anyone else
needing to care.
(2)VXID 鎖.每一個(gè)事務(wù)都會(huì)持有自身虛擬事務(wù)ID鎖.當(dāng)前的做法是,等待這些鎖的操作只有
CREATE INDEX CONCURRENTLY和Hot Standby(出現(xiàn)沖突的情況),因此大多數(shù)VXID鎖
跟其他進(jìn)程無關(guān).
The primary locking mechanism does not cope well with this workload.  Even
though the lock manager locks are partitioned, the locktag for any given
relation still falls in one, and only one, partition.  Thus, if many short
queries are accessing the same relation, the lock manager partition lock for
that partition becomes a contention bottleneck.  This effect is measurable
even on 2-core servers, and becomes very pronounced as core count increases.
主要的鎖定機(jī)制不能很好的處理這種工作負(fù)載.就算鎖管理器的locks已分區(qū),對(duì)于任意給定的realtion
仍會(huì)落在其中一個(gè)且唯一一個(gè)分區(qū)上.因此,如果許多端查詢正在訪問相同的relation,該分區(qū)上的鎖
會(huì)成為爭(zhēng)用瓶頸.隨著CPU核數(shù)的升高,這種影響會(huì)非常明顯.
To alleviate this bottleneck, beginning in PostgreSQL 9.2, each backend is
permitted to record a limited number of locks on unshared relations in an
array within its PGPROC structure, rather than using the primary lock table.
This mechanism can only be used when the locker can verify that no conflicting
locks exist at the time of taking the lock.
為了消除這樣的瓶頸,在PG 9.2開始,允許每一個(gè)后臺(tái)進(jìn)程記錄非共享relation上有限數(shù)目的鎖在
PGPROC結(jié)構(gòu)體中的數(shù)組中,而不是使用主要lock table.該機(jī)制只用于在鎖定者可以驗(yàn)證沒有沖突的情況.
A key point of this algorithm is that it must be possible to verify the
absence of possibly conflicting locks without fighting over a shared LWLock or
spinlock.  Otherwise, this effort would simply move the contention bottleneck
from one place to another.  We accomplish this using an array of 1024 integer
counters, which are in effect a 1024-way partitioning of the lock space.
Each counter records the number of "strong" locks (that is, ShareLock,
ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock) on unshared
relations that fall into that partition.  When this counter is non-zero, the
fast path mechanism may not be used to take new relation locks within that
partition.  A strong locker bumps the counter and then scans each per-backend
array for matching fast-path locks; any which are found must be transferred to
the primary lock table before attempting to acquire the lock, to ensure proper
lock conflict and deadlock detection.
該算法的一個(gè)關(guān)鍵點(diǎn)是可以驗(yàn)證可能的沖突不會(huì)出現(xiàn),而不需要與共享LWLock或spinlock競(jìng)爭(zhēng).
否則的話,這樣的處理結(jié)果會(huì)簡(jiǎn)單的把爭(zhēng)用瓶頸從一個(gè)地方移到了另外一個(gè)地方.
我們使用1024個(gè)整型計(jì)數(shù)器數(shù)組對(duì)應(yīng)1024個(gè)鎖空間分區(qū)來實(shí)現(xiàn)這一點(diǎn).每一個(gè)計(jì)數(shù)器記錄鎖分區(qū)上
非共享relation上"strong"鎖(ShareLock,ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock)的數(shù)目.
如果該計(jì)數(shù)器非0,則不使用fast path機(jī)制.
"strong"鎖會(huì)修改計(jì)數(shù)器,然后掃描每一個(gè)后臺(tái)進(jìn)程匹配的fast-path locks數(shù)組;每一個(gè)匹配的都必須
在嘗試獲取lock前轉(zhuǎn)換為主lock table,用以確保正使用確的鎖沖突和死鎖檢測(cè).
On an SMP system, we must guarantee proper memory synchronization.  Here we
rely on the fact that LWLock acquisition acts as a memory sequence point: if
A performs a store, A and B both acquire an LWLock in either order, and B
then performs a load on the same memory location, it is guaranteed to see
A's store.  In this case, each backend's fast-path lock queue is protected
by an LWLock.  A backend wishing to acquire a fast-path lock grabs this
LWLock before examining FastPathStrongRelationLocks to check for the presence
of a conflicting strong lock.  And the backend attempting to acquire a strong
lock, because it must transfer any matching weak locks taken via the fast-path
mechanism to the shared lock table, will acquire every LWLock protecting a
backend fast-path queue in turn.  So, if we examine
FastPathStrongRelationLocks and see a zero, then either the value is truly
zero, or if it is a stale value, the strong locker has yet to acquire the
per-backend LWLock we now hold (or, indeed, even the first per-backend LWLock)
and will notice any weak lock we take when it does.
在SMP系統(tǒng)上,必須確保正確的內(nèi)存同步.在這里,需要依賴于LWLock獲取作為內(nèi)存序列點(diǎn)這一事實(shí):
如果A執(zhí)行store,A和B按任意順序獲取LWLock,然后B在相同的內(nèi)存上執(zhí)行l(wèi)oad,這可以確保A'store.
在這種情況下,每一個(gè)后臺(tái)進(jìn)程的fast-path鎖會(huì)在檢查FastPathStrongRelationLocks是否與strong lock
存在沖突前獲取此LWLock.后臺(tái)進(jìn)程試圖獲取strong lock,因?yàn)樗仨殏鬏斖ㄟ^fast-path路徑獲取的
匹配weak locks到共享lock table中,因此將依次獲取保護(hù)后臺(tái)進(jìn)程fast-path的每個(gè)LWLock.
因此,如果檢查FastPathStrongRelationLocks結(jié)果為0,那么該值實(shí)際真的為0或者是一個(gè)固定值,
strong locks必須請(qǐng)求持有的per-backend LWLock,在完成后會(huì)關(guān)注所有的weak lock.
Fast-path VXID locks do not use the FastPathStrongRelationLocks table.  The
first lock taken on a VXID is always the ExclusiveLock taken by its owner.
Any subsequent lockers are share lockers waiting for the VXID to terminate.
Indeed, the only reason VXID locks use the lock manager at all (rather than
waiting for the VXID to terminate via some other method) is for deadlock
detection.  Thus, the initial VXID lock can *always* be taken via the fast
path without checking for conflicts.  Any subsequent locker must check
whether the lock has been transferred to the main lock table, and if not,
do so.  The backend owning the VXID must be careful to clean up any entry
made in the main lock table at end of transaction.
Fast-path VXID鎖沒有使用FastPathStrongRelationLocks表.
在VXID上獲取的第一個(gè)鎖通常是其自身的ExclusiveLock.接下來的lockers是等待VXID結(jié)束的共享lockers.
實(shí)際上,VXID鎖只有使用鎖管理器的唯一理由是用于死鎖檢測(cè).因此,VXID的初始化不需要檢查沖突
而是直接通過fast-path獲取.所有后續(xù)的locker必須檢查鎖釋放已傳輸?shù)街鱨ock table中,如沒有,則執(zhí)行此操作.
擁有VXID的后臺(tái)進(jìn)程必須在事務(wù)結(jié)束后小心清理主lock table中的entry.
Deadlock detection does not need to examine the fast-path data structures,
because any lock that could possibly be involved in a deadlock must have
been transferred to the main tables beforehand.
死鎖檢查不需要檢查fast-path數(shù)據(jù)結(jié)構(gòu),因?yàn)樗械逆i已傳輸?shù)絤ain table中.

感謝各位的閱讀，以上就是“怎么理解PostgreSQL Locks中的Fast Path Locking”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)怎么理解PostgreSQL Locks中的Fast Path Locking這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！