autovacuum_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
commit_timestamp_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於提交時間戳記快取的專用緩衝集區的大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | commit_timestamp_buffers |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 使用於雜湊表的「work_mem」倍數。 |
| 數據類型 | NUMERIC |
| 預設值 | 2 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 在 Linux 或 Windows 上使用大頁面。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
大頁面大小
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 應要求的大型分頁大小。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | huge_page_size |
io_combine_limit
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 對資料讀取和寫入的大小的限制。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 1-128 |
| 參數類型 | dynamic |
| 文件資料 | io_combine_limit |
io_max_combine_limit
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 限制 io_combine_limit 的伺服器範圍限制。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 1-128 |
| 參數類型 | dynamic |
| 文件資料 | io_max_combine_limit |
io_max_concurrency (最大併發數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 一個進程可以同時執行的 IO 數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 64 |
| 允許的值 | -1-1024 |
| 參數類型 | 靜態 |
| 文件資料 | io_max_concurrency |
io_method
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取執行非同步 I/O 的方法。 |
| 數據類型 | 列舉 |
| 預設值 | worker |
| 允許的值 | worker,sync |
| 參數類型 | 靜態 |
| 文件資料 | io_method |
io_workers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | IO 背景工作角色處理序的數目 (適用於 io_method=worker)。 |
| 數據類型 | 整數 |
| 預設值 | 3 |
| 允許的值 | 1-32 |
| 參數類型 | dynamic |
| 文件資料 | io_workers |
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 在溢出到磁碟之前，每個內部重新排序緩衝區都可以使用這麼多記憶體。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業的記憶體上限。 這包括VACUUM和CREATE INDEX等操作。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
min_dynamic_shared_memory
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟動時所保留的動態共用記憶體容量。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | min_dynamic_shared_memory |
multixact_member_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 MultiXact 成員快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 32 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | multixact_member_buffers |
multixact_offset_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 MultiXact 偏移快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | multixact_offset_buffers |
notify_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 LISTEN/NOTIFY 訊息快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | notify_buffers |
serializable_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於可序列化交易快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 32 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | 可序列化緩衝區 |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
subtransaction_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於子交易快取的專用緩衝池大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | subtransaction_buffers |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個工作階段使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
交易緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於交易狀態快取的專用緩衝池大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | 交易緩衝區 |
真空緩衝區使用上限
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定 VACUUM、ANALYZE 和 autovacuum 的緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 0-16777216 |
| 參數類型 | dynamic |
| 文件資料 | vacuum_buffer_usage_limit |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於查詢工作區的記憶體上限。 在切換到臨時磁碟檔案之前，每個內部排序操作和雜湊表都可以使用這麼多記憶體。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
commit_timestamp_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於提交時間戳記快取的專用緩衝集區的大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | commit_timestamp_buffers |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 使用於雜湊表的「work_mem」倍數。 |
| 數據類型 | NUMERIC |
| 預設值 | 2 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 在 Linux 或 Windows 上使用大頁面。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
大頁面大小
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 應要求的大型分頁大小。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | huge_page_size |
io_combine_limit
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 對資料讀取和寫入的大小的限制。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 16 |
| 參數類型 | 唯讀 |
| 文件資料 | io_combine_limit |
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 在溢出到磁碟之前，每個內部重新排序緩衝區都可以使用這麼多記憶體。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業的記憶體上限。 這包括VACUUM和CREATE INDEX等操作。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
min_dynamic_shared_memory
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟動時所保留的動態共用記憶體容量。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | min_dynamic_shared_memory |
multixact_member_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 MultiXact 成員快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 32 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | multixact_member_buffers |
multixact_offset_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 MultiXact 偏移快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | multixact_offset_buffers |
notify_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於 LISTEN/NOTIFY 訊息快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 16 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | notify_buffers |
serializable_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於可序列化交易快取的專用緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 32 |
| 允許的值 | 16-131072 |
| 參數類型 | 靜態 |
| 文件資料 | 可序列化緩衝區 |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
subtransaction_buffers
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於子交易快取的專用緩衝池大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | subtransaction_buffers |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個工作階段使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
交易緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定用於交易狀態快取的專用緩衝池大小。 指定 0 以將此值決定為 shared_buffers 的分數。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 0-131072 |
| 參數類型 | 靜態 |
| 文件資料 | 交易緩衝區 |
真空緩衝區使用上限
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定 VACUUM、ANALYZE 和 autovacuum 的緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 0-16777216 |
| 參數類型 | dynamic |
| 文件資料 | vacuum_buffer_usage_limit |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於查詢工作區的記憶體上限。 在切換到臨時磁碟檔案之前，每個內部排序操作和雜湊表都可以使用這麼多記憶體。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 要用於雜湊表的多個 work_mem。 |
| 數據類型 | NUMERIC |
| 預設值 | 2 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
大頁面大小
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 應要求的大型分頁大小。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | huge_page_size |
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
min_dynamic_shared_memory
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟動時所保留的動態共用記憶體容量。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | min_dynamic_shared_memory |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
真空緩衝區使用上限
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定 VACUUM、ANALYZE 和 autovacuum 的緩衝池大小。 |
| 數據類型 | 整數 |
| 預設值 | 256 |
| 允許的值 | 0-16777216 |
| 參數類型 | dynamic |
| 文件資料 | vacuum_buffer_usage_limit |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 要用於雜湊表的多個 work_mem。 |
| 數據類型 | NUMERIC |
| 預設值 | 2 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
大頁面大小
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 應要求的大型分頁大小。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | huge_page_size |
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
min_dynamic_shared_memory
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟動時所保留的動態共用記憶體容量。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | min_dynamic_shared_memory |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 要用於雜湊表的多個 work_mem。 |
| 數據類型 | NUMERIC |
| 預設值 | 1 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
大頁面大小
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 應要求的大型分頁大小。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | huge_page_size |
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
min_dynamic_shared_memory
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟動時所保留的動態共用記憶體容量。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0 |
| 參數類型 | 唯讀 |
| 文件資料 | min_dynamic_shared_memory |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 要用於雜湊表的多個 work_mem。 |
| 數據類型 | NUMERIC |
| 預設值 | 1 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
logical_decoding_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於邏輯解碼的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 65536 |
| 允許的值 | 64-2147483647 |
| 參數類型 | dynamic |
| 文件資料 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
hash_mem_multiplier
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 要用於雜湊表的多個 work_mem。 |
| 數據類型 | NUMERIC |
| 預設值 | 1 |
| 允許的值 | 1-1000 |
| 參數類型 | dynamic |
| 文件資料 | hash_mem_multiplier |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取要用於主要共用記憶體區域的共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | mmap |
| 允許的值 | mmap |
| 參數類型 | 唯讀 |
| 文件資料 | shared_memory_type |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：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
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個自動資料清理背景工作處理序要使用的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | -1 |
| 允許的值 | -1-2097151 |
| 參數類型 | dynamic |
| 文件資料 | autovacuum_work_mem |
動態共享記憶體類型
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 選取所使用的動態共用記憶體實作。 |
| 數據類型 | 列舉 |
| 預設值 | posix |
| 允許的值 | posix |
| 參數類型 | 唯讀 |
| 文件資料 | 動態共享記憶體類型 |
大頁
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 啟用/停用大型記憶體分頁的使用。 此設定不適用於虛擬核心少於 4 個的伺服器。 |
| 數據類型 | 列舉 |
| 預設值 | try |
| 允許的值 | on,off,try |
| 參數類型 | 靜態 |
| 文件資料 | 大頁面 |
Description
大頁面是一種允許在較大區塊中管理記憶體的功能。 您通常可以管理最多 2 MB 的區塊，而不是標準的 4 KB 頁面。
使用巨頁可以提供效能優勢，有效卸載 CPU：
- 其可減少與記憶體管理工作相關聯的額外負荷，例如較少的轉譯後備緩衝區 (TLB) 遺漏。
- 它們縮短了記憶體管理所需的時間。
具體來說，在PostgreSQL中，只能將巨頁用於共享記憶體區域。 共用記憶體區域的重要部分會配置給共用緩衝區。
另一個優點是大頁面可防止將共用記憶體區域交換到磁碟，從而進一步穩定效能。
Recommendations
- 對於具有重要記憶體資源的伺服器，請避免停用大型分頁。 停用大型頁面可能會影響效能。
- 如果您從不支援巨頁的較小伺服器開始，但您預期會擴展到支援巨頁的伺服器，請將設定保持
huge_pages為 ，TRY以實現無縫轉換和最佳效能。
Azure 特定注意事項
對於具有四個或多個 V 核心的伺服器，系統會從底層作業系統自動配置大型分頁。 此功能不適用於少於四個虛擬核心的伺服器。 如果變更任何共用記憶體的設定，包括變更 shared_buffers，巨頁數目會自動調整。
maintenance_work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定要用於維護作業 (例如 VACUUM、建立索引) 的記憶體上限。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 1024-2097151 |
| 參數類型 | dynamic |
| 文件資料 | maintenance_work_mem (維護工作記憶體) |
Description
maintenance_work_mem 是 PostgreSQL 中的配置參數。 它會控制配置給維護作業的記憶體量，例如 VACUUM、 CREATE INDEX和 ALTER TABLE。 與 work_mem影響查詢操作的記憶體分配不同， maintenance_work_mem 它保留給維護和最佳化資料庫結構的任務。
![注意] 若將
maintenance_work_mem設定得過於激進，可能會間歇性地導致系統發生記憶體耗盡錯誤。 在變更此參數之前，瞭解伺服器上可用的記憶體數量，以及可以為先前所述的工作配置記憶體的並行作業數目非常重要。
重點
-
Vacuum memory cap：如果您想透過增加
maintenance_work_mem來加速清理死元組，請注意VACUUM有收集死元組識別碼的內建限制。 此過程最多只能使用 1 GB 的內存。 -
自動清空的記憶體分離：您可以使用此
autovacuum_work_mem設定來控制自動清空作業獨立使用的記憶體。 此設定是maintenance_work_mem的一個子集。 您可以決定自動清理使用的記憶體量，而不會影響其他維護工作和資料定義作業的記憶體配置。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 maintenance_work_mem 伺服器參數的預設值。 對於支援彈性伺服器之計算的任何後續產品選擇變更，對於該執行個體 maintenance_work_mem 伺服器參數的預設值沒有任何影響。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 maintenance_work_mem 值。
用於計算 maintenance_work_mem 值的公式為 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99,328 KiB |
| 4 GiB | 157,696 KiB |
| 8 GiB | 216,064 KiB |
| 16 GiB | 274,432 KiB |
| 32 GiB | 332,800 KiB |
| 48 GiB | 367,616 KiB |
| 64 GiB | 392,192 Kibibyte |
| 80 GiB | 410,624 KiB |
| 128 GiB | 450,560 KiB |
| 160 GiB | 468,992 千字节 |
| 192 GiB | 484,352 KiB |
| 256 GiB | 508,928 KiB |
| 384 GiB | 542,720 KiB |
| 432 GiB | 552,960 千字節 |
| 672 GiB | 590,848 KiB |
max_prepared_transactions (最大預備交易數)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定同時備妥的交易數目上限。 執行複本伺服器時，您必須將此參數設定為與主要伺服器相同或更高的值。 |
| 數據類型 | 整數 |
| 預設值 | 0 |
| 允許的值 | 0-262143 |
| 參數類型 | 靜態 |
| 文件資料 | max_prepared_transactions |
最大堆疊深度 (max_stack_depth)
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定堆疊深度上限，以 KB 為單位。 |
| 數據類型 | 整數 |
| 預設值 | 2048 |
| 允許的值 | 2048 |
| 參數類型 | 唯讀 |
| 文件資料 | max_stack_depth |
共享緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定伺服器所使用的共用記憶體緩衝區數目。 單位為 8kb。 允許的值介於可用記憶體 10% - 75% 的範圍內。 |
| 數據類型 | 整數 |
| 預設值 | 取決於配置給伺服器的資源 (vCore、RAM 或磁碟空間)。 |
| 允許的值 | 16-1073741823 |
| 參數類型 | 靜態 |
| 文件資料 | shared_buffers |
Description
shared_buffers配置參數決定分配給 PostgreSQL 資料庫以緩衝資料的系統記憶體量。 它充當所有資料庫進程都可以存取的集中式記憶體池。
當需要資料時，資料庫處理程序會先檢查共用緩衝區。 如果存在所需的數據，則會快速檢索它並略過更耗時的磁盤讀取。 共用緩衝區可作為資料庫進程與磁碟之間的中介，並有效減少所需的 I/O 作業數目。
Azure 特定注意事項
當您佈建適用於 PostgreSQL 的 Azure 資料庫伺服器彈性伺服器的執行個體時，會根據您為其計算選取的產品名稱，計算 shared_buffers 伺服器參數的預設值。 任何將產品選擇更改為支援彈性伺服器的計算的後續變更，都不會影響該執行個體的 shared_buffers 伺服器參數的預設值。
每次變更指派給執行個體的產品時，您也應該根據下列公式中的值調整參數的 shared_buffers 值。
對於記憶體最多為 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 16384。
對於超過 2 GiB 的虛擬機器，用來計算 值 shared_buffers 的公式為 memoryGib * 32768。
根據上一個公式，下表列出此伺服器參數會設定的值，實際情況依佈建的記憶體數量而定：
| 記憶體大小 | 共享緩衝區 |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
暫存緩衝區
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定每個資料庫工作階段所使用的暫存緩衝區數目上限。 |
| 數據類型 | 整數 |
| 預設值 | 1024 |
| 允許的值 | 100-1073741823 |
| 參數類型 | dynamic |
| 文件資料 | temp_buffers |
work_mem
| Attribute | 價值觀 |
|---|---|
| 類別 | 資源使用狀況/記憶體 |
| Description | 設定在寫入到暫存磁碟檔案之前，內部排序作業和雜湊表所使用的記憶體數量。 |
| 數據類型 | 整數 |
| 預設值 | 4096 |
| 允許的值 | 4096-2097151 |
| 參數類型 | dynamic |
| 文件資料 | work_mem |
Description
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 用戶端連線至您的資料庫。
- 設定略高於 20 MB 的初始
work_mem值，以在記憶體中處理時考慮額外的標頭。 使用命令，例如：SET work_mem TO '25MB'。 - 在相同工作階段有問題的查詢上執行
EXPLAIN ANALYZE。 - 檢閱
"Sort Method: quicksort Memory: xkB"的輸出。 如果它顯示"external merge Disk: xkB"，以累加方式提高work_mem值並重新測試，直到"quicksort Memory"出現。 的"quicksort Memory"出現表示查詢現在正在記憶體中運作。 - 透過此方法判斷值之後，您可以全域套用它，或套用至更精細的層級 （如先前所述），以符合您的作業需求。