《Greenplum5.0 最佳實踐》 記憶體與資源隊列 （四）Greenplum 記憶體參數的配置

避免記憶體錯誤和GPDB資源問題

記憶體管理對GPDB叢集具有重要的性能影響。大多數環境推薦使用預設設定。不要去改變預設設定，除非你真的了解了自己系統的需求。

記憶體不足錯誤繪制出遇到記憶體不足錯誤的GPDB的段資料庫，節點，程序資訊

例如:

<code>Out of memeory ( seg27 host. example.com pid = 47093 ) VM Protecte failed to allocate 4096 bytes , 0MB available</code>

<code></code>

通常情況下GPDB記憶體溢出的情況可以歸因于以下情況：

系統本身記憶體資源就不足，不夠使用

在段資料庫層次上，資料傾斜

在查詢層次上，計算傾斜

解決GPDB記憶體溢出的情況，可以是用如下方法

修改查詢語句，盡量減少記憶體消耗

使用資源隊列，減少并發查詢的數量

在資料庫層面上檢查 gp_vmem_protect_limit 參數配置。 使用下面的例子計算該值

在資源隊列中，為每一個查詢設定記憶體配額

是用會話設定來減少查詢的 statement_mem在資料庫層面減少 statememt_mem

減少叢集中節點上段資料庫的數量，但是這需要重新安裝資料庫叢集和重新加載資料

在節點上增加硬體資源，如果可能（可以根據自身需求添加）

增加段資料庫的數量并不會緩和記憶體不足的問題。每個查詢使用的記憶體是有 statememt_mem 來确定的。

增加節點，并減少段資料庫的數量，調整 gp_vmem_protect_limit 增加，來提升記憶體配置設定量。

如果認真配置系統參數可以很好的避免大部分記憶體溢出問題。

如果不能增加系統硬體資源，我們可以通過配置資源隊列來管理任務，避免記憶體溢出。

當段資料庫失效時，記憶體需求對于鏡像段來說非常重要，因為它需要

推薦如下的系統設定和資料庫記憶體參數設定

不要是用系統級别的大存儲頁

vm.overcommit_memory 系統級的參數設定。推薦設定為2， 它決定系統配置設定多少資源給程序使用。

vm.overcommit_ratio linux系統級别的參數設定。記憶體使用的百分比。預設設定為50.如果這個值設定的太高，将會導緻系統沒有可用的資源，這也會導緻段失敗或者資料庫失敗; 如果這個隻設定的太低，将會導緻查詢的并發量和查詢的複雜度，可以通過減少資料庫叢集的設定記憶體量實作。如果要增加該值，一定要記住保留部分資源留給作業系統使用。

gp_vmem_protect_limit . 段資料庫上的全部工作所能申請的最大記憶體由該值控制。永遠不要設定該值大于作業系統所含有的實體記憶體大小 （RAM）。如果設定太大，很容易引起問題，操作失敗等。如果設定的值太小，也有問題。例如，真正系統需要記憶體時，會被制止。查詢很可能會失敗，因為hiting 受限。但是卻可以很好的保護段數劇庫失效和節點失效的問題。

runaway_detector_activation_percent中止失控查詢，引入到GPDB4.3.4，避免記憶體異常。

這個參數 runaway_detector_activation_percent 系統參數控制記憶體使用了 gp_vmem_protect_limit 的到達某個百分比，然後去觸發中止失控查詢。

這個值的預設值為90%。如果在段資料庫上，使用的記憶體量超過這個百分比，GPDB将會根據記憶體使用情況中止查詢。查詢記憶體使用量低于要求的百分比，将不會被中止。

statement_mem一個段資料庫中，一條查詢使用的記憶體量。如果多餘該值的記憶體被申請，将會産生溢出檔案到磁盤上。使用如下公式來确定 statement_mem 的值.

statement_mem 的預設值是125MB。例如， 一個查詢運作在DEll EMC DCA V2 系統上，使用預設值将會改變為 1GB 記憶體對于每一個段資料庫（8 segments * 125MB）。 在會話層面設定

statement_mem 去完成查詢任務。這種設定任務将會降低查詢的并發性。對于叢集高并發使用資源隊列來實作額外的控制，叢集運作多少查詢。

gp_workfle_limit_files_per_query 這個參數用來控制磁盤溢出檔案的最大數量對于每一個查詢任務。 溢出檔案是在查詢需要更多的記憶體資源時，建立的磁盤臨時檔案。當某一查詢申請的磁盤溢出檔案數量超過該值時，就會導緻查詢被中止。這個值預設是0，意味着對于查詢語句的溢出檔案數量沒有限制，知道溢出檔案數量填滿整個檔案系統為止。想想很瘋狂。

gp_workfile_compress_algorithm 為溢出檔案設定壓縮算法，可以避免溢出檔案太大的問題，減輕I/O操作的壓力。

叢集所含有實體記憶體為： 256GB

交換空間 SWAP ： 64GB

一共有4個節點，其中每一個節點有 8個段資料庫，8個鏡像段資料庫；

每個主節點最多允許失敗的節點數是11

<code>vm.overcommit_ratio = ( RAM - (0.026 * gp_vmeme) )/RAM</code>

是以設定 vm.overcommit_ratio = 98

計算

GPDB 資源隊列為管理整個叢集的負載提供非常有力的機制。資源隊列可以限制在隊列中查詢的數量和查詢語句記憶體的使用量。當一個查詢送出給GPDB叢集，它就會被追加到資源隊列中。這決定了這個查詢是否被資源隊列接收并确定是否有足夠的資源用于查詢的執行。

将所有使用者和管理者定義的資源隊列關聯，每一個登入的使用者都有自己的資源隊列；這個使用者送出的任何查詢都将會和管理者提供的資源隊列關聯起來。如果沒有顯示的配置設定隊列，則使用者的查詢将會轉換為預設隊列。

不要使用 gpadmin 使用者或者其他超級使用者角色去運作查詢。因為超級使用者并不受資源隊列的限制，超級使用者運作在其指定的資源隊列上，并且不受之前設定的參數限制。

使用 ACTIVE_STATEMENTS 資源隊列參數來限制特定的資源隊列成員可以同時運作的活動查詢的數量

使用 MEMORY_LIMIT 參數來限制資源隊列中全部查詢所能使用的記憶體總量。通過結合 ACTIVE_STATEMENTS 和 MEMORY_LIMIT 屬性，管理者可以完全控制從給定資源隊列發出的活動。配置設定工作如下

提供一個資源隊列， 名稱為： sample_queue， ACTIVE_STATEMENTS 設定為10 ， MEMORY_LIMIT 設定為2000MB。 這個資源隊列對每個段資料庫上執行查詢的記憶體限制為近似為 2GB。 對于一個叢集，每個節點上有8個段資料庫，那麼該節點執行查詢所需要的記憶體為 16GB 對于 sample_queue 這個隊列。 （2GB 8 segmnet / server）。假設一個節點有64GB記憶體，那麼像 sample_queue 這樣的資源隊列不要超過4個 （4 queues 16 GB per queue）。

請注意，通過使用 STATEMENT_MEM , 在隊列中運作各個查詢可以配置設定更多多餘他們 "share" 的内部才能。 進而減少可用于其他查詢的記憶體。

可以使用資源隊列來控制工作負載以獲得期望的效果。具有MAX優先級的隊列會阻止其他較低優先級的隊列運作。直到MAX隊列都執行完，較低優先級的隊裡才執行

根據負載和一天中的時間段動态調整資源隊列的優先級以滿足業務需求。根據時間段和系統的使用情況，典型的環境會有動态調整隊列優先級的操作流。可以通過腳本實作工作流并加入到 crontab 中。

使用 gptoolkit 工具來檢視監控資源隊列的使用情況，了解隊列的工作原理