Greenplum 數(shù)據(jù)庫(kù)最佳實(shí)踐

/?

介紹本文介紹PivotalGreenplumDatabase數(shù)據(jù)庫(kù)（以下簡(jiǎn)稱：Greenplum數(shù)據(jù)庫(kù)，或GPDB）的最佳實(shí)踐。最佳實(shí)踐是指能持續(xù)產(chǎn)生比其他方法更好結(jié)果的方法或者技術(shù)，它來(lái)自于實(shí)戰(zhàn)經(jīng)驗(yàn)，并被證實(shí)了遵循這些方法可以獲得可靠的預(yù)期結(jié)果。本最佳實(shí)踐旨在通過(guò)利用所有可能的知識(shí)和技術(shù)為正確使用GPDB提供有效參考。本文不是在教您如何使用Greenplum數(shù)據(jù)庫(kù)的功能，而是幫助您在設(shè)計(jì)、實(shí)現(xiàn)和使用Greenplum數(shù)據(jù)庫(kù)時(shí)了解需要遵循哪些最佳實(shí)踐。關(guān)于如何使用和實(shí)現(xiàn)具體的Greenplum數(shù)據(jù)庫(kù)特性，請(qǐng)參考

上的Greenplum數(shù)據(jù)庫(kù)幫助文檔以與

上的Sandbox和實(shí)踐指南。本文目的不是要涵蓋整個(gè)產(chǎn)品或者產(chǎn)品特性，而是概述GPDB實(shí)踐中最重要的因素。本文不涉與依賴于GPDB具體特性的邊緣用例，后者需要精通數(shù)據(jù)庫(kù)特性和您的環(huán)境，包括SQL訪問、查詢執(zhí)行、并發(fā)、負(fù)載和其他因素。通過(guò)掌握這些最佳實(shí)踐知識(shí)，會(huì)增加GPDB集群在維護(hù)、支持、性能和可擴(kuò)展性等方面的成功率。第一章

最佳實(shí)踐概述本部分概述了Greenplum數(shù)據(jù)庫(kù)最佳實(shí)踐所涉與的概念與要點(diǎn)。數(shù)據(jù)模型GPDB是一個(gè)基于大規(guī)模并行處理(MPP)和無(wú)共享架構(gòu)的分析型數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)的數(shù)據(jù)模式與高度規(guī)范化的事務(wù)性SMP數(shù)據(jù)庫(kù)顯著不同。通過(guò)使用非規(guī)范化數(shù)據(jù)庫(kù)模式，例如具有大事實(shí)表和小維度表的星型或者雪花模式，GPDB在處理MPP分析型業(yè)務(wù)時(shí)表現(xiàn)優(yōu)異。跨表關(guān)聯(lián)(JOIN)時(shí)字段使用相同的數(shù)據(jù)類型。詳見數(shù)據(jù)庫(kù)模式設(shè)計(jì)（后續(xù)章節(jié))堆存儲(chǔ)和追加優(yōu)化存儲(chǔ)(Append-Optimized，下稱AO)若表和分區(qū)表需要進(jìn)行迭代式的批處理或者頻繁執(zhí)行單個(gè)UPDATE、DELETE或INSERT操作，使用堆存儲(chǔ)。若表和分區(qū)表需要并發(fā)執(zhí)行UPDATE、DELETE或INSERT操作，使用堆存儲(chǔ)。若表和分區(qū)表在數(shù)據(jù)初始加載后更新不頻繁，且僅以批處理方式插入數(shù)據(jù)，則使用AO存儲(chǔ)。不要對(duì)AO表執(zhí)行單個(gè)INSERT、UPDATE或DELETE操作。不要對(duì)AO表執(zhí)行并發(fā)批量UPDATE或DELETE操作，但可以并發(fā)執(zhí)行批量INSERT操作。詳見堆存儲(chǔ)和AO存儲(chǔ)（后續(xù)章節(jié))行存儲(chǔ)和列存儲(chǔ)若數(shù)據(jù)需要經(jīng)常更新或者插入，則使用行存儲(chǔ)。若需要同時(shí)訪問一個(gè)表的很多字段，則使用行存儲(chǔ)。對(duì)于通用或者混合型業(yè)務(wù)，建議使用行存儲(chǔ)。若查詢?cè)L問的字段數(shù)目較少，或者僅在少量字段上進(jìn)行聚合操作，則使用列存儲(chǔ)。若僅常常修改表的某一字段而不修改其他字段，則使用列存儲(chǔ)。詳見行存儲(chǔ)和列存儲(chǔ)（后續(xù)章節(jié))壓縮對(duì)于大AO表和分區(qū)表使用壓縮，以提高系統(tǒng)I/O。在字段級(jí)別配置壓縮?？紤]壓縮比和壓縮性能之間的平衡。詳見壓縮（后續(xù)章節(jié))分布為所有表定義分布策略：要么定義分布鍵，要么使用隨機(jī)分布。不要使用缺省分布方式。優(yōu)先選擇可均勻分布數(shù)據(jù)的單個(gè)字段做分布鍵。不要選擇經(jīng)常用于WHERE子句的字段做分布鍵。不要使用日期或時(shí)間字段做分布鍵。分布鍵和分區(qū)鍵不要使用同一字段。對(duì)經(jīng)常執(zhí)行JOIN操作的大表，優(yōu)先考慮使用關(guān)聯(lián)字段做分布鍵，盡量做到本地關(guān)聯(lián)，以提高性能。數(shù)據(jù)初始加載后或者每次增量加載后，檢查數(shù)據(jù)分布是否均勻。盡可能避免數(shù)據(jù)傾斜。詳見分布（后續(xù)章節(jié))內(nèi)存管理設(shè)置

vm.overcommit_memory

為2不要為操作系統(tǒng)的頁(yè)設(shè)置過(guò)大的值使用

gp_vmem_protect_limit

設(shè)置單個(gè)節(jié)點(diǎn)數(shù)據(jù)庫(kù)（SegmentDatabase）可以為所有查詢分配的最大內(nèi)存量。不要設(shè)置過(guò)高的

gp_vmem_protect_limit

值，也不要大于系統(tǒng)的物理內(nèi)存。gp_vmem_protect_limit

的建議值計(jì)算公式為：(SWAP+(RAM*vm.overcommit_ratio))*0.9/number_Segments_per_server使用

statement_mem

控制節(jié)點(diǎn)數(shù)據(jù)庫(kù)為單個(gè)查詢分配的內(nèi)存量。使用資源隊(duì)列設(shè)置隊(duì)列允許的當(dāng)前最大查詢數(shù)（ACTIVE_STATEMENTS）和允許使用的內(nèi)存大小（MEMORY_LIMIT）。不要使用默認(rèn)的資源隊(duì)列，為所有用戶都分配資源隊(duì)列。根據(jù)負(fù)載和時(shí)間段，設(shè)置和隊(duì)列實(shí)際需求相匹配的優(yōu)先級(jí)（PRIORITY）。保證資源隊(duì)列的內(nèi)存配額不超過(guò)

gp_vmem_protect_limit。動(dòng)態(tài)更新資源隊(duì)列配置以適應(yīng)日常工作需要。詳見內(nèi)存和負(fù)載管理（后續(xù)章節(jié))分區(qū)只為大表設(shè)置分區(qū)，不要為小表設(shè)置分區(qū)。僅在根據(jù)查詢條件可以實(shí)現(xiàn)分區(qū)裁剪時(shí)使用分區(qū)表。建議優(yōu)先使用范圍(Range)分區(qū)，否則使用列表(List)分區(qū)。根據(jù)查詢特點(diǎn)合理設(shè)置分區(qū)。不要使用相同的字段即做分區(qū)鍵又做分布鍵。不要使用默認(rèn)分區(qū)。避免使用多級(jí)分區(qū)；盡量創(chuàng)建少量的分區(qū)，每個(gè)分區(qū)的數(shù)據(jù)更多些。通過(guò)查詢計(jì)劃的EXPLAIN結(jié)果來(lái)驗(yàn)證查詢對(duì)分區(qū)表執(zhí)行的是選擇性掃描（分區(qū)裁剪）。對(duì)于列存儲(chǔ)的表，不要?jiǎng)?chuàng)建過(guò)多的分區(qū)，否則會(huì)造成物理文件過(guò)多：Physicalfiles=Segments*Columns*Partitions。詳見分區(qū)（后續(xù)章節(jié))索引一般來(lái)說(shuō)GPDB中索引不是必需的。對(duì)于高基數(shù)的列存儲(chǔ)表，如果需要遍歷且查詢選擇性較高，則創(chuàng)建單列索引。頻繁更新的列不要建立索引。在加載大量數(shù)據(jù)之前刪除索引，加載結(jié)束后再重新創(chuàng)建索引。優(yōu)先使用B樹索引。不要為需要頻繁更新的字段創(chuàng)建位圖索引。不要為唯一性字段，基數(shù)非常高或者非常低的字段創(chuàng)建位圖索引。不要為事務(wù)性負(fù)載創(chuàng)建位圖索引。一般來(lái)說(shuō)不要索引分區(qū)表。如果需要建立索引，則選擇與分區(qū)鍵不同的字段。詳見索引（后續(xù)章節(jié))資源隊(duì)列使用資源隊(duì)列管理集群的負(fù)載。為所有角色定義適當(dāng)?shù)馁Y源隊(duì)列。使用ACTIVE_STATEMENTS參數(shù)限制隊(duì)列成員可以并發(fā)運(yùn)行的查詢總數(shù)。使用MEMORY_LIMIT參數(shù)限制隊(duì)列中查詢可以使用的內(nèi)存總量。不要設(shè)置所有隊(duì)列為MEDIUM，這樣起不到管理負(fù)載的作用。根據(jù)負(fù)載和時(shí)間段動(dòng)態(tài)調(diào)整資源隊(duì)列。詳見配置資源隊(duì)列（后續(xù)章節(jié))監(jiān)控和維護(hù)根據(jù)《Greenplum數(shù)據(jù)庫(kù)管理員指南》實(shí)現(xiàn)該書推薦的監(jiān)控和管理任務(wù)。安裝Greenplum數(shù)據(jù)庫(kù)前建議運(yùn)行

gpcheckperf，安裝后定期運(yùn)行。保存輸出結(jié)果，隨著時(shí)間推移對(duì)系統(tǒng)性能進(jìn)行比較。使用所有您可用的工具，以了解系統(tǒng)不同負(fù)載下的表現(xiàn)。檢查任何不尋常的事件并確定原因。通過(guò)定期運(yùn)行解釋計(jì)劃監(jiān)控系統(tǒng)查詢活動(dòng)，以確保查詢處于最佳運(yùn)行狀態(tài)。檢查查詢計(jì)劃，以確定是否按預(yù)期使用了索引和進(jìn)行了分區(qū)裁剪。了解系統(tǒng)日志文件的位置和內(nèi)容，定期監(jiān)控日志文件，而不是在出現(xiàn)問題時(shí)才查看。詳見系統(tǒng)監(jiān)控和維護(hù)以與監(jiān)控GPDB日志文件。（后續(xù)章節(jié))ANALYZE不要對(duì)整個(gè)數(shù)據(jù)庫(kù)運(yùn)行ANALYZE，只對(duì)需要的表運(yùn)行該命令。建議數(shù)據(jù)加載后即刻運(yùn)行ANALYZE。如果INSERT、UPDATE和DELETE等操作修改大量數(shù)據(jù)，建議運(yùn)行ANALYZE。執(zhí)行CREATEINDEX操作后建議運(yùn)行ANALYZE。如果對(duì)大表ANALYZE耗時(shí)很久，則只對(duì)JOIN字段、WHERE、SORT、GROUPBY或HAVING字句的字段運(yùn)行ANALYZE。詳見使用ANALYZE更新統(tǒng)計(jì)信息。（后續(xù)章節(jié))Vaccum批量UPDATE和DELETE操作后建議執(zhí)行VACUUM。不建議使用VACUUMFULL。建議使用CTAS（CREATETABLE...AS）操作，然后重命名表名，并刪除原來(lái)的表。對(duì)系統(tǒng)表定期運(yùn)行VACUUM，以避免系統(tǒng)表臃腫和在系統(tǒng)表上執(zhí)行VACUUMFULL操作。禁止殺死系統(tǒng)表的VACUUM任務(wù)。不建議使用VACUUMANALYZE。詳見消除系統(tǒng)表臃腫。（后續(xù)章節(jié))加載使用gpfdist進(jìn)行數(shù)據(jù)的加載和導(dǎo)出。隨著段數(shù)據(jù)庫(kù)個(gè)數(shù)的增加，并行性增加。盡量將數(shù)據(jù)均勻地分布到多個(gè)ETL節(jié)點(diǎn)上。將非常大的數(shù)據(jù)文件切分成相同大小的塊，并放在盡量多的文件系統(tǒng)上。一個(gè)文件系統(tǒng)運(yùn)行兩個(gè)gpfdist實(shí)例。在盡可能多的網(wǎng)絡(luò)接口上運(yùn)行g(shù)pfdsit。使用

gp_external_max_segs

控制訪問每個(gè)gpfdist服務(wù)器的段數(shù)據(jù)庫(kù)的個(gè)數(shù)。建議gp_external_max_segs的值和gpfdist進(jìn)程個(gè)數(shù)為偶數(shù)。數(shù)據(jù)加載前刪除索引；加載完后重建索引。數(shù)據(jù)加載完成后運(yùn)行ANALYZE操作。數(shù)據(jù)加載過(guò)程中，設(shè)置

gp_autostats_mode

為NONE，取消統(tǒng)計(jì)信息的自動(dòng)收集。若數(shù)據(jù)加載失敗，使用VACUUM回收空間。詳見加載數(shù)據(jù)。（后續(xù)章節(jié))gptransfer為了更好的性能，建議使用

gptransfer

遷移數(shù)據(jù)到相同大小或者更大的集群。避免使用

--full

或者

--schema-only

選項(xiàng)。建議使用其他方法拷貝數(shù)據(jù)庫(kù)模式到目標(biāo)數(shù)據(jù)庫(kù)，然后遷移數(shù)據(jù)。遷移數(shù)據(jù)前刪除索引，遷移完成后重建索引。使用SQLCOPY命令遷移小表到目標(biāo)數(shù)據(jù)庫(kù)。使用gptransfer批量遷移大表。在正式遷移生產(chǎn)環(huán)境前測(cè)試運(yùn)行

gptransfer。試驗(yàn)

--batch-size

和

--sub-batch-size

選項(xiàng)以獲得最大平行度。如果需要，迭代運(yùn)行多次

gptransfer

來(lái)確定每次要遷移的表的批次。僅使用完全限定的表名。表名字中若含有點(diǎn)、空格、單引號(hào)和雙引號(hào)，可能會(huì)導(dǎo)致問題。如果使用

--validation

選項(xiàng)在遷移后驗(yàn)證數(shù)據(jù)，則需要同時(shí)使用

-x

選項(xiàng)，以在源表上加排它鎖。確保在目標(biāo)數(shù)據(jù)庫(kù)上創(chuàng)建了相應(yīng)的角色、函數(shù)和資源隊(duì)列。gptransfer-t

不會(huì)遷移這些對(duì)象。從源數(shù)據(jù)庫(kù)拷貝

postgres.conf

和

pg_hba.conf

到目標(biāo)數(shù)據(jù)庫(kù)集群。使用

gppkg

在目標(biāo)數(shù)據(jù)庫(kù)上安裝需要的擴(kuò)展。詳見使用gptransfer遷移數(shù)據(jù)（后續(xù)章節(jié))安全妥善保護(hù)

gpadmin

賬號(hào)，只有在必要的時(shí)候才能允許系統(tǒng)管理員訪問它。僅當(dāng)執(zhí)行系統(tǒng)維護(hù)任務(wù)（例如升級(jí)或擴(kuò)容），管理員才能以

gpadmin

登錄Greenplum集群。限制具有SUPERUSER角色屬性的用戶數(shù)。GPDB中，身為超級(jí)用戶的角色會(huì)跳過(guò)所有訪問權(quán)限檢查和資源隊(duì)列限制。僅有系統(tǒng)管理員具有數(shù)據(jù)庫(kù)超級(jí)用戶權(quán)限。參考《Greenplum數(shù)據(jù)庫(kù)管理員指南》中的“修改角色屬性”。嚴(yán)禁數(shù)據(jù)庫(kù)用戶以

gpadmin

身份登錄，嚴(yán)禁以

gpadmin

身份執(zhí)行ETL或者生產(chǎn)任務(wù)。為有登錄需求的每個(gè)用戶都分配一個(gè)不同的角色?？紤]為每個(gè)應(yīng)用或者網(wǎng)絡(luò)服務(wù)分配一個(gè)不同的角色。使用用戶組管理訪問權(quán)限。保護(hù)好ROOT的密碼。對(duì)于操作系統(tǒng)密碼，強(qiáng)制使用強(qiáng)密碼策略。確保保護(hù)好操作系統(tǒng)的重要文件。詳見安全。（后續(xù)章節(jié))加密加密和解密數(shù)據(jù)會(huì)影響性能，僅加密需要加密的數(shù)據(jù)。在生產(chǎn)系統(tǒng)中實(shí)現(xiàn)任何加密解決方案之前都要做性能測(cè)試。GPDB生產(chǎn)系統(tǒng)使用的服務(wù)器證書應(yīng)由證書簽名頒發(fā)機(jī)構(gòu)（CA）簽名，這樣客戶端可以驗(yàn)證服務(wù)器。如果所有客戶端都是本地的，則可以使用本地CA。如果客戶端與GPDB的連接會(huì)經(jīng)過(guò)不安全的鏈路，則使用SSL加密。加密和解密使用相同密鑰的對(duì)稱加密方式比非對(duì)稱加密具有更好的性能，如果密鑰可以安全共享，則建議使用對(duì)稱加密方式。使用pgcrypto包中的函數(shù)加密磁盤上的數(shù)據(jù)。數(shù)據(jù)的加密和解密都由數(shù)據(jù)庫(kù)進(jìn)程完成，為了避免傳輸明文數(shù)據(jù)，需要使用SSL加密客戶端和數(shù)據(jù)庫(kù)間的連接。數(shù)據(jù)加載和導(dǎo)出時(shí)，使用gpfdists協(xié)議保護(hù)ETL數(shù)據(jù)安全。詳見加密數(shù)據(jù)和數(shù)據(jù)庫(kù)連接。（后續(xù)章節(jié))高可用使用8到24個(gè)磁盤的硬件RAID存儲(chǔ)解決方案。使用RAID1、5或6，以使磁盤陣列可以容忍磁盤故障。為磁盤陣列配備熱備磁盤，以便在檢測(cè)到磁盤故障時(shí)自動(dòng)開始重建。在重建時(shí)通過(guò)RAID卷鏡像防止整個(gè)磁盤陣列故障和性能下降。定期監(jiān)控磁盤利用率，并在需要時(shí)增加額外的空間。定期監(jiān)控段數(shù)據(jù)庫(kù)傾斜，以確保在所有段數(shù)據(jù)庫(kù)上數(shù)據(jù)均勻分布，存儲(chǔ)空間均勻消耗。配置備用主服務(wù)器，當(dāng)主服務(wù)器發(fā)生故障時(shí)由備用主服務(wù)器接管。規(guī)劃好當(dāng)主服務(wù)器發(fā)生故障時(shí)如何切換客戶端連接到新的主服務(wù)器實(shí)例，例如通過(guò)更新DNS中主服務(wù)器的地址。建立監(jiān)控系統(tǒng)，當(dāng)主服務(wù)器發(fā)生故障時(shí)，可以通過(guò)系統(tǒng)監(jiān)控應(yīng)用或電子郵件發(fā)送通知。分配主段數(shù)據(jù)庫(kù)和其鏡像到不同的主機(jī)上，以防止主機(jī)故障。建立監(jiān)控系統(tǒng)，當(dāng)主段數(shù)據(jù)庫(kù)發(fā)生故障時(shí)，可以通過(guò)系統(tǒng)監(jiān)控應(yīng)用或電子郵件發(fā)送通知。使用

gprecoverseg

工具與時(shí)恢復(fù)故障段，并使系統(tǒng)返回最佳平衡狀態(tài)。在主服務(wù)器上配置并運(yùn)行

gpsnmpd

以發(fā)送SNMP通知給網(wǎng)絡(luò)監(jiān)控器。在

$Master_DATA_DIRECTORY/postgresql.conf

配置文件中設(shè)置郵件通知，以便檢測(cè)到關(guān)鍵問題時(shí)，Greenplum系統(tǒng)可以通過(guò)電子郵件通知管理員?？紤]雙集群配置，提供額外的冗余和查詢處理能力。除非Greenplum數(shù)據(jù)庫(kù)的數(shù)據(jù)很容易從數(shù)據(jù)源恢復(fù)，否則定期備份。如果堆表相對(duì)較小，或者兩次備份之間僅有少量AO或列存儲(chǔ)分區(qū)有變化，則使用增量備份。如果備份保存在集群的本地存儲(chǔ)系統(tǒng)上，則備份結(jié)束后，將文件移到其他的安全存儲(chǔ)系統(tǒng)上。如果備份保存到NFS中，則建議使用像EMCIsilon這樣的可擴(kuò)展NFS方案以防止I/O瓶頸。Greenplum集成了對(duì)EMC的DataDomain和Symantec的NetBackup的支持，可以流式備份到DataDomain或NetBackup企業(yè)備份平臺(tái)上。詳見高可用性（后續(xù)章節(jié))第二章系統(tǒng)配置本節(jié)描述了Greenplum數(shù)據(jù)庫(kù)集群關(guān)于主機(jī)配置的需求和最佳實(shí)踐。?

首選操作系統(tǒng)紅帽企業(yè)級(jí)Linux（RHEL）是首選操作系統(tǒng)。應(yīng)使用最新支持的主版本，目前是RHEL6。?

文件系統(tǒng)Greenplum數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄推薦使用XFS文件系統(tǒng)。使用以下選項(xiàng)掛載XFS：rw,noatime,inode64,allocsize=16m?

端口配置ip_local_port_range

的設(shè)置不要和Greenplum數(shù)據(jù)庫(kù)的端口范圍有沖突，例如：net.ipv4.ip_local_port_range=300065535PORT_BASE=2000MIRROR_PORT_BASE=2100REPLICATION_PORT_BASE=2200MIRROR_REPLICATION_PORT_BASE=2300?

I/O配置包含數(shù)據(jù)目錄的設(shè)備的預(yù)讀大小應(yīng)設(shè)為16384./sbin/blockdev--getra/dev/sdb16384

包含數(shù)據(jù)目錄的設(shè)備的I/O調(diào)度算法設(shè)置為deadline。#cat/sys/block/sdb/queue/schedulernoopanticipatory[deadline]cfq通過(guò)/etc/security/limits.conf增大操作系統(tǒng)文件數(shù)和進(jìn)程數(shù)。*softno*hardno*softnproc131072*hardnproc131072啟用core文件轉(zhuǎn)儲(chǔ)，并保存到已知位置。確保limits.conf中允許的core轉(zhuǎn)儲(chǔ)文件。kernel.core_pattern=/var/core/core.%h.%t#grepcore/etc/security/limits.conf*softcoreunlimited?

操作系統(tǒng)內(nèi)存配置Linuxsysctl的

vm.overcommit_memory

和

vm.overcommit_ratio

變量會(huì)影響操作系統(tǒng)對(duì)內(nèi)存分配的管理。這些變量應(yīng)該設(shè)置如下：vm.overcommit_memory控制操作系統(tǒng)使用什么方法確定分配給進(jìn)程的內(nèi)存總數(shù)。對(duì)于Greenplum數(shù)據(jù)庫(kù)，唯一建議值是2.vm.overcommit_ratio

控制分配給應(yīng)用程序進(jìn)程的內(nèi)存百分比。建議使用缺省值50.不要啟用操作系統(tǒng)的大內(nèi)存頁(yè)。詳見內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

共享內(nèi)存設(shè)置Greenplum數(shù)據(jù)庫(kù)中同一數(shù)據(jù)庫(kù)實(shí)例的不同

postgres

進(jìn)程間通訊使用共享內(nèi)存。使用

sysctl

配置如下共享內(nèi)存參數(shù)，且不建議修改：kernel.shmmax=500000000kernel.shmmni=4096kernel.shmall=4000000000?

驗(yàn)證操作系統(tǒng)使用

gpcheck

驗(yàn)證操作系統(tǒng)配置。參考《Greenplum數(shù)據(jù)庫(kù)工具指南》中的

gpcheck。?

設(shè)置一個(gè)主機(jī)上段數(shù)據(jù)庫(kù)個(gè)數(shù)確定每個(gè)段主機(jī)上段數(shù)據(jù)庫(kù)的個(gè)數(shù)對(duì)整體性能有著巨大影響。這些段數(shù)據(jù)庫(kù)之間共享主機(jī)的CPU核、內(nèi)存、網(wǎng)卡等，且和主機(jī)上的所有進(jìn)程共享這些資源。過(guò)高地估計(jì)每個(gè)服務(wù)器上運(yùn)行的段數(shù)據(jù)庫(kù)個(gè)數(shù)，通常是達(dá)不到最優(yōu)性能的常見原因之一。以下因素確定了一個(gè)主機(jī)上可以運(yùn)行多少個(gè)段數(shù)據(jù)庫(kù)：CPU核的個(gè)數(shù)物理內(nèi)存容量網(wǎng)卡個(gè)數(shù)與速度存儲(chǔ)空間主段數(shù)據(jù)庫(kù)和鏡像共存主機(jī)是否運(yùn)行ETL進(jìn)程主機(jī)上運(yùn)行的非Greenplum進(jìn)程?

段服務(wù)器內(nèi)存配置服務(wù)器配置參數(shù)gp_vmem_protect_limit控制了每個(gè)段數(shù)據(jù)庫(kù)為所有運(yùn)行的查詢分配的內(nèi)存總量。如果查詢需要的內(nèi)存超過(guò)此值，則會(huì)失敗。使用下面公式確定合適的值：(swap+(RAM*vm.overcommit_ratio))*.9/number_of_Segments_per_server例如，具有下面配置的段服務(wù)器：8GB交換空間128GB內(nèi)存vm.overcommit_ratio=508個(gè)段數(shù)據(jù)庫(kù)則設(shè)置gp_vmem_protect_limit為8GB：(8+(128*.5))*.9/8=8GB參見

內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

SQL語(yǔ)句內(nèi)存配置服務(wù)器配置參數(shù)

gp_statement_mem

控制段數(shù)據(jù)庫(kù)上單個(gè)查詢可以使用的內(nèi)存總量。如果語(yǔ)句需要更多內(nèi)存，則會(huì)溢出數(shù)據(jù)到磁盤。用下面公式確定合適的值：(gp_vmem_protect_limit*.9)/max_expected_concurrent_queries例如，如果并發(fā)度為40，gp_vmeme_protect_limit為8GB，則

gp_statement_mem

為：(8192MB*.9)/40=184MB每個(gè)查詢最多可以使用184MB內(nèi)存，之后將溢出到磁盤。若想安全的增大

gp_statement_mem，要么增大

gp_vmem_protect_limit，要么降低并發(fā)。要增大gp_vmem_protect_limit，必須增加物理內(nèi)存和/或交換空間，或者降低單個(gè)主機(jī)上運(yùn)行的段數(shù)據(jù)庫(kù)個(gè)數(shù)。請(qǐng)注意，為集群添加更多的段數(shù)據(jù)庫(kù)實(shí)例并不能解決內(nèi)存不足的問題，除非引入更多新主機(jī)來(lái)降低了單個(gè)主機(jī)上運(yùn)行的段數(shù)據(jù)庫(kù)的個(gè)數(shù)。了解什么是溢出文件。了解gp_work

參數(shù)，其控制了單個(gè)查詢最多可以創(chuàng)建多少個(gè)溢出文件。了解gp_work。有關(guān)使用資源隊(duì)列管理內(nèi)存的更多信息，請(qǐng)參考

內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

溢出文件配置如果為SQL查詢分配的內(nèi)存不足，Greenplum數(shù)據(jù)庫(kù)會(huì)創(chuàng)建溢出文件（也叫工作文件）。在默認(rèn)情況下，一個(gè)SQL查詢最多可以創(chuàng)建100000個(gè)溢出文件，這足以滿足大多數(shù)查詢。參數(shù)gp_work

決定了一個(gè)查詢最多可以創(chuàng)建多少個(gè)溢出文件。0意味著沒有限制。限制溢出文件數(shù)據(jù)可以防止失控查詢破壞整個(gè)系統(tǒng)。如果分配內(nèi)存不足或者出現(xiàn)數(shù)據(jù)傾斜，則一個(gè)SQL查詢可能產(chǎn)生大量溢出文件。如果超過(guò)溢出文件上限，Greenplum數(shù)據(jù)庫(kù)報(bào)告如下錯(cuò)誤：ERROR:numberofworkfilesperquerylimitexceeded在嘗試增大gp_work前，先嘗試通過(guò)修改SQL、數(shù)據(jù)分布策略或者內(nèi)存配置以降低溢出文件個(gè)數(shù)。gp_toolkit模式包括一些視圖，通過(guò)這些視圖可以看到所有使用溢出文件的查詢的信息。這些信息有助于故障排除和調(diào)優(yōu)查詢：gp_work視圖的每一行表示一個(gè)正在使用溢出文件的操作符的信息。關(guān)于操作符，參考

如何理解查詢計(jì)劃解釋。（后續(xù)章節(jié))gp_work視圖的每一行表示一個(gè)正在使用溢出文件的SQL查詢的信息。gp_work視圖的每一行對(duì)應(yīng)一個(gè)段數(shù)據(jù)庫(kù)，包含了該段上使用的溢出文件占用的磁盤空間總量。關(guān)于這些視圖的字段涵義，請(qǐng)參考《Greenplum數(shù)據(jù)庫(kù)參考指南》。參數(shù)

gp_work指定溢出文件的壓縮算法：none或者zlib。第三章數(shù)據(jù)庫(kù)模式設(shè)計(jì)GPDB是一個(gè)基于大規(guī)模并行處理（MPP）和無(wú)共享架構(gòu)的分析型數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)的數(shù)據(jù)模式與高度規(guī)范化的事務(wù)性SMP數(shù)據(jù)庫(kù)顯著不同。使用非規(guī)范化數(shù)據(jù)庫(kù)模式，例如具有大事實(shí)表和小維度表的星型或者雪花模式，處理MPP分析型業(yè)務(wù)時(shí)，Greenplum數(shù)據(jù)庫(kù)表現(xiàn)優(yōu)異。?

數(shù)據(jù)類型類型一致性關(guān)聯(lián)列使用相同的數(shù)據(jù)類型。如果不同表中的關(guān)聯(lián)列數(shù)據(jù)類型不同，GPDB必須動(dòng)態(tài)的進(jìn)行類型轉(zhuǎn)換以進(jìn)行比較?？紤]到這一點(diǎn)，你可能需要增大數(shù)據(jù)類型的大小，以便關(guān)聯(lián)操作更高效。類型最小化建議選擇最高效的類型存儲(chǔ)數(shù)據(jù)，這可以提高數(shù)據(jù)庫(kù)的有效容量與查詢執(zhí)行性能。建議使用TEXT或者VARCHAR而不是CHAR。不同的字符類型間沒有明顯的性能差別，但是TEXT或者VARCHAR可以降低空間使用量。建議使用滿足需求的最小數(shù)值類型。如果INT或SAMLLINT夠用，那么選擇BIGINT會(huì)浪費(fèi)空間。?

存儲(chǔ)模型在Greenplum數(shù)據(jù)庫(kù)中，創(chuàng)建表時(shí)可以選擇不同的存儲(chǔ)類型。需要清楚什么時(shí)候該使用堆存儲(chǔ)、什么時(shí)候使用追加優(yōu)化(AO)存儲(chǔ)、什么時(shí)候使用行存儲(chǔ)、什么時(shí)候使用列存儲(chǔ)。對(duì)于大型事實(shí)表這尤為重要。相比而言，對(duì)小的維度表就不那么重要了。選擇合適存儲(chǔ)模型的常規(guī)最佳實(shí)踐為：對(duì)于大型事實(shí)分區(qū)表，評(píng)估并優(yōu)化不同分區(qū)的存儲(chǔ)選項(xiàng)。一種存儲(chǔ)模型可能滿足不了整個(gè)分區(qū)表的不同分區(qū)的應(yīng)用場(chǎng)景，例如某些分區(qū)使用行存儲(chǔ)而其他分區(qū)使用列存儲(chǔ)。使用列存儲(chǔ)時(shí)，段數(shù)據(jù)庫(kù)內(nèi)每一列對(duì)應(yīng)一個(gè)文件。對(duì)于有大量列的表，經(jīng)常訪問的數(shù)據(jù)使用列存儲(chǔ)，不常訪問的數(shù)據(jù)使用行存儲(chǔ)。在分區(qū)級(jí)別或者在數(shù)據(jù)存儲(chǔ)級(jí)別上設(shè)置存儲(chǔ)類型。如果集群需要更多空間，或者期望提高I/O性能，考慮使用壓縮。堆存儲(chǔ)和AO存儲(chǔ)堆存儲(chǔ)是默認(rèn)存儲(chǔ)模型，也是PostgreSQL存儲(chǔ)所有數(shù)據(jù)庫(kù)表的模型。如果表和分區(qū)經(jīng)常執(zhí)行UPDATE、DELETE操作或者單個(gè)INSERT操作，則使用堆存儲(chǔ)模型。如果需要對(duì)表和分區(qū)執(zhí)行并發(fā)UPDATE、DELETE、INSERT操作，也使用堆存儲(chǔ)模型。如果數(shù)據(jù)加載后很少更新，之后的插入也是以批處理方式執(zhí)行，則使用追加優(yōu)化(AO)存儲(chǔ)模型。千萬(wàn)不要對(duì)AO表執(zhí)行單個(gè)INSERT/UPDATE/DELETE操作。并發(fā)批量INSERT操作是可以的，但是不要執(zhí)行并發(fā)批量UPDATE或者DELETE操作。AO表中執(zhí)行刪除和更新操作后行所占空間的重用效率不如堆表，所以這種存儲(chǔ)類型不適合頻繁更新的表。AO表主要用于分析型業(yè)務(wù)中加載后很少更新的大表。行存儲(chǔ)和列存儲(chǔ)行存儲(chǔ)是存儲(chǔ)數(shù)據(jù)庫(kù)元組的傳統(tǒng)方式。一行的所有列在磁盤上連續(xù)存儲(chǔ)，所以一次I/O可以從磁盤上讀取整個(gè)行。列存儲(chǔ)在磁盤上將同一列的值保存在一塊。每一列對(duì)應(yīng)一個(gè)單獨(dú)的文件。如果表是分區(qū)表，那么每個(gè)分區(qū)的每個(gè)列對(duì)應(yīng)一個(gè)單獨(dú)的文件。如果列存儲(chǔ)表有很多列，而SQL查詢只訪問其中的少量列，那么I/O開銷與行存儲(chǔ)表相比大大降低，因?yàn)椴恍枰獜拇疟P上讀取不需要訪問的列。交易型業(yè)務(wù)中更新和插入頻繁，建議使用行存儲(chǔ)。如果需要同時(shí)訪問寬表的很多字段時(shí)，建議使用行存儲(chǔ)。如果大多數(shù)字段會(huì)出現(xiàn)在SELECT列表中或者WHERE子句中，建議使用行存儲(chǔ)。對(duì)于通用的混合型負(fù)載，建議使用行存儲(chǔ)。行存儲(chǔ)提供了靈活性和性能的最佳組合。列存儲(chǔ)是為讀操作而非寫操作優(yōu)化的一種存儲(chǔ)方式，不同字段存儲(chǔ)在磁盤上的不同位置。對(duì)于有很多字段的大型表，如果單個(gè)查詢只需訪問較少字段，那么列存儲(chǔ)性能優(yōu)異。列存儲(chǔ)的另一個(gè)好處是相同類型的數(shù)據(jù)存儲(chǔ)在一起比混合類型數(shù)據(jù)占用的空間少，因而列存儲(chǔ)表比行存儲(chǔ)表使用的磁盤空間小。列存儲(chǔ)的壓縮比也高于行存儲(chǔ)。數(shù)據(jù)倉(cāng)庫(kù)的分析型業(yè)務(wù)中，如果SELECT訪問少量字段或者在少量字段上執(zhí)行聚合計(jì)算，則建議使用列存儲(chǔ)。如果只有單個(gè)字段需要頻繁更新而不修改其他字段，則建議列存儲(chǔ)。從一個(gè)寬列存儲(chǔ)表中讀完整的行比從行存儲(chǔ)表中讀同一行需要更多時(shí)間。特別要注意的是，GPDB每個(gè)段數(shù)據(jù)庫(kù)上每一列都是一個(gè)獨(dú)立的物理文件。?

壓縮Greenplum數(shù)據(jù)庫(kù)為AO表和分區(qū)提供多種壓縮選項(xiàng)。使用壓縮后，每次磁盤讀操作可以讀入更多的數(shù)據(jù)，因而可以提高I/O性能。建議在實(shí)際保存物理數(shù)據(jù)的那一層設(shè)置字段壓縮方式。請(qǐng)注意，新添加的分區(qū)不會(huì)自動(dòng)繼承父表的壓縮方式，必須在創(chuàng)建新分區(qū)時(shí)明確指定壓縮選項(xiàng)。Delta和RLE的壓縮比較高。高壓縮比使用的磁盤空間較少，但是在寫入數(shù)據(jù)或者讀取數(shù)據(jù)時(shí)需要額外的時(shí)間和CPU周期進(jìn)行壓縮和解壓縮。壓縮和排序聯(lián)合使用，可以達(dá)到最好的壓縮比。在壓縮文件系統(tǒng)上不要再使用數(shù)據(jù)庫(kù)壓縮。測(cè)試不同的壓縮類型和排序方法以確定最適合自己數(shù)據(jù)的壓縮方式。?

分布(DISTRIBUTIONS)選擇能夠均勻分布數(shù)據(jù)的分布鍵對(duì)Greenplum數(shù)據(jù)庫(kù)非常重要。在大規(guī)模并行處理無(wú)共享環(huán)境中，查詢的總體響應(yīng)時(shí)間取決于所有段數(shù)據(jù)庫(kù)的完成時(shí)間。集群的最快速度與最慢的那個(gè)段數(shù)據(jù)庫(kù)一樣。如果存在嚴(yán)重?cái)?shù)據(jù)傾斜現(xiàn)象，那么數(shù)據(jù)較多的段數(shù)據(jù)庫(kù)響應(yīng)時(shí)間將更久。每個(gè)段數(shù)據(jù)庫(kù)最好有數(shù)量接近的數(shù)據(jù)，處理時(shí)間也相似。如果一個(gè)段數(shù)據(jù)庫(kù)處理的數(shù)據(jù)顯著比其他段多，那么性能會(huì)很差，并可能出現(xiàn)內(nèi)存溢出錯(cuò)誤。確定分布策略時(shí)考慮以下最佳實(shí)踐：為所有表要么明確地指明其分布字段，要么使用隨機(jī)分布。不要使用默認(rèn)方式。理想情況下，使用能夠?qū)?shù)據(jù)均勻分布到所有段數(shù)據(jù)庫(kù)上的一個(gè)字段做分布鍵。不要使用常出現(xiàn)在查詢的WHERE子句中的字段做分布鍵。不要使用日期或者時(shí)間字段做分布鍵。分布字段的數(shù)據(jù)要么是唯一值要么基數(shù)很大。如果單個(gè)字段不能實(shí)現(xiàn)數(shù)據(jù)均勻分布，則考慮使用兩個(gè)字段做分布鍵。作為分布鍵的字段最好不要超過(guò)兩個(gè)。GPDB使用哈希進(jìn)行數(shù)據(jù)分布，使用更多的字段通常不能得到更均勻的分布，反而耗費(fèi)更多的時(shí)間計(jì)算哈希值。如果兩個(gè)字段也不能實(shí)現(xiàn)數(shù)據(jù)的均勻分布，則考慮使用隨機(jī)分布。大多數(shù)情況下，如果分布鍵字段超過(guò)兩個(gè)，那么執(zhí)行表關(guān)聯(lián)時(shí)通常需要節(jié)點(diǎn)間的數(shù)據(jù)移動(dòng)操作（Motion），如此一來(lái)和隨機(jī)分布相比，沒有明顯優(yōu)勢(shì)。Greenplum數(shù)據(jù)庫(kù)的隨機(jī)分布不是輪詢算法，不能保證每個(gè)節(jié)點(diǎn)的記錄數(shù)相同，但是通常差別會(huì)小于10%。關(guān)聯(lián)大表時(shí)最優(yōu)分布至關(guān)重要。關(guān)聯(lián)操作需要匹配的記錄必須位于同一段數(shù)據(jù)庫(kù)上。如果分布鍵和關(guān)聯(lián)字段不同，則數(shù)據(jù)需要?jiǎng)討B(tài)重分發(fā)。某些情況下，廣播移動(dòng)操作（Motion）比重分布移動(dòng)操作效果好。本地（Co-located）關(guān)聯(lián)如果所用的哈希分布能均勻分布數(shù)據(jù)，并導(dǎo)致本地關(guān)聯(lián)，那么性能會(huì)大幅提升。本地關(guān)聯(lián)在段數(shù)據(jù)庫(kù)內(nèi)部執(zhí)行，和其他段數(shù)據(jù)庫(kù)沒有關(guān)系，避免了網(wǎng)絡(luò)通訊開銷，避免或者降低了廣播移動(dòng)操作和重分布移動(dòng)操作。為經(jīng)常關(guān)聯(lián)的大表使用相同的字段做分布鍵可實(shí)現(xiàn)本地關(guān)聯(lián)。本地關(guān)聯(lián)需要關(guān)聯(lián)的雙方使用相同的字段（且順序相同）做分布鍵，并且關(guān)聯(lián)時(shí)所有的字段都被使用。分布鍵數(shù)據(jù)類型必須相同。如果數(shù)據(jù)類型不同，磁盤上的存儲(chǔ)方式可能不同，那么即使值看起來(lái)相同，哈希值也可能不一樣。數(shù)據(jù)傾斜數(shù)據(jù)傾斜是很多性能問題和內(nèi)存溢出問題的根本原因。數(shù)據(jù)傾斜不僅影響掃描/讀性能，也會(huì)影響很多其他查詢執(zhí)行操作符，例如關(guān)聯(lián)操作、分組操作等。數(shù)據(jù)初始加載后，驗(yàn)證并保證數(shù)據(jù)分布的均勻性非常重要；每次增量加載后，都要驗(yàn)證并保證數(shù)據(jù)分布的均勻性。下面的查詢語(yǔ)句統(tǒng)計(jì)每個(gè)段數(shù)據(jù)庫(kù)上的記錄的條數(shù)，并根據(jù)最大和最小行數(shù)計(jì)算方差：SELECT'ExampleTable'AS"TableName",max(c)AS"MaxSegRows",min(c)AS"MinSegRows",(max(c)-min(c))*100.0/max(c)AS"PercentageDifferenceBetweenMax&Min"FROM(SELECTcount(*)c,gp_Segment_idFROMfactsGROUPBY2)ASa;gp_tooklit

模式中有兩個(gè)視圖可以幫助檢查傾斜情況：視圖gp_toolkit.gp_skew_coefficients

通過(guò)計(jì)算每個(gè)段數(shù)據(jù)庫(kù)所存儲(chǔ)數(shù)據(jù)的變異系數(shù)（coefficientofvariation,CV）來(lái)顯示數(shù)據(jù)傾斜情況。skccoeff

字段表示變異系數(shù)，通過(guò)標(biāo)準(zhǔn)偏差除以均值計(jì)算而來(lái)。它同時(shí)考慮了數(shù)據(jù)的均值和可變性。這個(gè)值越小越好，值越高表示數(shù)據(jù)傾斜越嚴(yán)重。視圖gp_toolkit.gp_skew_idle_fractions

通過(guò)計(jì)算表掃描時(shí)系統(tǒng)空閑的百分比顯示數(shù)據(jù)分布傾斜情況，這是表示計(jì)算傾斜情況的一個(gè)指標(biāo)。siffraction

字段顯示了表掃描時(shí)處于空閑狀態(tài)的系統(tǒng)的百分比。這是數(shù)據(jù)不均勻分布或者查詢處理傾斜的一個(gè)指標(biāo)。例如，0.1表示10%傾斜，0.5表示50%傾斜，以此類推。如果傾斜超過(guò)10%，則需對(duì)其分布策略進(jìn)行評(píng)估。計(jì)算傾斜（ProceddingSkew）當(dāng)不均衡的數(shù)據(jù)流向并被某個(gè)或者少數(shù)幾個(gè)段數(shù)據(jù)庫(kù)處理時(shí)將出現(xiàn)計(jì)算傾斜。這常常是Greenplum數(shù)據(jù)庫(kù)性能和穩(wěn)定性問題的罪魁禍?zhǔn)住ｊP(guān)聯(lián)、排序、聚合和各種OLAP操作中易發(fā)生計(jì)算傾斜。計(jì)算傾斜發(fā)生在查詢執(zhí)行時(shí)，不如數(shù)據(jù)傾斜那么容易檢測(cè)，通常是由于選擇了不當(dāng)?shù)姆植兼I造成數(shù)據(jù)分布不均勻而引起的。數(shù)據(jù)傾斜體現(xiàn)在表級(jí)別，所以容易檢測(cè)，并通過(guò)選擇更好的分布鍵避免。如果單個(gè)段數(shù)據(jù)庫(kù)失?。ú皇悄硞€(gè)節(jié)點(diǎn)上的所有段實(shí)例），那么可能是計(jì)算傾斜造成的。識(shí)別計(jì)算傾斜目前主要靠手動(dòng)。首先查看臨時(shí)溢出文件，如果有計(jì)算傾斜，但是沒有造成臨時(shí)溢出文件，則不會(huì)影響性能。下面是檢查的步驟和所用的命令：1.找到懷疑發(fā)生計(jì)算傾斜的數(shù)據(jù)庫(kù)的OID：SELECToid,datnameFROMpg_database;例子輸出:oid|datname+17088|gpadmin10899|postgres1|template110898|template038817|pws39682|gpperfmon(6rows)2.使用gpssh檢查所有Segments上的溢出文件大小。使用上面結(jié)果中的OID替換:[gpadmin@mdw

kend]$gpssh-f~/hosts-e\"du-b/data[1-2]/primary/gpseg*/base/<OID>/pgsql_tmp/*"|\grep-v"du-b"|sort|\awk-F""'{arr[$1]=arr[$1]+$2;tot=tot+

$2};\END{for(iinarr)print"Segmentnode"i,arr,\"bytes("arr/(1024**3)"GB)";\print"Total",tot,"bytes("tot/(1024**3)"GB)"}'-例子輸出:Segmentnode[sdw1]2443370457bytes(2.27557GB)Segmentnode[sdw2]1766575328bytes(1.64525GB)Segmentnode[sdw3]1761686551bytes(1.6407GB)Segmentnode[sdw4]1780301617bytes(1.65804GB)Segmentnode[sdw5]1742543599bytes(1.62287GB)Segmentnode[sdw6]1830073754bytes(1.70439GB)Segmentnode[sdw7]1767310099bytes(1.64594GB)Segmentnode[sdw8]1765105802bytes(1.64388GB)Totaytes(13.8366GB)如果不同段數(shù)據(jù)庫(kù)的磁盤使用量持續(xù)差別巨大，那么需要一進(jìn)步查看當(dāng)前執(zhí)行的查詢是否發(fā)生了計(jì)算傾斜（上面的例子可能不太恰當(dāng)，因?yàn)闆]有顯示出明顯的傾斜）。在很多監(jiān)控系統(tǒng)中，總是會(huì)發(fā)生某種程度的傾斜，如果僅是臨時(shí)性的，則不必深究。3.如果發(fā)生了嚴(yán)重的持久性傾斜，接下來(lái)的任務(wù)是找到有問題的查詢。上一步命令計(jì)算的是整個(gè)節(jié)點(diǎn)的磁盤使用量。現(xiàn)在我們要找到對(duì)應(yīng)的段數(shù)據(jù)庫(kù)(Segment)目錄?？梢詮闹鞴?jié)點(diǎn)（Master）上，也可以登錄到上一步識(shí)別出的Segment上做本操作。下面例子演示從Master執(zhí)行操作。本例找的是排序生成的臨時(shí)文件。然而并不是所有情況都是由排序引起的，需要具體問題具體分析：[gpadmin@mdw

kend]$gpssh-f~/hosts-e\"ls-l/data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*"|grep-isort|sort下面是例子輸出：

[sdw1]-rw1gpadmingpadmin1002209280Jul2912:48/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19791_0001.0[sdw1]-rw1gpadmingpadmin1003356160Jul2912:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19789_0001.0[sdw1]-rw1gpadmingpadmin288718848Jul2314:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17758_0001.0[sdw1]-rw1gpadmingpadmin291176448Jul2314:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17764_0001.0[sdw1]-rw1gpadmingpadmin988446720Jul2912:48/data1/primary/gpseg0/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19787_0001.0[sdw1]-rw1gpadmingpadmin995033088Jul2912:48/data2/primary/gpseg3/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19793_0001.0[sdw1]-rw1gpadmingpadmin997097472Jul2912:48/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19797_0001.0[sdw1]-rw1gpadmingpadmin997392384Jul2912:48/data2/primary/gpseg4/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19795_0001.0[sdw2]-rw1gpadmingpadmin1002340352Jul2912:48/data2/primary/gpseg11/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3973_0001.0[sdw2]-rw1gpadmingpadmin1004339200Jul2912:48/data1/primary/gpseg8/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3967_0001.0[sdw2]-rw1gpadmingpadmin989036544Jul2912:48/data2/primary/gpseg10/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3971_0001.0[sdw2]-rw1gpadmingpadmin993722368Jul2912:48/data1/primary/gpseg6/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3963_0001.0[sdw2]-rw1gpadmingpadmin998277120Jul2912:48/data1/primary/gpseg7/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3965_0001.0[sdw2]-rw1gpadmingpadmin999751680Jul2912:48/data2/primary/gpseg9/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3969_0001.0[sdw3]-rw1gpadmingpadmin1000112128Jul2912:48/data1/primary/gpseg13/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24723_0001.0[sdw3]-rw1gpadmingpadmin1004797952Jul2912:48/data2/primary/gpseg17/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24731_0001.0[sdw3]-rw1gpadmingpadmin1004994560Jul2912:48/data2/primary/gpseg15/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24727_0001.0[sdw3]-rw1gpadmingpadmin1006108672Jul2912:48/data1/primary/gpseg14/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24725_0001.0[sdw3]-rw1gpadmingpadmin998244352Jul2912:48/data1/primary/gpseg12/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24721_0001.0[sdw3]-rw1gpadmingpadmin998440960Jul2912:48/data2/primary/gpseg16/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24729_0001.0[sdw4]-rw1gpadmingpadmin1001029632Jul2912:48/data2/primary/gpseg23/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29435_0001.0[sdw4]-rw1gpadmingpadmin1002504192Jul2912:48/data1/primary/gpseg20/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29429_0001.0[sdw4]-rw1gpadmingpadmin1002504192Jul2912:48/data2/primary/gpseg21/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29431_0001.0[sdw4]-rw1gpadmingpadmin1009451008Jul2912:48/data1/primary/gpseg19/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29427_0001.0[sdw4]-rw1gpadmingpadmin980582400Jul2912:48/data1/primary/gpseg18/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29425_0001.0[sdw4]-rw1gpadmingpadmin993230848Jul2912:48/data2/primary/gpseg22/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29433_0001.0[sdw5]-rw1gpadmingpadmin1000898560Jul2912:48/data2/primary/gpseg28/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28641_0001.0[sdw5]-rw1gpadmingpadmin1003388928Jul2912:48/data2/primary/gpseg29/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28643_0001.0[sdw5]-rw1gpadmingpadmin1008566272Jul2912:48/data1/primary/gpseg24/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28633_0001.0[sdw5]-rw1gpadmingpadmin987332608Jul2912:48/data1/primary/gpseg25/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28635_0001.0[sdw5]-rw1gpadmingpadmin990543872Jul2912:48/data2/primary/gpseg27/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28639_0001.0[sdw5]-rw1gpadmingpadmin999620608Jul2912:48/data1/primary/gpseg26/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28637_0001.0[sdw6]-rw1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg33/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29598_0001.0[sdw6]-rw1gpadmingpadmin1003683840Jul2912:48/data1/primary/gpseg31/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29594_0001.0[sdw6]-rw1gpadmingpadmin1004732416Jul2912:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29600_0001.0[sdw6]-rw1gpadmingpadmin986447872Jul2912:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29602_0001.0[sdw6]-rw1gpadmingpadmin990543872Jul2912:48/data1/primary/gpseg30/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29592_0001.0[sdw6]-rw1gpadmingpadmin992870400Jul2912:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29596_0001.0[sdw7]-rw1gpadmingpadmin1007321088Jul2912:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18530_0001.0[sdw7]-rw1gpadmingpadmin1011187712Jul2912:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18526_0001.0[sdw7]-rw1gpadmingpadmin987332608Jul2912:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18534_0001.0[sdw7]-rw1gpadmingpadmin994344960Jul2912:48/data1/primary/gpseg38/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18528_0001.0[sdw7]-rw1gpadmingpadmin996114432Jul2912:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18532_0001.0[sdw7]-rw1gpadmingpadmin999194624Jul2912:48/data1/primary/gpseg36/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18524_0001.0[sdw8]-rw1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15675_0001.0[sdw8]-rw1gpadmingpadmin1003520000Jul2912:48/data1/primary/gpseg43/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15669_0001.0[sdw8]-rw1gpadmingpadmin1008009216Jul2912:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15671_0001.0[sdw8]-rw1gpadmingpadmin1073741824Jul2912:16/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0001.0[sdw8]-rw1gpadmingpadmin1073741824Jul2912:21/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1[sdw8]-rw1gpadmingpadmin1073741824Jul2912:24/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0003.2[sdw8]-rw1gpadmingpadmin1073741824Jul2912:26/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0004.3[sdw8]-rw1gpadmingpadmin1073741824Jul2912:31/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0006.5[sdw8]-rw1gpadmingpadmin1073741824Jul2912:32/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0005.4[sdw8]-rw1gpadmingpadmin1073741824Jul2912:34/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0007.6[sdw8]-rw1gpadmingpadmin1073741824Jul2912:36/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0008.7[sdw8]-rw1gpadmingpadmin1073741824Jul2912:43/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0009.8[sdw8]-rw1gpadmingpadmin924581888Jul2912:48/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0010.9[sdw8]-rw1gpadmingpadmin990085120Jul2912:48/data1/primary/gpseg42/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15667_0001.0[sdw8]-rw1gpadmingpadmin996933632Jul2912:48/data2/primary/gpseg47/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15677_0001.0從結(jié)果可以發(fā)現(xiàn)主機(jī)sdw8上的Segmentgpseg45是罪魁禍?zhǔn)住?.使用SSH登錄到有問題的節(jié)點(diǎn)，并切換為root用戶，使用lsof

找到擁有排序臨時(shí)文件的進(jìn)程PID。[root@sdw8

~]#lsof/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEpostgres15673gpadmin11uREG8,48107374182464424546751/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1這個(gè)例子中PID15673也是文件名的一部分，然而并不是所有的臨時(shí)溢出文件名都包含進(jìn)程PID。5.使用

ps

命令識(shí)別PID對(duì)應(yīng)的數(shù)據(jù)庫(kù)和連接信息。[root@sdw8

~]#ps-eaf|grep15673gpadmin15673274712812:05?00:12:59postgres:port40003,sbaskinbdw50(21813)con699238seg45cmd32slice10MPPEXECSELECTroot2962229566012:50pts/1600:00:00grep156736.最后，我們可以找到造成傾斜的查詢語(yǔ)句。到主節(jié)點(diǎn)（Master）上，根據(jù)用戶名(sbaskin)、連接信息(con699238)和命令信息(cmd32)查找pg_log下面的日志文件。找到對(duì)應(yīng)的日志行，該行應(yīng)該包含出問題的查詢語(yǔ)句。有時(shí)候cmd數(shù)字可能不一致。例如ps輸出中postgres進(jìn)程顯示的是cmd32，而日志中可能會(huì)是cmd34。如果分析的是正在運(yùn)行的查詢語(yǔ)句，則該用戶在對(duì)應(yīng)連接上運(yùn)行的最后一條語(yǔ)句就是出問題的查詢語(yǔ)句。大多數(shù)情況下解決這種問題是重寫查詢語(yǔ)句。創(chuàng)建臨時(shí)表可以避免傾斜。設(shè)置臨時(shí)表使用隨機(jī)分布，這樣會(huì)強(qiáng)制執(zhí)行兩階段聚合(two-stageaggregation)。?

分區(qū)（PARTITIONING)好的分區(qū)策略可以讓查詢只掃描需要訪問的分區(qū)，以降低掃描的數(shù)據(jù)量。在每個(gè)段數(shù)據(jù)庫(kù)上的每個(gè)分區(qū)都是一個(gè)物理文件。讀取分區(qū)表的所有分區(qū)比讀取相同數(shù)據(jù)量的非分區(qū)表需要更多時(shí)間。以下是分區(qū)最佳實(shí)踐：只為大表設(shè)置分區(qū)，不要為小表設(shè)置分區(qū)。僅在根據(jù)查詢條件可以實(shí)現(xiàn)分區(qū)裁剪時(shí)對(duì)大表使用分區(qū)。建議優(yōu)先使用范圍(Range)分區(qū)，否則使用列表(List)分區(qū)。僅當(dāng)SQL查詢包含使用不變操作符（例如=，<,<=,>=,<>）的簡(jiǎn)單直接的約束時(shí)，查詢優(yōu)化器才會(huì)執(zhí)行分區(qū)裁剪。選擇性掃描可以識(shí)別查詢中的STABLE和IMMUTABLE函數(shù)，但是不能識(shí)別VOLATILE函數(shù)。例如查詢優(yōu)化器對(duì)下面的WHERE子句date>CURRENT_DATE可以啟用分區(qū)裁剪，但是如果WHERE子句如下則不會(huì)啟用分區(qū)裁剪。time>TIMEOFDAY通過(guò)檢查查詢的EXPLAIN計(jì)劃驗(yàn)證是否執(zhí)行分區(qū)裁剪非常重要。不要使用默認(rèn)分區(qū)。默認(rèn)分區(qū)總是會(huì)被掃描，更重要的是很多情況下會(huì)導(dǎo)致溢出而造成性能不佳。切勿使用相同的字段既做分區(qū)鍵又做分布鍵避免使用多級(jí)分區(qū)。雖然支持子分區(qū)但不推薦，因?yàn)橥ǔＷ臃謪^(qū)包含數(shù)據(jù)不多甚至沒有。隨著分區(qū)或者子分區(qū)增多性能可能會(huì)提高，然而維護(hù)這些分區(qū)和子分區(qū)的代價(jià)將超過(guò)性能的提升?；谛阅?、擴(kuò)展性和可管理性，在掃描性能和分區(qū)總數(shù)間取得平衡。對(duì)于列存儲(chǔ)的表，慎用過(guò)多的分區(qū)?？紤]好并發(fā)量和所有并發(fā)查詢打開和掃描的分區(qū)均值。分區(qū)數(shù)目和列存儲(chǔ)文件Greenplum數(shù)據(jù)庫(kù)對(duì)于文件數(shù)目的唯一硬性限制是操作系統(tǒng)的打開文件限制。然而也需要考慮到集群的文件總數(shù)、每個(gè)段數(shù)據(jù)庫(kù)(Segment)上的文件數(shù)和每個(gè)主機(jī)上的文件總數(shù)。在MPP無(wú)共享環(huán)境中，節(jié)點(diǎn)獨(dú)立運(yùn)行。每個(gè)節(jié)點(diǎn)受其磁盤、CPU和內(nèi)存的約束。Greenplum數(shù)據(jù)庫(kù)中CPU和I/O較少成為瓶頸，而內(nèi)存卻比較常見，因?yàn)椴樵儓?zhí)行器需要使用內(nèi)存優(yōu)化查詢的性能。Segment的最佳文件數(shù)與每個(gè)主機(jī)節(jié)點(diǎn)上Segment個(gè)數(shù)、集群大小、SQL訪問模式、并發(fā)度、負(fù)載和傾斜等都有關(guān)系。通常一個(gè)主機(jī)上配置六到八個(gè)Segments，對(duì)于大集群建議為每個(gè)主機(jī)配置更少的Segment。使用分區(qū)和列存儲(chǔ)時(shí)平衡集群中的文件總數(shù)很重要，但是更重要的是考慮好每個(gè)Segment的文件數(shù)和每個(gè)主機(jī)上的文件數(shù)。例如EMCDCAV2每個(gè)節(jié)點(diǎn)64GB內(nèi)存：節(jié)點(diǎn)數(shù)：16每個(gè)節(jié)點(diǎn)Segment數(shù)：8每個(gè)Segment的文件均數(shù)：10000一個(gè)節(jié)點(diǎn)的文件總數(shù)是：8*10000=80000，集群的文件總數(shù)是：8*16*10000=1280000.隨著分區(qū)增加和列字段的增加，文件數(shù)目增長(zhǎng)很快。做為一個(gè)最佳實(shí)踐，單個(gè)節(jié)點(diǎn)的文件總數(shù)上限為100000。如前面例子所示，Segment的最佳文件數(shù)和節(jié)點(diǎn)的文件總數(shù)和節(jié)點(diǎn)的硬件配置（主要是內(nèi)存）、集群大小、SQL訪問、并發(fā)度、負(fù)載和數(shù)據(jù)傾斜等相關(guān)。?

索引Greenplum數(shù)據(jù)庫(kù)通常不用索引，因?yàn)榇蠖鄶?shù)的分析型查詢都需要處理大量數(shù)據(jù)，而順序掃描時(shí)數(shù)據(jù)讀取效率較高，因?yàn)槊總€(gè)段數(shù)據(jù)庫(kù)(Segment)含有數(shù)量相當(dāng)?shù)臄?shù)據(jù)，且所有Segment并行讀取數(shù)據(jù)。對(duì)于具有高選擇性的查詢，索引可以提高查詢性能。即使明確需要索引，也不要索引經(jīng)常更新的字段。對(duì)頻繁更新的字段建立索引會(huì)增加數(shù)據(jù)更新時(shí)寫操作的代價(jià)。僅當(dāng)表達(dá)式常在查詢中使用時(shí)才建立基于表達(dá)式的索引。謂詞索引會(huì)創(chuàng)建局部索引，可用于從大表中選擇少量行的情況。避免重復(fù)索引。具有相同前綴字段的索引是冗余的。對(duì)于壓縮AO表，索引可以提高那些指返回少量匹配行的查詢的性能。對(duì)于壓縮數(shù)據(jù)，索引可以降低需要解壓縮的頁(yè)面數(shù)。創(chuàng)建選擇性高的B樹索引。索引選擇性是指：表的索引字段的不同值總數(shù)除以總行數(shù)。例如，如果一個(gè)表有1000行，索引列具有800個(gè)不同的值，那么該索引的選擇性為0.8，這是一個(gè)良好的選擇性值。如果創(chuàng)建索引后查詢性能沒有顯著地提升，則刪除該索引。確保創(chuàng)建的每個(gè)索引都被優(yōu)化器采用。加載數(shù)據(jù)前務(wù)必刪除索引。加載速度比帶索引快一個(gè)數(shù)量級(jí)。加載完成后，重建索引。位圖索引適合查詢而不適合更新業(yè)務(wù)。當(dāng)列的基數(shù)較低（譬如100到100000個(gè)不同值）時(shí)位圖索引性能最好。不要對(duì)唯一列、基數(shù)很高的列或者基數(shù)很低的列建立位圖索引。不要為業(yè)務(wù)性負(fù)載使用位圖索引。一般來(lái)說(shuō)，不要索引分區(qū)表。如果需要，索引字段不要和分區(qū)字段相同。分區(qū)表索引的一個(gè)優(yōu)勢(shì)在于：隨著B樹的增大，B樹的性能呈指數(shù)下降，因而分區(qū)表上創(chuàng)建的索引對(duì)應(yīng)的B樹比較小，性能比非分區(qū)表好。?

字段順序和字節(jié)對(duì)齊為了獲得最佳性能，建議對(duì)表的字段順序進(jìn)行調(diào)整以實(shí)現(xiàn)數(shù)據(jù)類型的字節(jié)對(duì)齊。對(duì)堆表使用下面的順序：分布鍵和分區(qū)鍵固定長(zhǎng)度的數(shù)值類型可變長(zhǎng)度的數(shù)據(jù)類型從大到小布局?jǐn)?shù)據(jù)類型，BIGINT和TIMESTAMP在INT和DATE類型之前，TEXT，VARCHAR和NUMERIC(x,y)位于后面。例如首先定義8字節(jié)的類型（BIGINT，TIMESTAMP）字段，然后是4字節(jié)類型（INT，DATE），隨后是2字節(jié)類型（SMALLINT），最后是可變長(zhǎng)度數(shù)據(jù)類型（VARCHAR）。如果你的字段定義如下：Int,Bigint,Timestamp,Bigint,Timestamp,Int(分布鍵),Date(分區(qū)鍵),Bigint,Smallint則建議調(diào)整為：Int(分布鍵),Date(分區(qū)鍵),Bigint,Bigint,Bigint,Timestamp,Timestamp,Int,Smallint第四章內(nèi)存和負(fù)載管理內(nèi)存管理對(duì)GPDB集群性能有顯著影響。默認(rèn)設(shè)置可以滿足大多數(shù)環(huán)境需求。不要修改默認(rèn)設(shè)置，除非你理解系統(tǒng)的內(nèi)存特性和使用情況。如果精心設(shè)計(jì)內(nèi)存管理，大多數(shù)內(nèi)存溢出問題可以避免。下面是GPDB內(nèi)存溢出的常見原因：集群的系統(tǒng)內(nèi)存不足內(nèi)存參數(shù)設(shè)置不當(dāng)段數(shù)據(jù)庫(kù)(Segment)級(jí)別的數(shù)據(jù)傾斜查詢級(jí)別的計(jì)算傾斜有時(shí)不僅可以通過(guò)增加系統(tǒng)內(nèi)存解決問題，還可以通過(guò)正確的配置內(nèi)存和設(shè)置恰當(dāng)?shù)馁Y源隊(duì)列管理負(fù)載，以避免很多內(nèi)存溢出問題。建議使用如下參數(shù)來(lái)配置操作系統(tǒng)和數(shù)據(jù)庫(kù)的內(nèi)存：vm.overcommit_memory這是/etc/sysctl.conf中設(shè)置的一個(gè)Linux內(nèi)核參數(shù)?？偸窃O(shè)置其值為2。它控制操作系統(tǒng)使用什么方法確定分配給進(jìn)程的內(nèi)存總數(shù)。對(duì)于Greenplum數(shù)據(jù)庫(kù)，唯一建議值是2。vm.overcommit_ratio這是/etc/sysctl.conf中設(shè)置的一個(gè)Linux內(nèi)核參數(shù)。它控制分配給應(yīng)用程序進(jìn)程的內(nèi)存百分比。建議使用缺省值50.不要啟用操作系統(tǒng)的大內(nèi)存頁(yè)gp_vmem_protect_limit使用

gp_vmem_protect_limit

設(shè)置段數(shù)據(jù)庫(kù)(Segment)能為所有任務(wù)分配的最大內(nèi)存。切勿設(shè)置此值超過(guò)系統(tǒng)物理內(nèi)存。如果

gp_vmem_protect_limit

太大，可能造成系統(tǒng)內(nèi)存不足，引起正常操作失敗，進(jìn)而造成段數(shù)據(jù)庫(kù)故障。如果gp_vmem_protect_limit設(shè)置為較低的安全值，可以防止系統(tǒng)內(nèi)存真正耗盡；打到內(nèi)存上限的查詢可能失敗，但是避免了系統(tǒng)中斷和Segment故障，這是所期望的行為。

gp_vmem_protect_limit

的計(jì)算公式為：(SWAP+(RAM*vm.overcommit_ratio))*.9/number_Segments_per_serverrunaway_detector_activation_percentGreenplum數(shù)據(jù)庫(kù)4.3.4引入了失控查詢終止（RunawayQueryTermination）機(jī)制避免內(nèi)存溢出。系統(tǒng)參數(shù)runaway_detector_activation_percent控制內(nèi)存使用達(dá)到

gp_vmem_protect_limit的多少百分比時(shí)會(huì)終止查詢，默認(rèn)值是90%。如果某個(gè)Segment使用的內(nèi)存超過(guò)了gp_vmem_protect_limit的90%（或者其他設(shè)置的值），Greenplum數(shù)據(jù)庫(kù)會(huì)根據(jù)內(nèi)存使用情況終止那些消耗內(nèi)存最多的SQL查詢，直到低于期望的閾值。statement_mem使用

statement_mem

控制Segment數(shù)據(jù)庫(kù)分配給單個(gè)查詢的內(nèi)存。如果需要更多內(nèi)存完成操作，則會(huì)溢出到磁盤（溢出文件，spillfiles）。statement_mem

的計(jì)算公式為：(vmprotect*.9)/max_expected_concurrent_queriesstatement_mem

的默認(rèn)值是125MB。例如使用這個(gè)默認(rèn)值，EMCDCAV2的一個(gè)查詢?cè)诿總€(gè)Segment服務(wù)器上需要1GB內(nèi)存（8Segments*125MB）。對(duì)于需要更多內(nèi)存才能執(zhí)行的查詢，可以設(shè)置回話級(jí)別的

statement_mem。對(duì)于并發(fā)度比較低的集群，這個(gè)設(shè)置可以較好的管理查詢內(nèi)存使用量。并發(fā)度高的集群也可以使用資源隊(duì)列對(duì)系統(tǒng)運(yùn)行什么任務(wù)和怎么運(yùn)行提供額外的控制。gp_workgp_work

限制一個(gè)查詢可用的臨時(shí)溢出文件數(shù)。當(dāng)查詢需要比分配給它的內(nèi)存更多的內(nèi)存時(shí)將創(chuàng)建溢出文件。當(dāng)溢出文件超出限額時(shí)查詢被終止。默認(rèn)值是0，表示溢出文件數(shù)目沒有限制，可能會(huì)用光文件系統(tǒng)空間。gp_work如果有大量溢出文件，則設(shè)置gp_work對(duì)溢出文件壓縮。壓縮溢出文件也有助于避免磁盤子系統(tǒng)I/O操作超載。?

配置資源隊(duì)列Greenplum數(shù)據(jù)庫(kù)的資源隊(duì)列提供了強(qiáng)大的機(jī)制來(lái)管理集群的負(fù)載。隊(duì)列可以限制同時(shí)運(yùn)行的查詢的數(shù)量和內(nèi)存使用量。當(dāng)Greenplum數(shù)據(jù)庫(kù)收到查詢時(shí)，將其加入到對(duì)應(yīng)的資源隊(duì)列，隊(duì)列確定是否接受該查詢以與何時(shí)執(zhí)行它。不要使用默認(rèn)的資源隊(duì)列，為所有用戶都分配資源隊(duì)列。每個(gè)登錄用戶（角色）都關(guān)聯(lián)到一個(gè)資源隊(duì)列；用戶提交的所有查詢都由相關(guān)的資源隊(duì)列處理。如果沒有明確關(guān)聯(lián)到某個(gè)隊(duì)列，則使用默認(rèn)的隊(duì)列

pg_default。避免使用gpadmin角色或其他超級(jí)用戶角色運(yùn)行查詢超級(jí)用戶不受資源隊(duì)列的限制，因?yàn)槌?jí)用戶提交的查詢始終運(yùn)行，完全無(wú)視相關(guān)聯(lián)的資源隊(duì)列的限制。使用資源隊(duì)列參數(shù)ACTIVE_STATEMENTS限制某個(gè)隊(duì)列的成員可以同時(shí)運(yùn)行的查詢的數(shù)量。使用MEMORY_LIMIT參數(shù)控制隊(duì)列中當(dāng)前運(yùn)行查詢的可用內(nèi)存總量。聯(lián)合使用ACTIVE_STATEMENTS和MEMORY_LIMIT屬性可以完全控制資源隊(duì)列的活動(dòng)。隊(duì)列工作機(jī)制