瀚高資料庫記憶體結構

瀚高PG實驗室發表於2021-10-18
文件用途
瞭解瀚高資料庫的記憶體結構,調整相關記憶體引數的大小以適應當前的執行環境。
詳細資訊

瀚高資料庫的記憶體結構如下:

瀚高資料庫記憶體結構

下面將詳細介紹這些記憶體結構。


在瀚高資料庫中,記憶體大概被分為兩大類:

(1)本地記憶體(Local memory area): 為每一個後端程式(backend process)分配的記憶體

(2)共享記憶體(Shared memory area):資料庫服務端所有的後臺程式(backgroud process)使用的記憶體


(一)本地記憶體:


每一個後端程式都會分配一塊本地記憶體,每一塊區域又分為三個子區域。


1.1 work_mem


配置檔案中的引數名是“work_mem”,預設是4MB

設定在寫入臨時磁碟檔案之前,查詢操作(如排序或雜湊表)所使用的最大記憶體量。如果指定的值沒有單位,則使用千位元組(kilobytes)。預設值是 4兆位元組(4MB)。注意,對於一個複雜的查詢,可能會並行執行幾個排序(sort)或雜湊(hash)操作;在開始將資料寫入臨時檔案之前,允許每個操作使用此值指定的所有記憶體(PS.就是說一個查詢,可能分成幾個操作,每個操作單獨配有一塊 work_mem指定大小的記憶體)。另外,幾個正在執行的會話可能同時執行這些操作。因此,使用的總記憶體可能是 work_mem值的許多倍;在選擇值時,有必要記住這一點。排序操作用於 ORDER BY、DISTINCT和合並連線(merge joins)。雜湊表(hash tables)用於雜湊連線(hash joins)、基於雜湊的聚合(hash-based aggregation)和基於雜湊(hash-based)的 IN子查詢處理。


1.2 maintenance_work_mem


配置檔案中的引數名是“maintenance_work_mem”,預設是64MB

指定維護操作(如:VACUUM、CREATE INDEX和 ALTER TABLE ADD FOREIGN KEY)所使用的最大記憶體量。如果指定的值沒有單位,則使用千位元組(kilobytes)。它的預設值是 64兆位元組(64MB)。由於資料庫會話一次只能執行其中的一個操作,而且一個安裝通常不會同時執行許多操作,因此可以將這個值設定為比 work_mem大得多的值。較大的設定(值)可能提高清理(vacuuming)和恢復資料庫轉儲(restoring database dumps)的效能。

注意,在執行 autovacuum(自動清理)時,可能會分配相當於 autovacuum_max_workers乘以該記憶體(maintenance_work_mem),所以要注意不要將該預設值設定得太高。通過單獨設定 autovacuum_work_mem來進行控制可能會很有用。


1.3 temp_buffers


配置檔案中的引數名是“temp_buffers”,預設是8MB

設定每個資料庫會話中臨時緩衝區使用的最大記憶體量。這些是僅用於訪問臨時表的會話本地緩衝區。如果指定的值沒有單位,則將其作為塊,即 BLCKSZ位元組,通常為8kB。預設值是8MB。(如果 BLCKSZ不是 8kB,則預設值會與之成比例伸縮。)此設定可以在單個會話內更改,但僅限於在會話內第一次使用臨時表之前;後續更改該值的嘗試將不會對該會話產生影響。

會話將根據需要分配臨時緩衝區,上限由 temp_buffers指定。在實際上不需要很多臨時緩衝區的會話中設定較大值的代價只是一個緩衝區描述符,或者在 temp_buffers中每增加一個緩衝區大約 64位元組。但是,如果實際上真使用了緩衝區,則會為它消耗額外的 8192位元組(通常是一個 BLCKSZ位元組)。


(二)共享記憶體:


這塊區域在服務端啟動的時候分配,這塊區域也是分為好幾個子區域。

資料庫啟動後,會生成一塊共享記憶體,共享記憶體主要用做資料塊的緩衝區,以便提高讀寫效能。WAL日誌緩衝區和CLOG緩衝區也存在共享記憶體中。除此以外還有一些全域性資訊也儲存在共享記憶體中,如程式資訊、鎖的資訊、全據統計資訊,等等。


2.1 shared buffer pool


將表或者索引的page從磁碟載入到shared buffer,然後在shared buffer操作。


配置檔案中的引數名是“shared_buffers”,預設是8MB。

設定資料庫服務端用於共享記憶體緩衝區的記憶體量。預設值通常為 128兆位元組(128MB),但如果核心設定不支援它,則可能會更小(核心設定在 initdb期間確定)。此引數設定必須至少為 128KB。但是,為了獲得良好的效能,通常需要設定為比最小值高得多的值。如果指定的值沒有單位,則將它視為塊(blocks),即 BLCKSZ位元組(塊位元組),通常為 8kB。(BLCKSZ的非預設值更改了最小值的大小。PS:最小值與塊大小有關係)此引數只能在服務端啟動時設定。

如果你有一個具有 1GB或更多 RAM的專用資料庫伺服器(PS.是否指該伺服器只用來一個資料庫集簇使用),合理的 shared_buffers起始值是系統中記憶體的 25%。在某些工作負載中,shared_buffers的更大設定是高效的,但由於 PostgreSQL也依賴於作業系統快取,因此將超過 40%的 RAM分配給 shared_buffers不太可能比分配較小的記憶體更優。對於 shared_buffers,較大的設定通常需要相應地增加 max_wal_size,以便在較長一段時間內分散寫入大量新資料或更改資料的過程。

在RAM小於1GB的系統上,較小的 RAM百分比是合適的,以便為作業系統留下足夠的空間。


2.2 wal buffer


在服務端出現問題的時候,確保資料不會丟失,在寫到磁碟之前,wal buffer是wal log的快取區域


配置檔案中的引數名是“wal_buffers”,預設是16MB。

用於尚未寫入磁碟的WAL資料的共享記憶體量。預設設定-1時,選擇的大小等於shared_buffers的1/32(大約3%),但不小於64kB,也不大於一個WAL段的大小,通常為16MB。如果自動選取的值太大或太小,可以手動設定該值,但是任何小於32kB的正數值將被視為32kB。如果指定的值沒有單位,則將“WAL塊”作為單位,即“XLOG_BLCKSZ”位元組,通常為 8kB。此引數只能在服務端啟動時設定。


在每次事務提交時,WAL緩衝區的內容都被寫到磁碟上,因此非常大的值不太可能提供顯著的效能益處。但是,將這個值設定為至少幾兆位元組可以提高在許多客戶機同時提交的繁忙服務端上的寫效能。在大多數情況下,通過預設設定-1選擇的自動調優應該會給出合理的結果。


2.3 commitlog buffer


為了併發控制所有事物的狀態的保持而分配的區域

通過clog(commit log)儲存每個事務的狀態,在資料庫啟動時,clog檔案會載入到共享記憶體中,checkpoint時會把共享記憶體中的事務狀態資訊重新整理到磁碟上。


另外,瀚高資料庫還分配一些其他的記憶體區域:

為訪問控制分配的子區域,比如輕量級鎖,共享或者專有鎖。

為其他backgroud process提供的子區域,比如檢查點,vacuum。

為事物處理提供的子區域,比如事物中的儲存點,和二階段事物提交。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69994931/viewspace-2837867/,如需轉載,請註明出處,否則將追究法律責任。

相關文章