資源使用量/ 記憶體
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
hash_mem_multiplier
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 要用於哈希表的多個work_mem。 |
資料類型 | numeric |
預設值 | 2 |
允許的值 | 2 |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
huge_page_size
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 應要求的巨大頁面大小。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
logical_decoding_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於邏輯譯碼的最大記憶體。 |
資料類型 | 整數 |
預設值 | 65536 |
允許的值 | 65536 |
參數類型 | 唯讀 |
文件集 |
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
min_dynamic_shared_memory
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟動時保留的動態共享記憶體數量。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取用於主要共用記憶體區域的共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | mmap |
允許的值 | mmap |
參數類型 | 唯讀 |
文件集 |
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用的工具來監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或您慣用的 PostgreSQL 用戶端,連線 至您的資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
hash_mem_multiplier
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 要用於哈希表的多個work_mem。 |
資料類型 | numeric |
預設值 | 2 |
允許的值 | 2 |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
huge_page_size
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 應要求的巨大頁面大小。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
logical_decoding_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於邏輯譯碼的最大記憶體。 |
資料類型 | 整數 |
預設值 | 65536 |
允許的值 | 65536 |
參數類型 | 唯讀 |
文件集 |
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
min_dynamic_shared_memory
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟動時保留的動態共享記憶體數量。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取用於主要共用記憶體區域的共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | mmap |
允許的值 | mmap |
參數類型 | 唯讀 |
文件集 |
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用的工具來監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或慣用的 PostgreSQL 用戶端,連線 至資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
hash_mem_multiplier
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 要用於哈希表的多個work_mem。 |
資料類型 | numeric |
預設值 | 1 |
允許的值 | 1 |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
huge_page_size
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 應要求的巨大頁面大小。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
logical_decoding_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於邏輯譯碼的最大記憶體。 |
資料類型 | 整數 |
預設值 | 65536 |
允許的值 | 65536 |
參數類型 | 唯讀 |
文件集 |
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
min_dynamic_shared_memory
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟動時保留的動態共享記憶體數量。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取用於主要共用記憶體區域的共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | mmap |
允許的值 | mmap |
參數類型 | 唯讀 |
文件集 |
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用工具監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或您慣用的 PostgreSQL 用戶端,連線 至您的資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
hash_mem_multiplier
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 要用於哈希表的多個work_mem。 |
資料類型 | numeric |
預設值 | 1 |
允許的值 | 1 |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
logical_decoding_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於邏輯譯碼的最大記憶體。 |
資料類型 | 整數 |
預設值 | 65536 |
允許的值 | 65536 |
參數類型 | 唯讀 |
文件集 |
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取用於主要共用記憶體區域的共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | mmap |
允許的值 | mmap |
參數類型 | 唯讀 |
文件集 |
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用工具監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或您慣用的 PostgreSQL 用戶端,連線 至資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
hash_mem_multiplier
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 要用於哈希表的多個work_mem。 |
資料類型 | numeric |
預設值 | 1 |
允許的值 | 1 |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取用於主要共用記憶體區域的共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | mmap |
允許的值 | mmap |
參數類型 | 唯讀 |
文件集 |
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用工具監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或您慣用的 PostgreSQL 用戶端,連線 至您的資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
autovacuum_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個自動數據清理背景工作進程要使用的記憶體上限。 |
資料類型 | 整數 |
預設值 | -1 |
允許的值 | -1-2097151 |
參數類型 | dynamic |
文件集 | autovacuum_work_mem |
dynamic_shared_memory_type
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 選取所使用的動態共用記憶體實作。 |
資料類型 | 列舉 |
預設值 | posix |
允許的值 | posix |
參數類型 | 唯讀 |
文件集 |
huge_pages
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 啟用/停用大型記憶體頁面的使用。 此設定不適用於少於 4 個虛擬核心的伺服器。 |
資料類型 | 列舉 |
預設值 | try |
允許的值 | on,off,try |
參數類型 | static |
文件集 | huge_pages |
描述
大型頁面是一項功能,可讓內存在較大的區塊中管理。 您通常可以管理最多 2 MB 的區塊,而不是標準 4 KB 頁面。
使用大型頁面可提供可有效卸除 CPU 的效能優勢:
- 它們可減少與記憶體管理工作相關聯的額外負荷,例如較少的翻譯外觀緩衝區 (TLB) 遺漏。
- 它們縮短記憶體管理所需的時間。
具體而言,在 PostgreSQL 中,您只能針對共用記憶體區域使用大型頁面。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是,大型頁面會防止將共用記憶體區域交換到磁碟,進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器,請避免停用大型頁面。 停用大型頁面可能會危害效能。
- 如果您從不支援大型頁面的較小伺服器開始,但您預期會相應增加至執行的伺服器,請讓設定保持
huge_pages
TRY
順暢轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個虛擬核心的伺服器,大型頁面會自動從基礎操作系統配置。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共享記憶體設定,則會自動調整大型頁面數目,包括 變更為 shared_buffers
。
maintenance_work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定要用於維護作業的最大記憶體,例如 VACUUM、建立索引。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 1024-2097151 |
參數類型 | dynamic |
文件集 | maintenance_work_mem |
描述
maintenance_work_mem
是 PostgreSQL 中的組態參數。 它會控管設定給維護作業的記憶體數量,例如 VACUUM
、 CREATE INDEX
和 ALTER TABLE
。 與 影響查詢作業記憶體配置不同的 work_mem
是, maintenance_work_mem
會保留給維護及優化資料庫結構的工作。
重點
- 真空記憶體上限:如果您想要藉由增加
maintenance_work_mem
來加速清除無效 Tuple,請注意VACUUM
,具有收集無效 Tuple 標識符的內建限制。 此程式最多只能使用 1 GB 的記憶體。 - 自動數據清理的記憶體區隔:您可以使用
autovacuum_work_mem
設定來控制自動數據清理作業獨立使用的記憶體。 此設定可作為的maintenance_work_mem
子集。 您可以決定記憶體自動數據清理使用多少,而不會影響其他維護工作和數據定義作業的記憶體配置。
max_prepared_transactions
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定同時準備的交易數目上限。 執行複本伺服器時,您必須將此參數設定為與主伺服器上相同的或更高的值。 |
資料類型 | 整數 |
預設值 | 0 |
允許的值 | 0-262143 |
參數類型 | static |
文件集 | max_prepared_transactions |
max_stack_depth
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定最大堆疊深度,以 KB 為單位。 |
資料類型 | 整數 |
預設值 | 2048 |
允許的值 | 2048 |
參數類型 | 唯讀 |
文件集 |
shared_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為8kb。 允許的值位於可用記憶體的 10% - 75% 範圍內。 |
資料類型 | 整數 |
預設值 | 取決於配置給伺服器的資源(虛擬核心、RAM 或磁碟空間)。 |
允許的值 | 16-1073741823 |
參數類型 | static |
文件集 | shared_buffers |
描述
組 shared_buffers
態參數會決定配置給 PostgreSQL 資料庫的系統記憶體數量,以緩衝處理數據。 它可作為所有資料庫進程可存取的集中式記憶體集區。
需要數據時,資料庫進程會先檢查共用緩衝區。 如果必要數據存在,則會快速擷取並略過更耗時的磁碟讀取。 藉由做為資料庫進程與磁碟之間的媒介, shared_buffers
可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時,shared_buffers
設定值會以 (近似) 線性的方式縮放。
temp_buffers
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定每個資料庫會話所使用的暫存緩衝區數目上限。 |
資料類型 | 整數 |
預設值 | 1024 |
允許的值 | 100-1073741823 |
參數類型 | dynamic |
文件集 | temp_buffers |
work_mem
屬性 | 值 |
---|---|
類別 | 資源使用量/ 記憶體 |
描述 | 設定內部排序作業和哈希表在寫入暫存磁碟檔案之前要使用的記憶體數量。 |
資料類型 | 整數 |
預設值 | 4096 |
允許的值 | 4096-2097151 |
參數類型 | dynamic |
文件集 | work_mem |
描述
work_mem
PostgreSQL 中的 參數會控制針對每個資料庫會話私用記憶體區域內特定內部作業配置的記憶體數量。 這些作業的範例是排序和哈希。
不同於共用記憶體區域中的共用緩衝區, work_mem
會配置在每一會話或每個查詢的私人記憶體空間中。 藉由設定適當的 work_mem
大小,您可以大幅改善這些作業的效率,並減少將暫存數據寫入磁碟的需求。
重點
- 私人連線記憶體:
work_mem
是每個資料庫會話所使用的私人記憶體的一部分。 此記憶體與使用的共用記憶體區域shared_buffers
不同。 - 查詢特定用法:並非所有工作階段或查詢都使用
work_mem
。 之類的SELECT 1
簡單查詢不太可能需要work_mem
。 不過,涉及排序或哈希等作業的複雜查詢可能會取用一或多個 區塊work_mem
。 - 平行作業:對於跨越多個平行後端的查詢,每個後端都可能會使用一或多個 區塊
work_mem
。
監視和調整work_mem
請務必持續監視系統的效能,並視需要進行調整 work_mem
,主要是當與排序或哈希作業相關的查詢運行時間變慢時。 以下是使用 Azure 入口網站 中可用的工具來監視效能的方法:
- 查詢效能深入解析:檢查 [依暫存盤 排序的前一個查詢] 索引標籤,以識別產生暫存盤的查詢。 這種情況表明可能需要增加
work_mem
。 - 疑難解答指南:使用疑難解答指南中的 [ 高暫存盤 ] 索引卷標來識別有問題的查詢。
細微調整
當您管理 參數時 work_mem
,採用細微的調整方法,而不是設定全域值通常更有效率。 此方法可確保您可以根據進程和使用者的特定需求,明智地配置記憶體。 它也可將發生記憶體不足問題的風險降到最低。 以下是您可以如何進行:
用戶層級:如果特定使用者主要涉及匯總或報告工作,也就是需要大量記憶體的工作,請考慮自定義
work_mem
該使用者的值。ALTER ROLE
使用 命令來增強使用者作業的效能。函式/程式層級:如果特定函式或程式正在產生大量的暫存盤,則增加
work_mem
特定函式或程式層級的值可能會有説明。ALTER FUNCTION
使用或ALTER PROCEDURE
命令來特別配置更多記憶體給這些作業。資料庫層級:只有在特定資料庫產生大量臨時檔時,才會在資料庫層級改變
work_mem
。全域層級:如果您的系統分析顯示,大部分查詢都會產生小型臨時檔,而只有少數查詢會建立大型檔案,則全域增加
work_mem
此值可能很謹慎。 此動作可協助大部分查詢在記憶體中處理,因此您可以避免以磁碟為基礎的作業並提高效率。 不過,請務必小心並監視伺服器上的記憶體使用率,以確保它可以處理增加work_mem
的值。
判斷排序作業的最小work_mem值
若要尋找特定查詢的最小值 work_mem
,特別是一個在排序過程中產生暫存磁碟檔案的查詢,請先考慮查詢執行期間所產生的暫存盤大小。 例如,如果查詢產生 20 MB 的暫存盤:
- 使用 psql 或慣用的 PostgreSQL 用戶端,連線 至您的資料庫。
- 設定初始
work_mem
值略高於 20 MB,以在記憶體中處理時考慮其他標頭。 使用命令,例如:SET work_mem TO '25MB'
。 - 在相同會話中有問題的查詢上執行
EXPLAIN ANALYZE
。 - 檢閱的
"Sort Method: quicksort Memory: xkB"
輸出。 如果指出"external merge Disk: xkB"
,請work_mem
以累加方式提高值,並重新測試直到"quicksort Memory"
出現為止。 查詢現在在記憶體中運作的"quicksort Memory"
訊號外觀。 - 透過此方法判斷值之後,您可以全域或更細微的層級套用該值,以符合您的作業需求。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應