?介紹

本文介紹PivotalGreenplumDatabase數(shù)據(jù)庫（以下簡稱：Greenplum

數(shù)據(jù)庫，或GPDB）的最佳實(shí)踐。

最佳實(shí)踐是指能持續(xù)產(chǎn)生比其他方法更好結(jié)果的方法或者技術(shù)，它來自于

實(shí)戰(zhàn)閱歷，并被證明了遵循這些方法可以獲得牢靠的預(yù)期結(jié)果。本最佳實(shí)

踐旨在通過利用全部可能的學(xué)問和技術(shù)為正確運(yùn)用GPDB供應(yīng)有效參考。

本文不是在教您如何運(yùn)用Grccnplum數(shù)據(jù)庫的功能，而是幫助您在設(shè)計、

實(shí)現(xiàn)和運(yùn)用Greenplum數(shù)據(jù)庫時了解須要遵循哪些最佳實(shí)踐。關(guān)于如何

運(yùn)用和實(shí)現(xiàn)具體的Greenplum數(shù)據(jù)庫特性，請參考上的Greenplum

數(shù)據(jù)庫幫助文檔以與上的Sandbox和實(shí)踐指南。

本文H的不是要涵蓋整個產(chǎn)品或者產(chǎn)品特性，而是概述GPDB實(shí)踐中最

重要的因素。本文不涉與依靠于GPDB具體特性的邊緣用例，后者須要

精通數(shù)據(jù)庫特性和您的環(huán)境，包括SQL訪問、查詢執(zhí)行、并發(fā)、負(fù)載和

其他因素。

通過駕馭這些最佳實(shí)踐學(xué)問，會增加GPDB集群在維護(hù)、支持、性能和

可擴(kuò)展性等方面的勝利率。

第一章最佳實(shí)踐概述

本部分概述了Greenplum數(shù)據(jù)庫最佳實(shí)踐所涉與的概念與要點(diǎn)。

數(shù)據(jù)模型

GPDB是一個基于大規(guī)模并行處理(MPP)和無共享架構(gòu)的分析型數(shù)據(jù)庫。

這種數(shù)據(jù)庫的數(shù)據(jù)模式與高度規(guī)范化的事務(wù)性SMP數(shù)據(jù)庫顯著不同。通

過運(yùn)用非規(guī)范化數(shù)據(jù)庫模式，例如具有大事實(shí)表和小維度表的星型或者雪

花模式，GPDB在處理MPP分析型業(yè)務(wù)時表現(xiàn)優(yōu)異。

跨表關(guān)聯(lián)(JOIN)時字段運(yùn)用相同的數(shù)據(jù)類型。

詳見數(shù)據(jù)庫模式設(shè)計(后續(xù)章節(jié))

堆存儲和追加優(yōu)化存儲(Append-Optimized,下稱AO)

若表和分區(qū)表須要進(jìn)行迭代式的批處理或者頻繁執(zhí)行單個UPDATE、

DELETE或INSERT操作，運(yùn)用堆存儲。

若表和分區(qū)表須要并發(fā)執(zhí)行UPDATE、DELETE或INSERT操作，運(yùn)用

堆存儲。

若表和分區(qū)表在數(shù)據(jù)初始加載后更新不頻繁，且僅以批處理方式插入數(shù)據(jù),

則運(yùn)用AO存儲。

不要又寸AO表執(zhí)行單個INSERT、UPDATE或DELETE操作。

不要對AO表執(zhí)行并發(fā)批量UPDATE或DELETE操作，但可以并發(fā)執(zhí)行

批量INSERT操作。

詳見堆存儲和AO存儲（后續(xù)章忖

行存儲和列存儲

若數(shù)據(jù)須要常常更新或者插入，則運(yùn)用行存儲。

若須要同時訪問一個表的許多字段，則運(yùn)用行存儲。

對于通用或者混合型業(yè)務(wù)，建議運(yùn)用行存儲。

若查詢訪問的字段數(shù)目較少，或者僅在少量字段上進(jìn)行聚合操作，則運(yùn)用

列存儲。

若僅常常修改表的某一字段而不修改其他字段，則運(yùn)用列存儲。

詳見行存儲和列存儲（后續(xù)章節(jié)）

壓縮

對于大AO表和分區(qū)表運(yùn)用壓縮，以提高系統(tǒng)I/O。

在字段級別配置壓縮。

考慮壓縮比和壓縮性能之間的平衡。

詳見壓縮（后續(xù)章節(jié)）

分布

為全部表定義分布策略：要么定義分布鍵，要么運(yùn)用隨機(jī)分布。不要運(yùn)用

缺省分布方式。

優(yōu)先選擇可勻稱分布數(shù)據(jù)的單個字段做分布鍵。

不要選擇常常用于WHERE子句的字段做分布鍵。

不要運(yùn)用日期或時間字段做分布鍵。

分布鍵和分區(qū)鍵不要運(yùn)用同一字段。

對常常執(zhí)行JOIN操作的大表，優(yōu)先考慮運(yùn)用關(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)的頁設(shè)置過大的值

運(yùn)用gp_vmem_protectjimit設(shè)置單個節(jié)'點(diǎn)數(shù)據(jù)庫(Segment

Database)可以為全部查詢安排的最大內(nèi)存量。

不要設(shè)置過高的gp_vmem_protect_limit<,也不要大于系統(tǒng)的物理內(nèi)

存。

gp_vmem_protect_limit的建議值計算公式為：(SWAP+(RAM*

vm.overcommit_ratio))*0.9/number_Segments_per_server

運(yùn)用statement.mem限制節(jié)點(diǎn)數(shù)據(jù)庫為單個查詢安排的內(nèi)存量。

運(yùn)用資源隊列設(shè)置隊列允許的當(dāng)前最大查詢數(shù)(ACTIVE_STATEMENTS)

和允許運(yùn)用的內(nèi)存大小(MEMORY_LIMIT)。

不要運(yùn)用默認(rèn)的資源隊列，為全部用戶都安排資源隊列。

依據(jù)負(fù)載和時間段，設(shè)置和隊列實(shí)際需求相匹配的優(yōu)先級(PRIORITY)o

保證資源隊列的內(nèi)存配額不超過gp_vmem_protect_limito

動態(tài)更新資源隊列配置以適應(yīng)日常工作須要。

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

分區(qū)

只為大表設(shè)置分區(qū)，不要為小表設(shè)置分區(qū)。

僅在依據(jù)查詢條件可以實(shí)現(xiàn)分區(qū)裁剪時運(yùn)用分區(qū)表。

建議優(yōu)先運(yùn)用范圍(Range)分區(qū)，否則運(yùn)用列表(List)分區(qū)。

依據(jù)查詢特點(diǎn)合理設(shè)置分區(qū)。

不要運(yùn)用相同的字段即做分區(qū)鍵又做分布鍵。

不要運(yùn)用默認(rèn)分區(qū)。

避開運(yùn)用多級分區(qū)；盡量創(chuàng)建少量的分區(qū)，每個分區(qū)的數(shù)據(jù)更多些。

通過查詢安排的EXPLAIN結(jié)果來驗(yàn)證查詢對分區(qū)表執(zhí)行的是選擇性掃

描(分區(qū)裁剪)。

對于列存儲的表，不要創(chuàng)建過多的分區(qū)，否則會造成物理文件過多：

Physicalfiles=Segments*Columns*Partitionso

詳見分區(qū)(后續(xù)章節(jié))

索引

一般來說GPDB中索引不是必需的。

對于高基數(shù)的列存儲表，假如須要遍歷且查詢選擇性較高，則創(chuàng)建單列索

引。

頻繁更新的列不要建立索弓I。

在加載大量數(shù)據(jù)之前刪除索引，加載結(jié)束后再重新創(chuàng)建索弓I。

優(yōu)先運(yùn)用B樹索引。

不要為須要頻繁更新的字段創(chuàng)建位圖索引。

不要為唯一性字段，基數(shù)特別高或者特別低的字段創(chuàng)建位圖索引。

不要為事務(wù)性負(fù)載創(chuàng)建位圖索引。

一般來說不要索引分區(qū)表。假如須要建立索引，則選擇與分區(qū)鍵不同的字

段。

詳見索引（后續(xù)章節(jié)）

資源隊列

運(yùn)用資源隊列管理集群的負(fù)載。

為全部角色定義適當(dāng)?shù)馁Y源隊列。

運(yùn)用ACTIVE_STATEMENTS參數(shù)限制隊列成員可以并發(fā)運(yùn)行的查詢

總數(shù)。

運(yùn)用MEMORY.LIMIT參數(shù)限制隊列中查詢可以運(yùn)用的內(nèi)存總量。

不要設(shè)置全部隊列為MEDIUM,這樣起不到管理負(fù)載的作用。

依據(jù)負(fù)載和時間段動態(tài)調(diào)整資源隊列。

詳見配置資源隊列（后續(xù)章節(jié)）

監(jiān)控和維護(hù)

依據(jù)《Greenplum數(shù)據(jù)庫管理員指南》實(shí)現(xiàn)該書舉薦的監(jiān)控和管理任務(wù)。

安裝Greenplum數(shù)據(jù)庫前建議運(yùn)行g(shù)pcheckperf,安裝后定期運(yùn)行，保

存輸出結(jié)果，隨著時間推移對系統(tǒng)性能進(jìn)行比較。

運(yùn)用全部您可用的工具，以了解系統(tǒng)不同負(fù)載下的表現(xiàn)。

檢查任何不尋常的事務(wù)并確定緣由。

通過定期運(yùn)行說明安排監(jiān)控系統(tǒng)查詢活動，以確保查詢處于最佳運(yùn)行狀態(tài)。

檢查查詢安排，以確定是否按預(yù)期運(yùn)用了索引和進(jìn)行了分區(qū)裁剪。

了解系統(tǒng)日志文件的位置和內(nèi)容，定期監(jiān)控日志文件，而不是在出現(xiàn)問題

時才查看。

詳見系統(tǒng)監(jiān)控和維護(hù)以與監(jiān)控GPDB日志文件。（后續(xù)章節(jié)）

ANALYZE

不要對整個數(shù)據(jù)庫運(yùn)行ANALYZE,只對須要的表運(yùn)行該吩咐。

建議數(shù)據(jù)加載后即刻運(yùn)行ANALYZEo

假如INSERT、UPDATE和DELETE等操作修改大量數(shù)據(jù)，建議運(yùn)行

ANALYZEo

執(zhí)彳亍CREATEINDEX操作后建議運(yùn)彳亍ANALYZE。

假如對大表ANALYZE耗時很久，則只對JOIN字段、WHERE、SORT、

GROUPBY或HAVING字句的字段運(yùn)行ANALYZE。

詳見運(yùn)用ANALYZE更新統(tǒng)計信息。（后續(xù)章節(jié)）

Vaccum

批量UPDATE和DELETE操作后建議執(zhí)行VACUUM。

不建議運(yùn)用VACUUMFULL。建議運(yùn)用CTAS（CREATETABLE...AS）

操作，然后重命名表名，并刪除原來的表。

對系統(tǒng)表定期運(yùn)行VACUUM,以避開系統(tǒng)表臃腫和在系統(tǒng)表上執(zhí)行

VACUUMFULL操作。

禁止殺死系統(tǒng)表的VACUUM任務(wù)。

不建議運(yùn)用VACUUMANALYZEo

詳見消退系統(tǒng)表臃腫。（后續(xù)章節(jié)）

加載

運(yùn)用gpfdist進(jìn)行數(shù)據(jù)的加載和導(dǎo)出。

隨著段數(shù)據(jù)庫個數(shù)的增加，并行性增加。

盡量將數(shù)據(jù)勻稱地分布到多個ETL節(jié)點(diǎn)上。

將特別大的數(shù)據(jù)文件切分成相同大小的塊，并放在盡量多的文件系統(tǒng)上。

一個文件系統(tǒng)運(yùn)行兩個gpfdist實(shí)例。

在盡可能多的網(wǎng)絡(luò)接口上運(yùn)行g(shù)pfdsito

運(yùn)用gp_external_max_segs限制訪問每個gpfdist服務(wù)器的段數(shù)據(jù)庫

的個數(shù)。

建議gp_external_max_segs的值和gpfdist進(jìn)程個數(shù)為偶數(shù)。

數(shù)據(jù)加載前刪除索引；加載完后重建索引。

數(shù)據(jù)加載完成后運(yùn)行ANALYZE操作。

數(shù)據(jù)加載過程中，設(shè)置gp_autostats_mode為NONE,取消統(tǒng)計信息

的自動收集。

若數(shù)據(jù)加載失敗，運(yùn)用VACUUM回收空間。

詳見加載數(shù)據(jù)。（后續(xù)章節(jié)）

gptransfer

為了更好的性能，建議運(yùn)用gptransfer遷移數(shù)據(jù)到相同大小或者更大的

集群。

避開運(yùn)用一色11或者-schema-only選項。建議運(yùn)用其他方法拷貝數(shù)據(jù)

庫模式到目標(biāo)數(shù)據(jù)庫，然后遷移數(shù)據(jù)。

遷移數(shù)據(jù)前刪除索引，遷移完成后重建索引。

運(yùn)用SQLCOPY助咐遷移小表到目標(biāo)數(shù)據(jù)庫。

運(yùn)用gptransfer批量遷移大表。

在正式遷移生產(chǎn)環(huán)境前測試運(yùn)行g(shù)ptransfer。試

驗(yàn)一batch-size和-sub-batch-size選項以獲得最大平行度。假如須要,

迭代運(yùn)行多次gptransfer來確定每次要遷移的表的批次。

僅運(yùn)用完全限定的表名。表名字中若含有點(diǎn)、空格、單引號和雙引號，可

能會導(dǎo)致問題。

假如運(yùn)用一validation選項在遷移后驗(yàn)證數(shù)據(jù)，則須要同時運(yùn)用-x選項，

以在源表上加排它鎖。

確保在目標(biāo)數(shù)據(jù)庫上創(chuàng)建了相應(yīng)的角色、函數(shù)和資源隊列。gptransfer

-t不會遷移這些對象。

從源數(shù)據(jù)庫拷貝postgres.conf和pg_hba.conf到目標(biāo)數(shù)據(jù)庫集群。

運(yùn)用gppkg在目標(biāo)數(shù)據(jù)庫上安裝須要的擴(kuò)展。

詳見運(yùn)用gptransfer遷移數(shù)據(jù)（后續(xù)章節(jié)）

平安

妥當(dāng)愛護(hù)gpadmin賬號,只有在必要的時候才能允許系統(tǒng)管理員訪問它。

僅當(dāng)執(zhí)行系統(tǒng)維護(hù)任務(wù)（例如升級或擴(kuò)容），管理員才能以gpadmin登

錄Greenplum集群。

限制具有SUPERUSER角色屬性的用戶數(shù)。GPDB中，身為超級用戶

的角色會跳過全部訪問權(quán)限檢查和資源隊列限制。僅有系統(tǒng)管理員具有數(shù)

據(jù)庫超級用戶權(quán)限。參考《Greenplum數(shù)據(jù)庫管理員指南》中的“修改

角色屬性”。

嚴(yán)禁數(shù)據(jù)庫用戶以gpadmin身份登錄，嚴(yán)禁以gpadmin身份執(zhí)行ETL

或者生產(chǎn)任務(wù)。

為有登錄需求的每個用戶都安排一個不同的角色。

考慮為每個應(yīng)用或者網(wǎng)絡(luò)服務(wù)安排一個不同的角色。

運(yùn)用用戶組管理訪問權(quán)限。

愛護(hù)好ROOT的密碼。

對于操作系統(tǒng)密碼，強(qiáng)制運(yùn)用強(qiáng)密碼策略。

確保愛護(hù)好操作系統(tǒng)的重要文件。

詳見平安。（后續(xù)章節(jié)）

加密

加密和解密數(shù)據(jù)會影響性能，僅加密須要加密的數(shù)據(jù)。

在生產(chǎn)系統(tǒng)中實(shí)現(xiàn)任何加密解決方案之前都要做性能測試。

GPDB生產(chǎn)系統(tǒng)運(yùn)用的服務(wù)器證書應(yīng)由證書簽名頒發(fā)機(jī)構(gòu)（CA）簽名，

這樣客戶端可以驗(yàn)證服務(wù)器。假如全部客戶端都是本地的，則可以運(yùn)用本

地CA。

假如客戶端與GPDB的連接會經(jīng)過擔(dān)心全的鏈路，則運(yùn)用SSL加密。

加密和解密運(yùn)用相同密鑰的對稱加密方式比非對稱加密具有更好的性能,

假如密鑰可以平安共享，則建議運(yùn)用對稱加密方式。

運(yùn)用pgcrypto包中的函數(shù)加密磁盤上的數(shù)據(jù)。數(shù)據(jù)的加密和解密都由數(shù)

據(jù)庫進(jìn)程完成，為了避開傳輸明文數(shù)據(jù)，須要運(yùn)用SSL加密客戶端和數(shù)

據(jù)庫間的連接。

數(shù)據(jù)加載和導(dǎo)出時，運(yùn)用gpfdists協(xié)議愛護(hù)ETL數(shù)據(jù)平安。

詳見加密數(shù)據(jù)和數(shù)據(jù)庫連接。（后續(xù)章節(jié)）

高可用

運(yùn)用8到24個磁盤的硬件RAID存儲解決方案。

運(yùn)用RAID1、5或6,以使磁盤陣列可以容忍磁盤故障。

為磁盤陣列配備熱備磁盤，以便在檢測到磁盤故障時自動起先重建。

在重建時通過RAID卷鏡像防止整個磁盤陣列故障和性能下降。

定期監(jiān)控磁盤利用率，并在須要時增加額外的空間。

定期監(jiān)控段數(shù)據(jù)庫傾斜，以確保在全部段數(shù)據(jù)庫上數(shù)據(jù)勻稱分布，存儲空

間勻稱消耗。

配置備用主服務(wù)器，當(dāng)主服務(wù)器發(fā)生故障時由備用主服務(wù)器接管。

規(guī)劃好當(dāng)主服務(wù)器發(fā)生故障時如何切換客戶端連接到新的主服務(wù)器實(shí)例，

例如通過更新DNS中主服務(wù)器的地址。

建立監(jiān)控系統(tǒng)，當(dāng)主服務(wù)器發(fā)生故障時，可以通過系統(tǒng)監(jiān)控應(yīng)用或電子郵

件發(fā)送通知。

安排主段數(shù)據(jù)庫和其鏡像到不同的主機(jī)上，以防止主機(jī)故障。

建立監(jiān)控系統(tǒng)，當(dāng)主段數(shù)據(jù)庫發(fā)生故障時，可以通過系統(tǒng)監(jiān)控應(yīng)用或電子

郵件發(fā)送通知。

運(yùn)用gprecoverseg工具與時復(fù)原故障段，并使系統(tǒng)返回最佳平衡狀態(tài)。

在主服務(wù)器上配置并運(yùn)行g(shù)psnmpd以發(fā)送SNMP通知給網(wǎng)絡(luò)監(jiān)控器。

在$Master_DATA_DIRECTORY/postgresql.conf配置文件中設(shè)置郵

件通知，以便檢測到關(guān)鍵問題時，Greenplum系統(tǒng)可以通過電子郵件通

知管理員。

考慮雙集群配置，供應(yīng)額外的冗余和查詢處理實(shí)力。

除非Greenplum數(shù)據(jù)庫的數(shù)據(jù)很簡潔從數(shù)據(jù)源復(fù)原，否則定期備份。

假如堆表相對較小,或者兩次備份之間僅有少量AO或列存儲分區(qū)有變更,

則運(yùn)用增量備份。

假如備份保存在集群的本地存儲系統(tǒng)上，則備份結(jié)束后，將文件移到其他

的平安存儲系統(tǒng)上。

假如備份保存到NFS中，則建議運(yùn)用像EMCIsilon這樣的可擴(kuò)展

NFS方案以防止I/O瓶頸。

Greenplum集成了對EMC的DataDomain和Symantec的

NetBackup的支持，可以流式備份到DataDomain或NetBackup企

業(yè)備份平臺上。

詳見高可用性（后續(xù)章節(jié)）

其次章系統(tǒng)配置

本節(jié)描述了Greenplum數(shù)據(jù)庫集群關(guān)于主機(jī)配置的需求和最佳實(shí)踐。

。首選操作系統(tǒng)

紅帽企業(yè)級Linux(RHEL)是首選操作系統(tǒng)c應(yīng)運(yùn)用最新支持的主版本，

目前是RHEL6o

?文件系統(tǒng)

Greenplum數(shù)據(jù)庫的數(shù)據(jù)書目舉薦運(yùn)用XFS文件系統(tǒng)。運(yùn)用以下選項

掛載XFS：

rw,noatime,inode64,allocsize=16m

?端口配置

ip」ocal_port_range的設(shè)置不要和Greenplum數(shù)據(jù)庫的端口范圍有

沖突，例如：

net.ipv4.ip_local_port_range=3000

65535PORT_BASE=2GOOMIRROR_PORT_BASE=2100REPLICATI

ON_PORT_BASE=2200MIRROR_REPLICATION_PORT_BASE=230

0

?I/O配置

包含數(shù)據(jù)書目的設(shè)備的預(yù)讀大小應(yīng)設(shè)為16384.

/sbin/blockdev—getra/dev/sdbl6384

包含數(shù)據(jù)書目的設(shè)備的I/O調(diào)度算法設(shè)置為deadlineo

#cat/sys/block/sdb/queue/schedulernoopanticipatory

[deadline]cfq

通過/etc/security/limits.conf增大操作系統(tǒng)文件數(shù)和進(jìn)程數(shù)。

*softno*hardno*softnproc131072*hardnproc131072

啟用core文件轉(zhuǎn)儲，并保存到已知位置。確保limits.conf中允許的core

轉(zhuǎn)儲文件。

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變量會影響操

作系統(tǒng)對內(nèi)存安排的管理。這些變量應(yīng)當(dāng)設(shè)置如下：

?vm.overcommit_memory限制操作系統(tǒng)運(yùn)用什么方法確定安排給進(jìn)程

的內(nèi)存總數(shù)。對于Greenplum數(shù)據(jù)庫，唯一建議值是2.

?vm.overcommit_ratio限制安排給應(yīng)用程序進(jìn)程的內(nèi)存百分比。建議運(yùn)

用缺省值50.

不要啟用操作系統(tǒng)的大內(nèi)存頁。

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

?共享內(nèi)存設(shè)置

Greenplum數(shù)據(jù)庫中同一數(shù)據(jù)庫實(shí)例的不同postgres進(jìn)程間通訊運(yùn)用

共享內(nèi)存。運(yùn)用sysctl配置如卜共享內(nèi)存參數(shù)，且不建議修改：

kernel.shmmax=500000000kernel.shmmni=4096kernel.shmall

=4000000000

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

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

中的gpchecko

?設(shè)置一個主機(jī)上段數(shù)據(jù)庫個數(shù)

確定每個段主機(jī)上段數(shù)據(jù)庫的個數(shù)對整體性能有著巨大影響。這些段數(shù)據(jù)

庫之間共享主機(jī)的CPU核、內(nèi)存、網(wǎng)卡等，且和主機(jī)上的全部進(jìn)程共享

這些資源。過高地估計每個服務(wù)器上運(yùn)行的段數(shù)據(jù)庫個數(shù)，通常是達(dá)不到

最優(yōu)性能的常見緣由之一。

以下因素確定了一個主機(jī)上可以運(yùn)行多少個段數(shù)據(jù)庫:

?CPU核的個數(shù)

?物理內(nèi)存容量

?網(wǎng)卡個數(shù)與速度

?存儲空間

?主段數(shù)據(jù)庫和鏡像共存

?主機(jī)是否運(yùn)行ETL進(jìn)程

?主機(jī)上運(yùn)行的非Greenplum進(jìn)程

?段服務(wù)器內(nèi)存配置

服務(wù)器配置參數(shù)gp_vmem_protect_limit限制了每個段數(shù)據(jù)庫為全部

運(yùn)行的查詢安排的內(nèi)存總量。假如查詢須要的內(nèi)存超過此值，則會失敗。

運(yùn)用下面公式確定合適的值：

(swap+(RAM*vm.overcommit_ratio))*.9/

number_of_Segments_per_server

例如，具有下面配置的段服務(wù)器：

?8GB交換空間

?128GB內(nèi)存

?vm.overcommit_ratio=50

?8個段數(shù)據(jù)庫

貝ij設(shè)置gp_vmem_protect_limit為8GB:

(8+(128*.5))*.9/8=8GB

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

。SQL語句內(nèi)存配置

服務(wù)器配置參數(shù)gp_statement_mem限制段數(shù)據(jù)庫上單個查詢可以運(yùn)

用的內(nèi)存總量。假如語句須要更多內(nèi)存，則會溢出數(shù)據(jù)到磁盤。用下面公

式確定合適的值：

(gp_vmem_protect_limit*.9)/max_expected_concurrent_queries

例如，假如并發(fā)度為40,gp_vmeme_protect_limit為8GB,

則gp_statement_mem為：

(8192MB*⑼/40=184MB

每個查詢最多可以運(yùn)用184MB內(nèi)存，之后將溢出到磁盤。

若想平安的增大gp_statement_mem,要么增

大gp_vmem_protectJimit,要么降低并發(fā)。要增大

gp_vmem_protectJimit,必需增加物理內(nèi)存和/或交換空間，或者降低

單個主機(jī)上運(yùn)行的段數(shù)據(jù)庫個數(shù)。

請留意，為集群添加更多的段數(shù)據(jù)庫實(shí)例并不能解決內(nèi)存不足的問題，除

非引入更多新主機(jī)來降低了單個主機(jī)上運(yùn)行的段數(shù)據(jù)庫的個數(shù)。

了解什么是溢出文件。了解gp_work參數(shù)，其限制了單個查詢最多可以

創(chuàng)建多少個溢出文件。了解gp_work。

有關(guān)運(yùn)用資源隊列管理內(nèi)存的更多信息，請參考內(nèi)存和負(fù)載管理。（后續(xù)

章節(jié)）

。溢出文件配置

假如為SQL查詢安排的內(nèi)存不足,Greenplum數(shù)據(jù)庫會創(chuàng)建溢出文件（也

叫工作文件）。在默認(rèn)狀況下，一個SQL查詢最多可以創(chuàng)建100000個

溢出文件，這足以滿意大多數(shù)查詢。

參數(shù)gp_work確定了一個查詢最多可以創(chuàng)建多少個溢出文件。。意味著

沒有限制。限制溢出文件數(shù)據(jù)可以防止失控查詢破壞整個系統(tǒng)。

假如安排內(nèi)存不足或者出現(xiàn)數(shù)據(jù)傾斜，則一個SQL查詢可能產(chǎn)生大量溢

出文件。假如超過溢出文件上限，Greenplum數(shù)據(jù)庫報告如下錯誤：

ERROR:numberofworkfilesperquerylimitexceeded

在嘗試增大gp_work前，先嘗試通過修改SQL、數(shù)據(jù)分布策略或者內(nèi)存

配置以降低溢出文件個數(shù)。

gp-toolkit模式包括一些視圖，通過這些視圖可以看到全部運(yùn)用溢出文件

的查詢的信息。這些信息有助于故障解除和調(diào)優(yōu)查詢：

?gp_work視圖的每一行表示一個正在運(yùn)用溢出文件的操作符的信息。關(guān)于

操作符，參考如何理解查詢安排說明。（后續(xù)章節(jié)）

?gp_work視圖的每一行表示一個正在運(yùn)用溢出文件的SQL查詢的信息。

?gp_work視圖的每一行對應(yīng)一個段數(shù)據(jù)庫，包含了該段上運(yùn)用的溢出文件

占用的磁盤空間總量。

關(guān)于這些視圖的字段涵義，請參考《Greenplum數(shù)據(jù)庫參考指南》。

參數(shù)gp_work指定溢出文件的壓縮算法：none或者zlibo

第三章數(shù)據(jù)庫模式設(shè)計

GPDB是一個基于大規(guī)模并行處理（MPP）和無共享架構(gòu)的分析型數(shù)據(jù)

庫。這種數(shù)據(jù)庫的數(shù)據(jù)模式與高度規(guī)范化的事務(wù)性SMP數(shù)據(jù)庫顯著不同。

運(yùn)用非規(guī)范化數(shù)據(jù)庫模式，例如具有大事實(shí)表和小維度表的星型或者雪花

模式，處理MPP分析型業(yè)務(wù)時，Greenplum數(shù)據(jù)庫表現(xiàn)優(yōu)異。

?數(shù)據(jù)類型

類型一樣性

關(guān)聯(lián)列運(yùn)用相同的數(shù)據(jù)類型。假如不同表中的關(guān)聯(lián)列數(shù)據(jù)類型不同，

GPDB必需動態(tài)的進(jìn)行類型轉(zhuǎn)換以進(jìn)行比較，考慮到這一點(diǎn)，你可能須

要增大數(shù)據(jù)類型的大小，以便關(guān)聯(lián)操作更高效。

類型最小化

建議選擇最高效的類型存儲數(shù)據(jù)，這可以提高數(shù)據(jù)庫的有效容量與查詢執(zhí)

行性能。

建議運(yùn)用TEXT或者VARCHAR而不是CHAR。不同的字符類型間沒

有明顯的性能差別，但是TEXT或者VARCHAR可以降低空間運(yùn)用量。

建議運(yùn)用滿意需求的最小數(shù)值類型。假如INT或SAMLLINT夠用，那

么選擇BIGINT會奢侈空間。

?存儲模型

在Greenplum數(shù)據(jù)庫中，創(chuàng)建表時可以選擇不同的存儲類型。須要清

晰什么時候該運(yùn)用堆存儲、什么時候運(yùn)用追加優(yōu)化(AO)存儲、什么時候運(yùn)

用行存儲、什么時候運(yùn)用列存儲。對于大型事實(shí)表這尤為重要。相比而言，

對小的維度表就不那么重要了。

選擇合適存儲模型的常規(guī)最佳實(shí)踐為：

1.對于大型事實(shí)分區(qū)表，評估并優(yōu)化不同分區(qū)的存儲選項。一種存儲模型可

能滿意不了整個分區(qū)表的不同分區(qū)的應(yīng)用場景，例如某些分區(qū)運(yùn)用行存儲

而其他分區(qū)運(yùn)用列存儲。

2.運(yùn)用列存儲時，段數(shù)據(jù)庫內(nèi)每一列對應(yīng)一個文件。對于有大量列的表，常

常訪問的數(shù)據(jù)運(yùn)用列存儲，不常訪問的數(shù)據(jù)運(yùn)用行存儲。

3.在分區(qū)級別或者在數(shù)據(jù)存儲級別上設(shè)置存儲類型。

4.假如集群須要更多空間，或者期望提高I/O性能，考慮運(yùn)用壓縮。

堆存儲和AO存儲

堆存儲是默認(rèn)存儲模型，也是PostgreSQL存儲全部數(shù)據(jù)庫表的模型。

假如表和分區(qū)常常執(zhí)行UPDATE、DELETE操作或者單個INSERT操

作，則運(yùn)用堆存儲模型。假如須要對表和分區(qū)執(zhí)行并發(fā)UPDATE、

DELETE、INSERT操作，也運(yùn)用堆存儲模型。

假如數(shù)據(jù)加載后很少更新，之后的插入也是以批處理方式執(zhí)行，則運(yùn)用追

加優(yōu)化(AO)存儲模型。千萬不要對AO表執(zhí)行單個

INSERT/UPDATE/DELETE操作。并發(fā)批量INSERT操作是可以的,

但是不要執(zhí)行并發(fā)批量UPDATE或者DELETE操作。

AO表中執(zhí)行刪除和更新操作后行所占空間的重用效率不如堆表，所以這

種存儲類型不適合頻繁更新的表。AO表主要用于分析型業(yè)務(wù)中加載后很

少更新的大表。

行存儲和列存儲

行存儲是存儲數(shù)據(jù)庫元組的傳統(tǒng)方式。一行的全部列在磁盤上連續(xù)存儲,

所以一次I/O可以從磁盤上讀取整個行。

列存儲在磁盤上將同一列的值保存在一塊。每一列對應(yīng)一個單獨(dú)的文件。

假如表是分區(qū)表，那么每個分區(qū)的每個列對應(yīng)一個單獨(dú)的文件。假如列存

儲表有許多列，而SQL查詢只訪問其中的少量列，那么I/O開銷與行存

儲表相比大大降低，因?yàn)椴豁氁獜拇疟P上讀取不須要訪問的列。

交易型業(yè)務(wù)中更新和插入頻繁，建議運(yùn)用行存儲。假如須要同時訪問寬表

的許多字段時，建議運(yùn)用行存儲。假如大多數(shù)字段會出現(xiàn)在SELECT列

表中或者WHERE子句中，建議運(yùn)用行存儲。對于通用的混合型負(fù)載，

建議運(yùn)用行存儲。行存儲供應(yīng)了敏捷性和性能的最佳組合。

列存儲是為讀操作而非寫操作優(yōu)化的一種存儲方式，不同字段存儲在磁盤

上的不同位置。對于有許多字段的大型表，假如單個查詢只需訪問較少字

段，那么列存儲性能優(yōu)異。

列存儲的另一個好處是相同類型的數(shù)據(jù)存儲在一起比混合類型數(shù)據(jù)占用

的空間少，因而列存儲表比行存儲表運(yùn)用的磁盤空間小。列存儲的壓縮比

也高于行存儲。

數(shù)據(jù)倉庫的分析型業(yè)務(wù)中，假如SELECT訪問少量字段或者在少量字段

上執(zhí)行聚合計算，則建議運(yùn)用列存儲。假如只有單個字段須要頻繁更新而

不修改其他字段，則建議列存儲。從一個寬列存儲表中讀完整的行比從行

存儲表中讀同一行須要更多時間。特殊要留意的是，GPDB每個段數(shù)據(jù)庫

上每一列都是一個獨(dú)立的物理文件。

壓縮

Greenplum數(shù)據(jù)庫為AO表和分區(qū)供應(yīng)多種壓縮選項。運(yùn)用壓縮后，每

次磁盤讀操作可以讀入更多的數(shù)據(jù)，因而可以提高I/O性能。建議在實(shí)際

保存物理數(shù)據(jù)的那一層設(shè)置字段壓縮方式。

請留意，新添加的分區(qū)不會自動繼承父表的壓縮方式，必需在創(chuàng)建新分區(qū)

時明確指定壓縮選項。

Delta和RLE的壓縮比較高。高壓縮比運(yùn)用的磁盤空間較少，但是在寫

入數(shù)據(jù)或者讀取數(shù)據(jù)時須要額外的時間和CPU周期進(jìn)行壓縮和解壓縮。

壓縮和排序聯(lián)合運(yùn)用，可以達(dá)到最好的壓縮比。

在壓縮文件系統(tǒng)上不耍再運(yùn)用數(shù)據(jù)庫壓縮。

測試不同的壓縮類型和排序方法以確定最適合自己數(shù)據(jù)的壓縮方式。

?分布(DISTRIBUTIONS)

選擇能夠勻稱分布數(shù)據(jù)的分布鍵對Greenplum數(shù)據(jù)庫特別重要。在大

規(guī)模并行處理無共享環(huán)境中，查詢的總體響應(yīng)時間取決于全部段數(shù)據(jù)庫的

完成時間。集群的最快速度與最慢的那個段數(shù)據(jù)庫一樣。假如存在嚴(yán)峻數(shù)

據(jù)傾斜現(xiàn)象，那么數(shù)據(jù)較多的段數(shù)據(jù)庫響應(yīng)時間將更久。每個段數(shù)據(jù)庫最

好有數(shù)量接近的數(shù)據(jù)，處理時間也相像。假如一個段數(shù)據(jù)庫處理的數(shù)據(jù)顯

著比其他段多，那么性能會很差，并可能出現(xiàn)內(nèi)存溢出錯誤。

確定分布策略時考慮以下最佳實(shí)踐：

?為全部表要么明確地指明其分布字段，要么運(yùn)用隨機(jī)分布。不要運(yùn)用默認(rèn)

方式。

?志向狀況下，運(yùn)用能夠?qū)?shù)據(jù)勻稱分布到全部段數(shù)據(jù)庫上的一個字段做分

布鍵C

?不要運(yùn)用常出現(xiàn)在查詢的WHERE子句中的字段做分布鍵。

?不要運(yùn)用日期或者時間字段做分布鍵。

?分布字段的數(shù)據(jù)要么是唯一值要么基數(shù)很大。

?假如單個字段不能實(shí)現(xiàn)數(shù)據(jù)勻稱分布，則考慮運(yùn)用兩個字段做分布鍵。作

為分布鍵的字段最好不要超過兩個。GPDB運(yùn)用哈希進(jìn)行數(shù)據(jù)分布，運(yùn)用

更多的字段通常不能得到更勻稱的分布，反而耗費(fèi)更多的時間計算哈希值。

?假如兩個字段也不能實(shí)現(xiàn)數(shù)據(jù)的勻稱分布，則考慮運(yùn)用隨機(jī)分布。大多數(shù)

狀況下，假如分布鍵字段超過兩個，那么執(zhí)行表關(guān)聯(lián)時通常須要節(jié)點(diǎn)間的

數(shù)據(jù)移動操作（Motion）,如此一來和隨機(jī)分布相比，沒有明顯優(yōu)勢。

Greenplum數(shù)據(jù)庫的隨機(jī)分布不是輪詢算法，不能保證每個節(jié)點(diǎn)的記錄

數(shù)相同，但是通常差別會小于10%o

關(guān)聯(lián)大表時最優(yōu)分布至關(guān)重要。關(guān)聯(lián)操作須要匹配的記錄必需位于同一段

數(shù)據(jù)庫上。假如分布鍵和關(guān)聯(lián)字段不同，則數(shù)據(jù)須要動態(tài)重分發(fā)。某些狀

況下，廣播移動操作（Motion）比重分布移動操作效果好。

本地（Co-located）關(guān)聯(lián)

假如所用的哈希分布能勻稱分布數(shù)據(jù)，并導(dǎo)致本地關(guān)聯(lián)，那么性能會大幅

提升。本地關(guān)聯(lián)在段數(shù)據(jù)庫內(nèi)部執(zhí)行，和其他段數(shù)據(jù)庫沒有關(guān)系，避開了

網(wǎng)絡(luò)通訊開銷，避開或者降低了廣播移動操作和重分布移動操作。

為常常關(guān)聯(lián)的大表運(yùn)用相同的字段做分布鍵可實(shí)現(xiàn)本地關(guān)聯(lián)。本地關(guān)聯(lián)須

要關(guān)聯(lián)的雙方運(yùn)用相同的字段（且依次相同）做分布鍵，并且關(guān)聯(lián)時全部

的字段都被運(yùn)用。分布鍵數(shù)據(jù)類型必需相同。假如數(shù)據(jù)類型不同，磁盤上

的存儲方式可能不同，那么即使值看起來相同，哈希值也可能不一樣。

數(shù)據(jù)傾斜

數(shù)據(jù)傾斜是許多性能問題和內(nèi)存溢出問題的根本緣由。數(shù)據(jù)傾斜不僅影響

掃描/讀性能，也會影響許多其他查詢執(zhí)行操作符，例如關(guān)聯(lián)操作、分組

操作等。

數(shù)據(jù)初始加載后，驗(yàn)證并保證數(shù)據(jù)分布的勻稱性特別重要；每次增量加載

后，都要驗(yàn)證并保證數(shù)據(jù)分布的勻稱性。

下面的查詢語句統(tǒng)計每個段數(shù)據(jù)庫上的記錄的條數(shù)，并依據(jù)最大和最小行

數(shù)計算方差：

SELECT'ExampleTable'AS"TableName",max(c)AS"MaxSeg

Rows",min(c)AS"MinSegRows",(max(c)-min(c))*100.0/max(c)

AS"PercentageDifferenceBetweenMax&Min"FROM(SELECT

count(*)c,gp_Segment_idFROMfactsGROUPBY2)ASa;

gp_tooklit模式中有兩個視圖可以幫助檢查傾斜狀況：

?視圖gp_toolkit.gp_skew_coefficients通過計算每個段數(shù)據(jù)庫所存儲數(shù)

據(jù)的變異系數(shù)(coefficientofvariation,CV)來顯示數(shù)據(jù)傾斜狀況。

skccoeff字段表示變異系數(shù)，通過標(biāo)準(zhǔn)偏差除以均值計算而來。它同時考

慮了數(shù)據(jù)的均值和可變性。這個值越小越好，值越高表示數(shù)據(jù)傾斜越嚴(yán)峻。

?視圖gp_toolkit.gp_skewjdle_fractions通過計算表掃描時系統(tǒng)空閑的

百分比顯示數(shù)據(jù)分布傾斜狀況，這是表示計算傾斜狀況的一個指標(biāo)。

siffraction字段顯示了表掃描時處于空閑狀態(tài)的系統(tǒng)的百分比。這是數(shù)據(jù)

不勻稱分布或者查詢處理傾斜的一個指標(biāo)。例如，。.1表示10%傾斜,

0.5表示50%傾斜，以此類推。假如傾斜超過10%,則需對其分布策

略進(jìn)行評估。

計算傾斜(ProceddingSkew)

當(dāng)不均衡的數(shù)據(jù)流向并被某個或者少數(shù)幾個段數(shù)據(jù)庫處理時將出現(xiàn)計算

傾斜。這常常是Greenplum數(shù)據(jù)庫性能和穩(wěn)定性問題的罪魁禍?zhǔn)住ｊP(guān)聯(lián)、

排序、聚合和各種OLAP操作中易發(fā)生計算傾斜。計算傾斜發(fā)生在查詢執(zhí)

行時，不如數(shù)據(jù)傾斜那么簡潔檢測，通常是由于選擇了不當(dāng)?shù)姆植兼I造成

數(shù)據(jù)分布不勻稱而引起的。數(shù)據(jù)傾斜體現(xiàn)在表級別，所以簡潔檢測，并通

過選擇更好的分布鍵避開。

假如單個段數(shù)據(jù)庫失敗(不是某個節(jié)點(diǎn)上的全部段實(shí)例)，那么可能是計

算傾斜造成的。識別計算傾斜目前主要靠手動。首先查看臨時溢出文件，

假如有計算傾斜，但是沒有造成臨時溢出文件，則不會影響性能。下面是

檢查的步驟和所用的吩咐：

1.找到懷疑發(fā)生計算傾斜的數(shù)據(jù)庫的OID：

SELECToid,datnameFROMpg_database;

例子輸出：

oid|datname+17088|gpadmin10899|postgres

1|template110898|templateO38817|pws39682|gpperfmon

(6rows)

2.運(yùn)用gpssh檢查全部Segments上的溢出文件大小。運(yùn)用上面結(jié)果

中的OID替換：

[gpadmin@mdwkend]$gpssh-f-/hosts-e\"du-b

/data[1-2]/primary/gpseg*/base/<OID>/pgsql_tmp/*"|\grep

-v"du-b"|sort|\awk-F""'{arr[$l]=arr[$l]+$2;tot=tot

+$2);\END{for|iinarr)print"Segmentnode"i,arri,\"bytes

(“am-t/(1024**3)"GB)H;\print"Total"，tot,“bytes("

tot/(1024**3)HGB)n}，-

例子輸出：

Segmentnode[sdwl]2443370457bytes(2.27557GB)Segment

node[sdw2]1766575328bytes(1.64525GB)Segmentnode[sdw3]

1761686551bytes(1.6407GB)Segmentnode[sdw4]1780301617

bytes(1.65804GB)Segmentnode[sdw5]1742543599bytes

(1.62287GB)Segmentnode[sdw6]1830073754bytes(1.70439

GB)Segmentnode[sdw7]1767310099bytes(1.64594

GB)Segmentnode[sdw8]1

假如不同段數(shù)據(jù)庫的磁盤運(yùn)用量持續(xù)差別巨大，那么須要一進(jìn)步查看當(dāng)前

執(zhí)行的查詢是否發(fā)生了計算傾斜(上面的例子可能不太恰當(dāng)，因?yàn)闆]有顯

示出明顯的傾斜）。在許多監(jiān)控系統(tǒng)中，總是會發(fā)生某種程度的傾斜，

假如僅是臨時性的，則不必深究。

3.假如發(fā)生了嚴(yán)峻的長久性傾斜，接下來的任務(wù)是找到有問題的查詢。

上一步吩咐計算的是整個節(jié)點(diǎn)的磁盤運(yùn)用量。現(xiàn)在我們要找到對應(yīng)的段數(shù)

據(jù)庫（Segment）書目，可以從主節(jié)點(diǎn)（Master）上，也可以登錄到上一

步識別出的Segment上做本操作。下面例子演示從Master執(zhí)行操作。

本例找的是排序生成的臨時文件。然而并不是全部狀況都是由排序引起的,

須要具體問題具體分析：

[gpadmin@mdwkend]$gpssh-f-/hosts-e\"Is-1

/data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*"|grep-i

sort|sort

下面是例子輸出：

[sdwl]-rw1gpadmingpadmin1002209280Jul2912:48

/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slic

el0_sort_19791_0001.0[sdwl]-rw1gpadmingpadmin

1003356160Jul29

12:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19789_0001.0[sdw1]-rw1gpadmin

gpadmin288718848Jul23

14:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tm

p_sliceO_sort_l7758_0001.0[sdw1]-rw1gpadmingpadmin

291176448Jul23

14:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tm

p_slice0_sort_17764_0001.0[sdwl]-rw1gpadmingpadmin

988446720Jul29

12:48/data1/primary/gpsegO/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19787_0001.0[sdw1]-rw1gpadmin

gpadmin995033088Jul29

12:48/data2/primary/gpseg3/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19793_0001.0[sdw1]-rw1gpadmin

gpadmin997097472Jul29

12:48/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19797_0001.0[sdw1]-rw1gpadmin

gpadmin997392384Jul29

12:48/data2/primary/gpseg4/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19795_0001.0[sdw2]-rw1gpadmin

gpadmin1002340352Jul29

12:48/data2/primary/gpseg11/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_3973_0001.0[sdw2]-rw1gpadmin

gpadmin1004339200Jul29

12:48/data1/primary/gpseg8/base/19979/pgsql_tmp/pgsql_tm

p_slicel0_sort_3967_0001.0[sdw2]-rw1gpadmingpadmin

989036544Jul29

12:48/data2/primary/gpseglO/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_3971_0001.0[sdw2]-rw1gpadmin

gpadmin993722368Jul29

12:48/datal/primary/gpseg6/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_3963_0001.0[sdw2]-rw1gpadmingpadmin

998277120Jul29

12:48/data1/primary/gpseg7/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_3965_0001.0[sdw2]-rw1gpadmingpadmin

999751680Jul29

12:48/data2/primary/gpseg9/base/19979/pgsql_tmp/pgsql.tm

p_slicel0_sort_3969_0001.0[sdw3]-rw1gpadmingpadmin

1000112128Jul29

12:48/datal/primary/gpsegl3/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24723_0001.0[sdw3]-rw1gpadmin

gpadmin1004797952Jul29

12:48/data2/primary/gpseg17/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24731_0001.0[sdw3]-rw1gpadmin

gpadmin1004994560Jul29

12:48/data2/primary/gpsegl5/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_24727_0001.0[sdw3]-rw1gpadmin

gpadmin1006108672Jul29

12:48/data1/primary/gpsegl4/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24725_0001.0[sdw3]-rw1gpadmin

gpadmin998244352Jul29

12:48/data1/primary/gpseg12/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24721_0001.0[sdw3]-rw1gpadmin

gpadmin998440960Jul29

12:48/data2/primary/gpseg16/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24729_0001.0[sdw4]-rw1gpadmin

gpadmin1001029632Jul29

12:48/data2/primary/gpseg23/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29435_0001.0[sdw4]-rw1gpadmin

gpadmin1002504192Jul29

12:48/datal/primary/gpseg20/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29429_0001.0[sdw4]-rw1gpadmin

gpadmin1002504192Jul29

12:48/data2/primary/gpseg21/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29431_0001.0[sdw4]-rw1gpadmin

gpadmin1009451008Jul29

12:48/datal/primary/gpsegl9/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29427_0001.0[sdw4]-rw1gpadmin

gpadmin980582400Jul29

12:48/data1/primary/gpsegl8/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29425_0001.0[sdw4]-rw1gpadmin

gpadmin993230848Jul29

12:48/data2/primary/gpseg22/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29433_0001.0[sdw5]-rw1gpadmin

gpadmin1000898560Jul29

12:48/data2/primary/gpseg28/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28641_0001.0[sdw5]-rw1gpadmin

gpadmin1003388928Jul29

12:48/data2/primary/gpseg29/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28643_0001.0[sdw5]-rw1gpadmin

gpadmin1008566272Jul29

12:48/data1/primary/gpseg24/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28633_0001.0[sdw5]-rw1gpadmin

gpadmin987332608Jul29

12:48/data1/primary/gpseg25/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28635_0001.0[sdw5]-rw1gpadmin

gpadmin990543872Jul29

12:48/data2/primary/gpseg27/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28639_0001.0[sdw5]-rw1gpadmin

gpadmin999620608Jul29

12:48/datal/primary/gpseg26/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28637_0001.0[sdw6]-rw1gpadmin

gpadmin1002242048Jul29

12:48/data2/primary/gpseg33/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29598_0001.0[sdw6]-rw1gpadmin

gpadmin1003683840Jul29

12:48/data1/primary/gpseg31/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29594_0001.0[sdw6]-rw1gpadmin

gpadmin1004732416Jul29

12:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29600_0001.0[sdw6]-rw1gpadmin

gpadmin986447872Jul29

12:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29602_0001.0[sdw6]-rw1gpadmin

gpadmin990543872Jul29

12:48/datal/primary/gpseg30/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29592_0001.0[sdw6]-rw1gpadmin

gpadmin992870400Jul29

12:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29596_0001.0[sdw7]-rw1gpadmin

gpadmin1007321088Jul29

12:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18530_0001.0[sdw7]-rw1gpadmin

gpadmin1011187712Jul29

12:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18526_0001.0[sdw7]-rw1gpadmin

gpadmin987332608Jul29

12:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18534_0001.0[sdw7]-rw1gpadmin

gpadmin994344960Jul29

12:48/datal/primary/gpseg38/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18528_0001.0[sdw7]-rw1gpadmin

gpadmin996114432Jul29

12:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18532_0001.0[sdw7]-rw1gpadmin

gpadmin999194624Jul29

12:48/datal/primary/gpseg36/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_18524_0001.0[sdw8]-rw1gpadmin

gpadmin1002242048Jul29

12:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_l5675_0001.0[sdw8]-rw1gpadmin

gpadmin1003520000Jul29

12:48/datal/primary/gpseg43/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15669_0001.0[sdw8]-rw1gpadmin

gpadmin1008009216Jul29

12:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15671_0001.0[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:16/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0001.0[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:21/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0002.1[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:24/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0003.2[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:26/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0004.3[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:31/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0006.5[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:32/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0005.4[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:34/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0007.6[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:36/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0008.7[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:43/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0009.8[sdw8]-rw1gpadmin

gpadmin924581888Jul29

12:48/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0010.9[sdw8]-rw1gpadmin

gpadmin990085120Jul29

12:48/data1/primary/gpseg42/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15667_0001.0[sdw8]-rw1gpadmin

gpadmin996933632Jul29

12:48/data2/primary/gpseg47/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_l5677_0001.0

從結(jié)果可以發(fā)覺主機(jī)sdw8上的Segmentgpseg45是罪魁禍?zhǔn)住?/p>

4.運(yùn)用SSH登錄到有問題的節(jié)點(diǎn)，并切換為root用戶，運(yùn)用Isof找

到擁有排序臨時文件的進(jìn)程PIDo

[root@sdw8?]#Isof

/data2/primary/gpseg45/base/19979/pgsql_tmp/

pgsql_tmp_slice10_sort_15673_0002.1COMMANDPIDUSERFD

TYPEDEVICESIZENODENAMEpostgres15673gpadminliu

REG8,481073741824

6442454675l/data2/primary/gpseg45/base/19979/pgsql_tmp

/pgsql_tmp_slice10_sort_l5673_0002.1

這個例子中PID15673也是文件名的一部分，然而并不是全部的臨時溢

出文件名都包含進(jìn)程PID。

5.運(yùn)用ps吩咐識別PID對應(yīng)的數(shù)據(jù)庫和連接信息