- [8.緩衝區管理器](#8緩衝區管理器)
  - [8.1概覽](#81概覽)
  - [8.2緩衝區管理器的結構](#82緩衝區管理器的結構)
    - [8.2.1緩衝表](#821緩衝表)
    - [8.2.1緩衝區描述符](#821緩衝區描述符)
    - [8.2.3緩衝區描述符層](#823緩衝區描述符層)
    - [8.2.3緩衝池](#823緩衝池)
  - [8.3緩衝區管理器鎖](#83緩衝區管理器鎖)
    - [8.3.1緩衝表鎖](#831緩衝表鎖)
    - [8.3.2緩衝區描述符相關的鎖](#832緩衝區描述符相關的鎖)
  - [8.4緩衝區管理器的工作原理](#84緩衝區管理器的工作原理)
    - [8.4.1訪問儲存在緩衝池中的頁面](#841訪問儲存在緩衝池中的頁面)
    - [8.4.2將頁面從儲存載入到空槽](#842將頁面從儲存載入到空槽)
    - [8.4.3將頁面從儲存載入到受害者緩衝池槽](#843將頁面從儲存載入到受害者緩衝池槽)
    - [8.4.4 頁面替換演算法：時鐘掃描](#844-頁面替換演算法時鐘掃描)
  - [8.5環形緩衝區](#85環形緩衝區)
  - [8.6髒頁刷盤](#86髒頁刷盤)

### 8.緩衝區管理器

衝區管理器管理著共享記憶體和持久儲存之間的資料傳輸

#### 8.1概覽

PostgreSQL緩衝區管理器由緩衝表、緩衝區描述符和緩衝池組成。緩衝池層儲存著資料檔案頁面，諸如表頁與索引頁，以及其相應的自由空間對映和可見性對映的頁面。緩衝池是一個陣列，資料的每個槽中儲存資料檔案的一頁。緩衝池陣列的序號索引稱為buffer_id。

PostgreSQL中的每個資料檔案頁面都可以分配到唯一的標籤，即緩衝區標籤。當緩衝區管理器收到請求時，PostgreSQL會用到目標頁面的緩衝區標籤。

緩衝區標籤由三個值組成，分別是關係檔案節點、關係分支編號和頁面塊號。第一個值分別代表了表空間、資料庫和表的oid；第二個值代表關係表的分支號；最後一個值代表頁面號。

```
#/pgdata/pgsql13/include/server/storage/buf_internals.h
/*
 * Buffer tag identifies which disk block the buffer contains.
 *
 * Note: the BufferTag data must be sufficient to determine where to write the
 * block, without reference to pg_class or pg_tablespace entries.  It's
 * possible that the backend flushing the buffer doesn't even believe the
 * relation is visible yet (its xact may have started before the xact that
 * created the rel).  The storage manager must be able to cope anyway.
 *
 * Note: if there's any pad bytes in the struct, INIT_BUFFERTAG will have
 * to be fixed to zero them, since this struct is used as a hash key.
 */
typedef struct buftag
{
        RelFileNode rnode;                      /* physical relation identifier */
        ForkNumber      forkNum;
        BlockNumber blockNum;           /* blknum relative to begin of reln */
} BufferTag;

#/pgdata/pgsql13/include/server/storage/relfilenode.h
typedef struct RelFileNode
{
        Oid                     spcNode;                /* tablespace */
        Oid                     dbNode;                 /* database */
        Oid                     relNode;                /* relation */
} RelFileNode;
```

**後端程式如何讀取資料頁**

當後端程式修改緩衝池中的頁面時（例如向頁面插入元組），這種尚未重新整理到持久儲存，但已被修改的頁面被稱為髒頁。

![圖8.2](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.2.png)

**頁面置換演算法**

當所有緩衝池槽位都被佔用，且其中未包含所請求的頁面時，緩衝區管理器必須在緩衝池中選擇一個頁面逐出，用於放置被請求的頁面。

**髒頁刷盤**

髒頁最終應該被刷入儲存，但緩衝區管理器執行這個任務需要額外幫助。在PostgreSQL中，檢查點程式和後臺寫入器這兩個後臺程式負責此任務。

#### 8.2緩衝區管理器的結構

- 緩衝表層是一個雜湊表，它儲存著頁面的buffer_tag 與描述符的buffer_id 之間的對映關係。
- 衝區描述符層是一個由緩衝區描述符組成的陣列。每個描述符與緩衝池槽一一對應，並儲存著相應槽的後設資料。
- 緩衝池層是一個陣列。每個槽都儲存一個資料檔案頁，陣列槽的索引稱為buffer_id。

##### 8.2.1緩衝表

緩衝表可以在邏輯上分為三個部分，分別是雜湊函式、雜湊桶槽及資料項。

![圖8.4](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.4.png)

##### 8.2.1緩衝區描述符
緩衝區描述符儲存著頁面的後設資料，這些與緩衝區描述符相對應的頁面儲存在緩衝池槽中。緩衝區描述符的結構由BufferDesc結構定義。

```
# src/include/storage/buf_internals.h.
/*
 * Flags for buffer descriptors
 *
 * Note: BM_TAG_VALID essentially means that there is a buffer hashtable
 * entry associated with the buffer's tag.
 */
#define BM_LOCKED                               (1U << 22)      /* buffer header is locked */
#define BM_DIRTY                                (1U << 23)      /* data needs writing */
#define BM_VALID                                (1U << 24)      /* data is valid */
#define BM_TAG_VALID                    (1U << 25)      /* tag is assigned */
#define BM_IO_IN_PROGRESS               (1U << 26)      /* read or write in progress */
#define BM_IO_ERROR                             (1U << 27)      /* previous I/O failed */
#define BM_JUST_DIRTIED                 (1U << 28)      /* dirtied since write started */
#define BM_PIN_COUNT_WAITER             (1U << 29)      /* have waiter for sole pin */
#define BM_CHECKPOINT_NEEDED    (1U << 30)      /* must write for checkpoint */
#define BM_PERMANENT                    (1U << 31)      /* permanent buffer (not unlogged,
                                                                                         * or init fork) */
                                                                                         
/*
 *      BufferDesc -- shared descriptor/state data for a single shared buffer.
 *
 * Note: Buffer header lock (BM_LOCKED flag) must be held to examine or change
 * the tag, state or wait_backend_pid fields.  In general, buffer header lock
 * is a spinlock which is combined with flags, refcount and usagecount into
 * single atomic variable.  This layout allow us to do some operations in a
 * single atomic operation, without actually acquiring and releasing spinlock;
 * for instance, increase or decrease refcount.  buf_id field never changes
 * after initialization, so does not need locking.  freeNext is protected by
 * the buffer_strategy_lock not buffer header lock.  The LWLock can take care
 * of itself.  The buffer header lock is *not* used to control access to the
 * data in the buffer!
 *
 * It's assumed that nobody changes the state field while buffer header lock
 * is held.  Thus buffer header lock holder can do complex updates of the
 * state variable in single write, simultaneously with lock release (cleaning
 * BM_LOCKED flag).  On the other hand, updating of state without holding
 * buffer header lock is restricted to CAS, which insure that BM_LOCKED flag
 * is not set.  Atomic increment/decrement, OR/AND etc. are not allowed.
 *
 * An exception is that if we have the buffer pinned, its tag can't change
 * underneath us, so we can examine the tag without locking the buffer header.
 * Also, in places we do one-time reads of the flags without bothering to
 * lock the buffer header; this is generally for situations where we don't
 * expect the flag bit being tested to be changing.
 *
 * We can't physically remove items from a disk page if another backend has
 * the buffer pinned.  Hence, a backend may need to wait for all other pins
 * to go away.  This is signaled by storing its own PID into
 * wait_backend_pid and setting flag bit BM_PIN_COUNT_WAITER.  At present,
 * there can be only one such waiter per buffer.
 *
 * We use this same struct for local buffer headers, but the locks are not
 * used and not all of the flag bits are useful either. To avoid unnecessary
 * overhead, manipulations of the state field should be done without actual
 * atomic operations (i.e. only pg_atomic_read_u32() and
 * pg_atomic_unlocked_write_u32()).
 *
 * Be careful to avoid increasing the size of the struct when adding or
 * reordering members.  Keeping it below 64 bytes (the most common CPU
 * cache line size) is fairly important for performance.
 */
typedef struct BufferDesc
{
        BufferTag       tag;                    /* ID of page contained in buffer */
        int                     buf_id;                 /* buffer's index number (from 0) */

/* state of the tag, containing flags, refcount and usagecount */
        pg_atomic_uint32 state;

int                     wait_backend_pid;       /* backend PID of pin-count waiter */
        int                     freeNext;               /* link in freelist chain */

LWLock          content_lock;   /* to lock access to buffer contents */
} BufferDesc;
```

##### 8.2.3緩衝區描述符層

緩衝區描述符的集合構成了一個陣列，本書稱該陣列為緩衝區描述符層。

> PostgreSQL中的freelist完全不同於Oracle中freelist的概念。PostgreSQL的freelist只是空緩衝區描述符的連結串列。PostgreSQL中與Oracle中的freelist相對應的物件是空閒空間對映（FSM）

##### 8.2.3緩衝池

緩衝池只是一個用於儲存關係資料檔案（例如表或索引）頁面的簡單陣列。緩衝池陣列的序號索引也就是buffer_id。

緩衝池槽的大小為8KB，等於頁面大小，因而每個槽都能儲存整個頁面。

#### 8.3緩衝區管理器鎖

緩衝區管理器會出於不同的目的使用各式各樣的鎖，注意，本節描述的鎖，指的是緩衝區管理器同步機制的一部分。它們與SQL語句和SQL操作中的鎖沒有任何關係。

##### 8.3.1緩衝表鎖

BufMappingLock保護整個緩衝表的資料完整性。它是一種輕量級的鎖，有共享模式與獨佔模式。在緩衝表中查詢條目時，後端程式會持有共享的BufMappingLock。插入或刪除條目時，後端程式會持有獨佔的BufMappingLock。

BufMappingLock會被分為多個分割槽，以減少緩衝表中的爭用（預設為128個分割槽）。每個BufMappingLock分割槽都保護著一部分相應的雜湊桶槽。

緩衝表也需要許多其他鎖。例如，在緩衝表內部會使用自旋鎖（spin lock）來刪除資料項。

![圖例8.7](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.7.png)

> 兩個後端程式可以同時持有各自分割槽的BufMappingLock獨佔鎖，以插入新的資料項。如果BufMappingLock是系統級的鎖，那麼其中一個程式就需要等待另一個程式完成處理。

##### 8.3.2緩衝區描述符相關的鎖

每 個 緩 衝 區 描 述 符 都 會 用 到 內 容 鎖（content_lock）與 IO 進 行 鎖（io_in_progress_lock）這兩個輕量級鎖，以控制對相應緩衝池槽頁面的訪問。當檢查或更改描述符本身欄位的值時，就會用到自旋鎖。

**內容鎖** 典型的強制限制訪問的鎖

當讀取頁面時，後端程式以共享模式獲取頁面相應緩衝區描述符中的content_lock.

執行以下操作之一時，則會獲取獨佔模式的內容鎖

- 將行（即元組）插入頁面，或更改頁面中元組的 t_xmin/t_xmax 欄位時
- 物理移除元組，或壓緊頁面上的空閒空間。
- 凍結頁面中的元組

**IO進行鎖**

IO 進行鎖（io_in_progress_lock）用於等待緩衝區上的I/O完成。當PostgreSQL程式載入/寫入頁面資料時，該程式在訪問頁面期間，持有對應描述符上獨佔的io_in_progres_lock。

**自旋鎖**

當檢查或更改標記欄位與其他欄位時，例如refcount和usage_count，會用到自旋鎖。

例子1：

釘住緩衝區描述符：
- 獲取緩衝區描述符上的自旋鎖
- 將其refcount和usage_count的值增加1
- 釋放自旋鎖

```
LockBufHdr(bufferdesc);    /* Acquire a spinlock */
bufferdesc->refcont++;
bufferdesc->usage_count++;
UnlockBufHdr(bufferdesc); /* Release the spinlock */
```

例子2：

將髒位設定為"1":
- 獲取緩衝區描述符上的自旋鎖
- 使用位操作將髒位置位為"1"。
- 釋放自旋鎖

```
#define BM_DIRTY             (1 << 0)    /* data needs writing */
#define BM_VALID             (1 << 1)    /* data is valid */
#define BM_TAG_VALID         (1 << 2)    /* tag is assigned */
#define BM_IO_IN_PROGRESS    (1 << 3)    /* read or write in progress */
#define BM_JUST_DIRTIED      (1 << 5)    /* dirtied since write started */

LockBufHdr(bufferdesc);
bufferdesc->flags |= BM_DIRTY;
UnlockBufHdr(bufferdesc);
```

> 緩衝區描述符的資料結構定義位置src/include/storage/buf_internals.h:BM_LOCKED

**參考**

- http://www.postgres.cn/v2/news/viewone/1/241
- https://zhmin.github.io/2019/10/15/postgresql-lwlock/

#### 8.4緩衝區管理器的工作原理
本節介紹緩衝區管理器的工作原理。當後端程式想要訪問所需頁面時，它會呼叫ReadBufferExtended函式。

函式 ReadBufferExtended的行為因場景而異，在邏輯上具體可以分為三種情況。

##### 8.4.1訪問儲存在緩衝池中的頁面

當從緩衝池槽中的頁面裡讀取行時，PostgreSQL 程式獲取相應緩衝區描述符的共享content_lock，因而緩衝池槽可以同時被多個程式讀取。

當向頁面插入（及更新、刪除）行時，該 postgres後端程式獲取相應緩衝區描述符的獨佔content_lock（注意，這裡必須將相應頁面的髒位置設為"1"）。訪問完頁面後，相應緩衝區描述符的引用計數值減1。

圖8.8是訪問儲存在緩衝池中的頁面示意圖。

![圖例8.8](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.8.png)

（1）建立所需頁面的 buffer_tag（在本例中 buffer_tag 是'Tag_C'），並使用雜湊函式計算與描述符相對應的雜湊桶槽。

（2）獲取相應雜湊桶槽分割槽上的BufMappingLock共享鎖。

（3）查詢標籤為'Tag_C'的條目，並從條目中獲取buffer_id。本例中buffer_id為2。

（4）將 buffer_id=2 的緩衝區描述符釘住，即將描述符的 refcount 和usage_count增加1。

（5）釋放BufMappingLock。

（6）訪問buffer_id=2的緩衝池槽。

##### 8.4.2將頁面從儲存載入到空槽

![圖例8.9](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.9.png)

在第二種情況下，假設所需頁面不在緩衝池中，且freelist中有空閒元素（空描述符）。這時，緩衝區管理器將執行以下步驟：

（1）查詢緩衝區表（本節假設頁面不存在，找不到對應頁面）。

- 1.建立所需頁面的buffer_tag（本例中buffer_tag為'Tag_E'）並計算其雜湊桶槽。
- 2.以共享模式獲取相應分割槽上的BufMappingLock。
- 3.查詢緩衝區表（根據假設，這裡沒找到）。
- 4.釋放BufMappingLock。

（2）從 freelist 中獲取空緩衝區描述符，並將其釘住。在本例中所獲的描述符：buffer_id=4。

（3）以獨佔模式獲取相應分割槽的BufMappingLock（此鎖將在步驟（6）中被釋放）。

（4）建立一條新的緩衝表資料項：buffer_tag='Tag_E', buffer_id=4，並將其插入緩衝區表中。

（5）將頁面資料從儲存載入至buffer_id=4的緩衝池槽中，如下所示：

- 1.以排他模式獲取相應描述符的io_in_progress_lock。
- 2.將相應描述符的IO_IN_PROGRESS標記位設定為1，以防其他程式訪問。
- 3.將所需的頁面資料從儲存載入到緩衝池插槽中。
- 4.更改相應描述符的狀態，將IO_IN_PROGRESS標記位設定為"0"，且VALID標記位設定為"1"。
- 5.釋放io_in_progress_lock。

（6）釋放相應分割槽的BufMappingLock。

（7）訪問buffer_id=4的緩衝池槽。

##### 8.4.3將頁面從儲存載入到受害者緩衝池槽

在這種情況下，假設所有緩衝池槽位都被頁面佔用，且未儲存所需的頁面。圖8.10、圖8.11是將頁面從儲存載入到受害者緩衝池槽的示意圖。

![圖例8.10](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.10.png)

![圖例8.11](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.11.png)

緩衝區管理器將執行以下步驟：

（1）建立所需頁面的buffer_tag並查詢緩衝表。在本例中假設buffer_tag是'Tag_M' （且相應的頁面在緩衝區中找不到）。

（2）使用時鐘掃描演算法選擇一個受害者緩衝池槽位，從緩衝表中獲取包含著受害者槽位buffer_id的舊錶項，並在緩衝區描述符層將受害者槽位的緩衝區描述符釘住。本例中受害者槽的buffer_id=5，舊錶項為Tag_F, id = 5。時鐘掃描將在下一節介紹。

（3）如果受害者頁面是髒頁，則將其刷盤（write & fsync），否則進入步驟（4）。在使用新資料覆蓋髒頁之前，必須將髒頁寫入儲存中。髒頁的刷盤步驟如下：

在使用新資料覆蓋髒頁之前，必須將髒頁寫入儲存中。髒頁的刷盤步驟如下：

- 1.獲取 buffer_id=5 描述符上的共享 content_lock 和獨佔io_in_progress_lock。
- 2.更改相應描述符的狀態：相應IO_IN_PROCESS 位設定為"1"，JUST_DIRTIED 位設定為"0"。
- 3.根據具體情況，呼叫XLogFlush()函式將WAL緩衝區上的WAL資料寫入當前WAL段檔案
- 4.將受害者頁面的資料刷盤至儲存中。
- 5.更改相應描述符的狀態；將IO_IN_PROCESS位設定為"0"，將VALID位設定為"1"。
- 6.釋放io_in_progress_lock和content_lock。

（4）以排他模式獲取緩衝區表中舊錶項所在分割槽上的BufMappingLock。

（5）獲取新表項所在分割槽上的BufMappingLock，並將新表項插入緩衝表：

- 1.建立新表項：由buffer_tag='Tag_M'與受害者的buffer_id組成的新表項。
- 2.以獨佔模式獲取新表項所在分割槽上的BufMappingLock。
- 3.將新表項插入緩衝區表中。

（6）從緩衝表中刪除舊錶項，並釋放舊錶項所在分割槽的BufMappingLock。

（7）將目標頁面資料從儲存載入至受害者槽位，然後用 buffer_id=5 更新描述符的標識欄位，將髒位設定為0，並按流程初始化其他標記位。

（8）釋放新表項所在分割槽上的BufMappingLock。

（9）訪問buffer_id=5對應的緩衝區槽位。

##### 8.4.4 頁面替換演算法：時鐘掃描

NFU（Not Frequently Used）演算法的變體，開銷較少，能高效地選出較少使用的頁面。

緩衝區描述符為黑色或灰色的方框，框中的數字顯示每個描述符的 usage_count。而 nextVictimBuffer是一個 32位的無符號整型變數，它總是指向某個緩衝區描述符並按順時針順序旋轉。

```
--為程式碼，時鐘掃描
    WHILE true
(1)     Obtain the candidate buffer descriptor pointed by the nextVictimBuffer
(2)     IF the candidate descriptor is unpinned THEN
(3)	       IF the candidate descriptor's usage_count == 0 THEN
	            BREAK WHILE LOOP  /* the corresponding slot of this descriptor is victim slot. */
	       ELSE
		    Decrease the candidate descriptpor's usage_count by 1
               END IF
         END IF
(4)     Advance nextVictimBuffer to the next one
      END WHILE 
(5) RETURN buffer_id of the victim

#（1）獲取nextVictimBuffer指向的候選緩衝區描述符。
#（2）如果候選描述符未被釘住，則進入步驟（3），否則進入步驟（4）。
#（3）如果候選描述符的usage_count為0，則選擇該描述符對應的槽作為受害者，並進入步驟（5），否則將此描述符的usage_count減1，並繼續執行步驟（4）。
#（4）將nextVictimBuffer迭代至下一個描述符（如果到末尾則迴繞至頭部）並返回步驟（1），重複直到找到受害者。
#（5）返回受害者的buffer_id。
```

![圖例8.12](https://gitee.com/firsouler/postgresql-learning/raw/master/pginternalsImages/8.12.png)

如上圖，該演算法的虛擬碼與演算法描述如下：

- 1.nextVictimBuffer 指向第一個描述符（buffer_id = 1），但因為該描述符被釘住了，所以跳過。
- 2.extVictimBuffer指向第二個描述符（buffer_id = 2），該描述符未被釘住，但其usage_count為2，因此該描述符的usage_count將減1，而nextVictimBuffer迭代至第三個候選描述符。
- 3.nextVictimBuffer 指向第三個描述符（buffer_id = 3），該描述符未被釘住，但其usage_count = 0，因而成為本輪的受害者。

當nextVictimBuffer掃過未釘住的描述符時，其usage_count會減1。因此只要緩衝池中存在未釘住的描述符，該演算法總能在旋轉若干次 nextVictimBuffer 後，找到一個usage_count為0的受害者。

#### 8.5環形緩衝區

在讀大表是，pg使用環形緩衝區，而非緩衝池，環形緩衝區是一個小的臨時區域，當滿足下面任意一個條件時，pg將在共享記憶體中分配一個環形緩衝區。

- 1.批次讀取：當掃描關係讀取資料的大小超過緩衝池的1/4時，環形緩衝區的大小為256KB
- 2.批次寫入，當執行以下sql命令時，該緩衝區大小為16MB
   . copy from 
   . create tables
   . create meterialized view / refresh materialized view
   . alter table
- 3.清理過程，當欄位清理守護程式執行清理過程時，該區大小256KB

分配的環形緩衝區將在使用後被立即釋放。

環形緩衝區的好處顯而易見，如果後端程式在不使用環形緩衝區的情況下讀取大表，則所有儲存在緩衝池中的頁面都會被移除，這會導致快取命中率降低。環形緩衝區可以避免此問題。

**為什麼批次讀取和清理過程的預設環形緩衝區大小為256 KB**

原始碼中緩衝區管理器目錄下的README中解釋了這個問題

> 順序掃描使用256KB的環形緩衝區，它足夠小，因而能放入L2快取中，從而使得作業系統快取到共享緩衝區的頁面傳輸變得高效。通常更小一點也可以，但環形緩衝區需要足夠大到能同時容納掃描中被釘住的所有頁面。

#### 8.6髒頁刷盤

除了置換受害者頁面之外，檢查點程式和後臺寫入器程式也會將髒頁刷盤至儲存中。儘管兩個程式都具有相同的功能（髒頁刷盤），但是它們有著不同的角色和行為。

檢查點程式將檢查點記錄寫入WAL段檔案，並在檢查點開始時進行髒頁刷盤

後臺寫入器的目的是透過少量多次的髒頁刷盤，減少檢查點帶來的密集寫入的影響。後臺寫入器會一點點地將髒頁落盤，儘可能減少對資料庫活動造成的影響。在預設情況下，後臺寫入器每 200ms 被喚醒一次（由引數 bgwriter_delay 定義），且最多刷寫 bgwriter_lru_maxpages個頁面（預設為100個頁面）。

**本節英文版**

https://www.interdb.jp/pg/pgsql08.html

【讀書筆記】《PostgreSQL指南-內幕探索》-8.緩衝區管理器

相關文章