Greenplum配置參數優化：5.10.2

Greenplum參數配置優化:

work_mem（,global,實體記憶體的2%-4%）,segment用作sort,hash操作的記憶體大小

當PostgreSQL對大表進行排序時，資料庫會按照此參數指定大小進行分片排序，将中間結果存放在臨時檔案中，這些中間結果的臨時檔案最終會再次合并排序，是以增加此參數可以減少臨時檔案個數進而提升排序效率。當然如果設定過大，會導緻swap的發生，是以設定此參數時仍需謹慎。

global，CREATE INDEX, VACUUM等時用到,segment用于VACUUM,CREATE INDEX等操作的記憶體大小，預設是16兆位元組(16MB)。因為在一個資料庫會話裡， 任意時刻隻有一個這樣的操作可以執行，并且一個資料庫安裝通常不會有太多這樣的工作并發執行， 把這個數值設定得比work_mem更大是安全的。 更大的設定可以改進清理和恢複資料庫轉儲的速度。

設定每個查詢最大使用的記憶體量，該參數是防止statement_mem參數設定的記憶體過大導緻的記憶體溢出.

設定每個查詢在segment主機中可用的記憶體，該參數設定的值不能超過max_statement_mem設定的值，如果配置了資源隊列，則不能超過資源隊列設定的值。

設定活躍段執行個體的所有postgres程序可以使用的記憶體量（以MB為機關）。如果查詢超出該限制，則不會配置設定記憶體，并且查詢将失敗。請注意，這是本地參數，必須為系統中的每個段（主要段和鏡像段）設定。設定參數值時，僅指定數值。例如，要指定4096MB，請使用 4096。不要将機關 MB 添加到該值。

-v：修改的值

-m：指定master節點上該内容的值，若不加此選項，則master和其他segment一緻，或 --masteronly，表示此操作隻針對master節點。

SQL查詢配置設定的記憶體不足，Greenplum資料庫會建立溢出檔案（也叫工作檔案）。在預設情況下，一個SQL查詢最多可以建立 100000 個溢出檔案，這足以滿足大多數查詢。

該參數決定了一個查詢最多可以建立多少個溢出檔案。0 意味着沒有限制。限制溢出檔案資料可以防止失控查詢破壞整個系統。

伺服器配置參數 gp_statement_mem 控制段資料庫上單個查詢可以使用的記憶體總量。如果語句需要更多記憶體，則會溢出資料到磁盤。

（master節點，可以設為實體記憶體的85%）

這個參數告訴PostgreSQL的優化器有多少記憶體可以被用來緩存資料，以及幫助決定是否應該使用索引。這個數值越大，優化器使用索引的可能性也越大。是以這個數值應該設定成shared_buffers加上可用作業系統緩存兩者的總量。通常這個數值會超過系統記憶體總量的50%以上。

master和每個segment的可以使用的cpu個數,每個segment的配置設定線程數;

最大連接配接數，Segment建議設定成Master的5-10倍。

max_connections = 200 #(master、standby)

max_connections = 1200 #(segment)

這個參數隻有在啟動資料庫時，才能被設定。它決定能夠同時處于prepared狀态的事務的最大數目（參考PREPARE TRANSACTION指令）。如果它的值被設為0。則将資料庫将關閉prepared事務的特性。它的值通常應該和max_connections的值一樣大。每個事務消耗600位元組(b)共享記憶體。

設定每個伺服器程序允許同時打開的最大檔案數目。預設是1000。 如果核心強制一個合理的每程序限制，那麼你不用操心這個設定。 但是在一些平台上(特别是大多數BSD系統)， 核心允許獨立程序打開比個系統真正可以支援的數目大得多得檔案數。 如果你發現有"Too many open files"這樣的失敗現像，那麼就嘗試縮小這個設定。 這個值隻能在伺服器啟動的時候設定。

隻能配置segment節點，用作磁盤讀寫的記憶體緩沖區,開始可以設定一個較小的值，比如總記憶體的15%，然後逐漸增加，過程中監控性能提升和swap的情況。

設定ftsprobe線程數，此參數建議大于等于每台伺服器segments的數目。

設定發送資料到用戶端逾時時間，預設3600秒。

https://gp-docs-cn.github.io/docs/ref_guide/config_params/guc_config.html#topic_vsn_22l_z4

https://gp-docs-cn.github.io/docs/ref_guide/config_params/guc-list.html#add_missing_from

https://blog.csdn.net/tomson8975/article/details/52064339

https://blog.csdn.net/wxc20062006/article/details/50602123

https://www.cnblogs.com/zhaowenzhong/p/5667434.html