資源使用狀況/記憶體
autovacuum_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個自動資料清理背景工作處理序所要使用的記憶體上限。 |
| 資料類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件集 | autovacuum_work_mem (英文) |
dynamic_shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取所使用的動態共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
hash_mem_multiplier
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要用於雜湊資表的多個 work_mem。 |
| 資料類型 | numeric |
| 預設值 | 2 |
| 允許的值 | 2 |
| 參數類型 | 唯讀 |
| 文件集 | hash_mem_multiplier (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
huge_page_size
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 應要求之大型分頁的大小。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | huge_page_size (英文) |
logical_decoding_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於邏輯解碼的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 65536 |
| 參數類型 | 唯讀 |
| 文件集 | logical_decoding_work_mem (英文) |
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
min_dynamic_shared_memory
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要在啟動時保留的動態共用記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | min_dynamic_shared_memory (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | static |
| 文件集 | shared_buffers (英文) |
描述
shared_buffers 設定參數會決定配置給 PostgreSQL 資料庫以進行資料緩衝的系統記憶體數量。 其可作為可供所有資料庫處理序存取的集中式記憶體集區。
需要資料時，資料庫處理序會先檢查共用緩衝區。 如果必要資料存在，則會快速加以擷取並略過更耗時的磁碟讀取。 透過作為資料庫處理序與磁碟之間的媒介，shared_buffers 可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時，shared_buffers 設定值會以 (近似) 線性的方式縮放。
shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件集 | shared_memory_type (英文) |
temp_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 資料類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件集 | temp_buffers (英文) |
work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 在寫入暫存磁碟檔案之前，設定內部排序作業和雜湊表所使用的記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件集 | work_mem |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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 |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
hash_mem_multiplier
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要用於雜湊資表的多個 work_mem。 |
| 資料類型 | numeric |
| 預設值 | 2 |
| 允許的值 | 2 |
| 參數類型 | 唯讀 |
| 文件集 | hash_mem_multiplier (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
huge_page_size
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 應要求之大型分頁的大小。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | huge_page_size (英文) |
logical_decoding_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於邏輯解碼的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 65536 |
| 參數類型 | 唯讀 |
| 文件集 | logical_decoding_work_mem (英文) |
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
min_dynamic_shared_memory
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要在啟動時保留的動態共用記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | min_dynamic_shared_memory (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | static |
| 文件集 | shared_buffers (英文) |
描述
shared_buffers 設定參數會決定配置給 PostgreSQL 資料庫以進行資料緩衝的系統記憶體數量。 其可作為可供所有資料庫處理序存取的集中式記憶體集區。
需要資料時，資料庫處理序會先檢查共用緩衝區。 如果必要資料存在，則會快速加以擷取並略過更耗時的磁碟讀取。 透過作為資料庫處理序與磁碟之間的媒介，shared_buffers 可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時，shared_buffers 設定值會以 (近似) 線性的方式縮放。
shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件集 | shared_memory_type (英文) |
temp_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 資料類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件集 | temp_buffers (英文) |
work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 在寫入暫存磁碟檔案之前，設定內部排序作業和雜湊表所使用的記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件集 | work_mem |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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 |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
hash_mem_multiplier
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要用於雜湊資表的多個 work_mem。 |
| 資料類型 | numeric |
| 預設值 | 1 |
| 允許的值 | 1 |
| 參數類型 | 唯讀 |
| 文件集 | hash_mem_multiplier (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
huge_page_size
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 應要求之大型分頁的大小。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | huge_page_size (英文) |
logical_decoding_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於邏輯解碼的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 65536 |
| 參數類型 | 唯讀 |
| 文件集 | logical_decoding_work_mem (英文) |
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
min_dynamic_shared_memory
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要在啟動時保留的動態共用記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件集 | min_dynamic_shared_memory (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | static |
| 文件集 | shared_buffers (英文) |
描述
shared_buffers 設定參數會決定配置給 PostgreSQL 資料庫以進行資料緩衝的系統記憶體數量。 其可作為可供所有資料庫處理序存取的集中式記憶體集區。
需要資料時，資料庫處理序會先檢查共用緩衝區。 如果必要資料存在，則會快速加以擷取並略過更耗時的磁碟讀取。 透過作為資料庫處理序與磁碟之間的媒介，shared_buffers 可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時，shared_buffers 設定值會以 (近似) 線性的方式縮放。
shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件集 | shared_memory_type (英文) |
temp_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 資料類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件集 | temp_buffers (英文) |
work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 在寫入暫存磁碟檔案之前，設定內部排序作業和雜湊表所使用的記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件集 | work_mem |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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 |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
hash_mem_multiplier
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要用於雜湊資表的多個 work_mem。 |
| 資料類型 | numeric |
| 預設值 | 1 |
| 允許的值 | 1 |
| 參數類型 | 唯讀 |
| 文件集 | hash_mem_multiplier (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
logical_decoding_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於邏輯解碼的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 65536 |
| 參數類型 | 唯讀 |
| 文件集 | logical_decoding_work_mem (英文) |
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | static |
| 文件集 | shared_buffers (英文) |
描述
shared_buffers 設定參數會決定配置給 PostgreSQL 資料庫以進行資料緩衝的系統記憶體數量。 其可作為可供所有資料庫處理序存取的集中式記憶體集區。
需要資料時，資料庫處理序會先檢查共用緩衝區。 如果必要資料存在，則會快速加以擷取並略過更耗時的磁碟讀取。 透過作為資料庫處理序與磁碟之間的媒介，shared_buffers 可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時，shared_buffers 設定值會以 (近似) 線性的方式縮放。
shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件集 | shared_memory_type (英文) |
temp_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 資料類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件集 | temp_buffers (英文) |
work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 在寫入暫存磁碟檔案之前，設定內部排序作業和雜湊表所使用的記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件集 | work_mem |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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 |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
hash_mem_multiplier
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 要用於雜湊資表的多個 work_mem。 |
| 資料類型 | numeric |
| 預設值 | 1 |
| 允許的值 | 1 |
| 參數類型 | 唯讀 |
| 文件集 | hash_mem_multiplier (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | static |
| 文件集 | shared_buffers (英文) |
描述
shared_buffers 設定參數會決定配置給 PostgreSQL 資料庫以進行資料緩衝的系統記憶體數量。 其可作為可供所有資料庫處理序存取的集中式記憶體集區。
需要資料時，資料庫處理序會先檢查共用緩衝區。 如果必要資料存在，則會快速加以擷取並略過更耗時的磁碟讀取。 透過作為資料庫處理序與磁碟之間的媒介，shared_buffers 可有效地減少所需的 I/O 作業數目。
Azure 特定注意事項
當階層中的虛擬核心增加時，shared_buffers 設定值會以 (近似) 線性的方式縮放。
shared_memory_type
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 資料類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件集 | shared_memory_type (英文) |
temp_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 資料類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件集 | temp_buffers (英文) |
work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 在寫入暫存磁碟檔案之前，設定內部排序作業和雜湊表所使用的記憶體數量。 |
| 資料類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件集 | work_mem |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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 |
| 參數類型 | 唯讀 |
| 文件集 | dynamic_shared_memory_type (英文) |
huge_pages
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 啟用/停用大型記憶體分頁的使用。 此設定不適用於具有少於 4 個 V 核心的伺服器。 |
| 資料類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | static |
| 文件集 | huge_pages (英文) |
描述
大型分頁是一項功能，能以較大區塊的形式來管理記憶體。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 分頁。
使用大型分頁可提供可能有效卸載 CPU 的效能優勢：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 其能縮短記憶體管理所需的時間。
具體而言，在 PostgreSQL 中，您只能針對共用記憶體區域使用大型分頁。 共用記憶體區域的絕大部分都會配置給共用緩衝區。
另一個優點是，大型分頁會防止將共用記憶體區域交換到磁碟，其能進一步穩定效能。
建議
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型分頁可能會危害效能。
- 如果您從不支援大型分頁的較小伺服器開始，但您預期會擴大至支援大型分頁的伺服器，請將
huge_pages設定保持在TRY，以獲得順暢的轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於具有少於四個 V 核心的伺服器。 如果變更任何共用記憶體設定 (包括對 shared_buffers 的變更)，系統會自動調整大型分頁數目。
maintenance_work_mem
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定要用於維護作業 (例如 VACUUM、建立索引) 的最大記憶體。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件集 | maintenance_work_mem |
描述
maintenance_work_mem 是 PostgreSQL 中的設定參數。 其會控管配置給如下列維護作業的記憶體數量：VACUUM、CREATE INDEX 和 ALTER TABLE。 不同於會影響查詢作業記憶體配置的 work_mem，maintenance_work_mem 會保留給維護及最佳化資料庫結構的工作。
重點
- Vacuum memory cap (資料清理記憶體上限)：如果您想要透過增加
maintenance_work_mem來加快清除無效 Tuple 的速度，請注意VACUUM有收集無效 Tuple 識別項的內建限制。 其針對此處理序最多只能使用 1 GB 的記憶體。 - Separation of memory for autovacuum (針對自動資料清理區隔記憶體)：您可以使用
autovacuum_work_mem設定來控制自動資料清理作業獨立使用的記憶體。 此設定可作為maintenance_work_mem的子集。 您可以決定在不會影響其他維護工作和資料定義作業之記憶體配置的情況下，要讓記憶體自動資料清理使用多少記憶體。
max_prepared_transactions
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定同時準備交易的數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同的或更高的值。 |
| 資料類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | static |
| 文件集 | max_prepared_transactions (英文) |
max_stack_depth
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定最大堆疊深度，以 KB 為單位。 |
| 資料類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件集 | max_stack_depth (英文) |
shared_buffers
| 屬性 | 值 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| 描述 | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 資料類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、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 |
描述
PostgreSQL 中的 work_mem 參數會控制針對每個資料庫工作階段私人記憶體區域中特定內部作業所配置的記憶體數量。 這些作業的其中一個範例是排序和雜湊。
不同於位於共用記憶體區域中的共用緩衝區，work_mem 會配置在每個工作階段或每個查詢私人記憶體空間中。 透過設定適當的 work_mem 大小，您可以大幅提升這些作業的效率，並減少將暫存資料寫入磁碟的需求。
重點
- Private connection memory (私人連線記憶體)：
work_mem是每個資料庫工作階段使用之私人記憶體的一部分。 此記憶體與shared_buffers使用的共用記憶體區域不同。 - Query-specific usage (查詢特定使用方式)：並非所有工作階段或查詢都會使用
work_mem。SELECT 1之類的簡單查詢不太可能會需要work_mem。 不過，牽涉到排序或雜湊等作業的複雜查詢可能會取用一或多個work_mem區塊。 - Parallel operations (平行作業)：對於跨越多個平行後端的查詢，每個後端都可能會使用一或多個
work_mem區塊。
監視和調整 work_mem
請務必持續監視系統的效能，並視需要調整 work_mem，特別是如果與排序或雜湊作業相關的查詢執行時間緩慢。 以下是使用 Azure 入口網站中提供的工具來監視效能的方法：
- 查詢效能深入解析：檢查 [Top queries by temporary files] \(依暫存檔案排序的前幾名查詢\) 索引標籤來識別產生暫存檔案的查詢。 這種情況表示可能需要增加
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"的外觀表示查詢現在正在記憶體內運作。 - 透過此方法判斷值之後，您便能以全域或更細微的層級 (如上所述) 套用該值，以符合您的作業需求。