第八章 Greenplum 线上环境部署

[TOC]

本章开始讲解如何搭建一个高性能、安全可靠、可扩展、可管理的 Greenplum 集群。

8.1 服务器硬件选型

数据库服务器硬件选型应该遵循以下几个原则：

（1）高性能原则

保证所选购的服务器，不仅能够满足现有应用的需要，而且能够满足一定时期内业务量增长的需要。对于数据库而言，数据库性能依赖于硬件的性能和各种硬件资源的均衡，CPU、内存、磁盘、网络这几个关键组件在系统中都很关键，如果过分突出某一方面硬件资源则会造成大量的资源浪费，而任何一个硬件性能差都会成为系统的瓶颈，故在硬件选择的时候，需要根据应用需求在预算中做到平衡。

（2）可靠性原则

不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性。

（3）可扩展性原则

需要服务器能够在相应时间根据业务发展的需要对其自身进行相应的升级，如 CPU 型号升级、内存扩大、硬盘扩大、更换网卡等。

（4）可管理型原则

需要服务器的软硬件对标准的管理系统提供支持。

8.1.1 CPU

CPU 选择主要考虑以下两个方面：

Interl 还是 AMD
更快的处理器还是更多的处理器

Intel 作为单核运算速度方面的领导者，其 CPU 及相关组件相对较贵，而 AMD 在多核处理技术方面表现优异，仍不失为一个较好的选择。

如果仅有较少进程运行在单个处理器上，则可以考虑配置更快的 CPU。相反，如果大量并发进程运行在所有处理器上，则考虑配备更多的核。

一台服务器上 CPU 的数量决定部署到机器上的 gp 数据库 Segment 实例的数量，比如一个 CPU 配置一个主 Segment。

8.1.2 内存

内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁。计算机中所有程序运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。内存的选择总体上来说是越大越好。

对于处理像数据库这样的海量数据，并且内存远小于数据存储的情况，如歌内存已经够用，通过增加内存来获取性能的提升则非常细微。对于 gp ，磁盘的吞吐量决定 gp 的性能，磁盘吞吐量越高性能越好。

8.1.3 磁盘及硬盘接口

硬盘分为固态硬盘（SSD）和机械硬盘（HDD），SSD 采用闪存颗粒来存储，HDD 采用磁性碟片来存储。

硬盘接口主要有如下几类：

（1）ATA（Advanced Technology Attachment）

是用传统的 40-pin 并口数据线连接主板与硬盘的。外部接口速度最大为 133MB/s。因为并口线的抗干扰性太差，且排线占空间，不利计算机散热，将逐渐被 SATA 所取代。

（2）IDE（Integrated Drive Electonices）

即电子集成驱动器，是把“硬盘控制器”与“盘体”集成在一起的硬盘驱动器。

（3）SCSI 小型计算机系统接口

同 IDE 和 ATA 完全不同的接口，IDE 接口是普通 PC的标准接口，而 SCSI 并不是专门为硬盘设计的接口，是一种广泛应用于小型机上的高速数据上传输技术。SCSI 接口具有应用范围广、任务多、带宽大、CPU 占用率低，以及热插拔等优点，但较高的价格

（4）SATA（Serial Advanced Technology Attachment）

串行高级技术附件，一种基于行业标准的串行硬件驱动器接口，是由Intel、IBM、Dell、APT、Maxtor 和 Seagate 公司共同提出的硬盘接口规范。

（5）SAS（Serial Attached SCSI，串行连接SCSI）

是新一代的 SCSI 技术。同 SATA 都采用串行技术以获得更高的传输速度，并通过缩短连接线改善内部空间等。

（6）SSD（Solid State Disk）

即固态硬盘。

表8-1

在选择硬盘和硬盘控制器时，确认选择的硬盘控制器能够包括硬盘带宽之和。假如有20个 70Mb/s 内部带宽的硬盘，为了获得硬盘最佳性能，需要最少支持 1.4Gb/s 的硬盘控制器。

要提升服务器 I/O 吞吐量、可用性及存储容量，常见的方法是做 RAID，即独立冗余磁盘阵列（Redundant Array of Independent Disk，RAID）。

几种常见的 RAID 技术如下：

（1）RAID 0

从严格意义上说，RAID 0 不是 RAID，因为它没有数据冗余和校验。RAID0 技术只是实现了条带化，具有很高的数据传输率，最高的存储利用率，但是 RAID中硬盘数越多，安全性越低。

（2）RAID 1

通常称为 RAID 镜像。RAID 1 主要是通过数据镜像实现数据冗余，在两对分离的磁盘上产生互为备份的数据，因此 RAID 1 具有很高的安全性。但是 RAID空间利用率低，磁盘控制器负载大，因此只有当系统需要极高的可靠性时，才选择 RAID 1。

（3）RAID 1+0

RAID 0+1 至少需要 4 块硬盘才可以实现，不过它综合 RAID 0 和 RAID 1 的特点，独立磁盘配置成 RAID 0，两套完整的 RAID 0 互相镜像。它的读写性能出色，安全性也较高。但是构建 RAID 0+1 阵列的成本投入大，数据空间利用率只有 50%，因此还不能称为经济高效的方案。

（4）RAID 5

RAID 5 是目前应用最广泛的 RAID 技术。各块独立硬盘进行条带化分隔，相同的条带区进行奇偶校验（异或运算），校验数据平均分布在每块硬盘上。RAID 5 具有数据安全、读写速度快、空间利用率高等优点，应用非常广泛。但是不足之处是，如果1块硬盘出现故障，整个系统的性能将大大降低。

8.1.4 网络

gp 数据库互联的性能与 Segment 上网卡的网络负载有关，所以 gp 服务器一般由一组多个网卡的硬件组成。为了达到最好性能，gp 建议为 Segment 机器上的每一个机器上的每一个主 Segment 配置一个千兆网卡，或者配置每台机器都有万兆网卡。

如果 gp 数据库网络集群中有多个网络交换机，那么交换机之间均衡地分配子网较为理想，比如每个机器上的网卡1和2用其中一个交换机，网卡3和4使用另一个交换机。

8.2 服务器系统参数调整

对于不同的应用场景，每一种硬件都有不同的参数配置，通过参数调整，可以极大地提高读写性能。对于 OLTP 数据库而言，关注的是磁盘的随机读写，提高单次读写的性能；而对于 OLAP 数据库而言，最关注的是磁盘的顺序读写，重点在于提高每次磁盘读写的吞吐量。

GP 目前支持的操作系统有以下几种：

SUSE Linux SLES 10.2 or higher
CentOS 5.0 or higher
RedHat Enterprise Linux 5.0 or higher
Oracle Unbreakable Linux 5.5
Solaris x86 v10 update 7

一般情况下，需要在操作系统中修改以下三种类型的参数：

（1）共享内存

gp 只有在操作系统中内存大小配置适当的时候才能正常工作。大部分操作系统的共享内存设置太小，不适合 gp 的场景，因为这样可以避免进程因为内存占用过高被操作系统停止。

（2）网络

gp 的数据分布在各个节点上，因此在计算过程中经常需要将数据移动到其他节点上进行计算，这是，合理的网络配置就显得格外的重要。

（3）系统对用户的限制

操作系统在默认情况下会对用户进行一下资源的限制，以避免某个用户占用太多资源导致其他用户资源不可用。对于数据库来说，只会有一个操作系统用户，这些限制都必须取消掉，例如 gp 会同时打开很多文件句柄，而操作系统默认的文件句柄一般很小。

8.2.1 Solaris 参数修改

8.2.2 Linux 参数修改

在 Linux，对应共享内存，网络、用户限制的参数修改如下。

/etc/sysctl.conf，修改共享内存及网络 ipv4 的配置：

kernel.sem = 250 64000 100 512
kernel.shmmax = 5000000000
kernel.shmmni = 4096
kernel.shmall = 4000000000
kernel.sem = 250 64000 100 512
kernel.sysrq = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
net.ipv4.tcp_syncookies = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
nete.core.net.netdev_max_backlog=10000
vm.overcommit_memory=2

修改文件数，进程数的限制

* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

8.2.3 系统参数及性能验证

gp 中提供了 gpcheck 脚本对系统参数进行校验，确保配置合理，同时还提高了 gpcheckperf 对机器进行性能测试，包括网络性能测试、磁盘 I/O 吞吐测试、内存带宽测试等。

（1）使用 gpcheck 脚本对系统参数进行验证，命令如下：

[root@test /] # gpcheck -h dw-greenplum-l

gpcheck

这个脚本会配置一些需要校验的参数，在 $GPHOME/etc/gpcheck.cnf 文件中，如如果参数配置与 gpcheck.cnf 中的不一致，则会报出一条 ERROR。例如在上面这个例子中，错误显示在 /etc/project 中没有诶之相应的参数。

（2）网络测试

利用 gp 自带的 gpcheckperf 工具可以很方便地测试各节点间网络连通情况。

网络测试的机器名列表如下（host.1 文件中）

host.1

运行 gpcheckperf 进行测试：

[gpadmin@dw-greenplum-3 /export/home/gpadmin]# gpcheckperf -d /storagepool/upload -r N -f host.1 
/opt/greenplum/greenplum-db-4.1.1.1/bin/gpcheckperf -d /storagepool/upload -r N -f host.1

gpcheckperf

（3）文件系统性能验证

利用 gp 自带的 gpcheckperf 工具可以很方便地测试文件系统的读写性能，示例代码如下：

[gpadmin@greenplum-3 /export/home/gpadmin]# gpcheckperf -d /storagepool/gptempp1 -d /storagepool/gptempp2 -d /storagepool/gptempp3 -d /storagepool/gptempp4 -d /storagepool/gptempm1 -d /storagepool/gptempm2 -d /storagepool/gptempm3 -d /storagepool/gptempm4 -r ds -D -f host.1 /opt/greenplum/greenplum-db-4.1.1.1/bin/gpcheckperf -d /storagepool/gptempp1 -d /storagepool/gptempp2 -d /storagepool/gptempp3 -d /storagepool/gptempp4 -d /storagepool/gptempm1 -d /storagepool/gptempm2 -d /storagepool/gptempm3 -d /storagepool/gptempm4 -r ds -D -f host.1

8.3 计算节点分配技巧

如果配置了 mirror 节点，其会分布在所有 Segment 节点上，在默认情况下同一服务器上主节点对应的所有备节点会分配在一台服务器上（这种方式称为 Grouped Mirror），这样一旦某一台计算节点死机，所有备节点会在同一台服务器上，致使性能降低 50%，且不利于数据恢复。在初始化数据库时，可以指定 -S 参数，将同一服务器上主节点对应的备节点打散至集群不同服务器上（这种方式称为 Spread Mirror）

8.4 数据库参数介绍

数据库优化主要从两个方面着手：

提升 CPU、内存、磁盘、网络等集群服务器的硬件配置
优化提交到数据库的语句

简单介绍一下影响数据库性能的参数及其他常用的配置参数：

（1）shared_buffers

数据距离 CPU 越近效率就越高，而离 CPU 由近到远的主要设备有寄存器、CPU cache、RAM、Disk Drives 等。CPU 的寄存器和 cache 是没办法直接优化的。为了避免磁盘访问，只能尽可能将更多有用信息存放在 RAM 中。gp 数据库的 RAM 主要用于存放如下信息：

执行程序
程序数据和堆栈
postgreSQL shared buffer cache
kernel disk buffer cache
kernel

因此最大化地保持数据库信息在内存中而不影响其他区域才是最佳的调优方式。

pgsql 并非直接在磁盘上进行数据修改，而是将数据读入 shared buffercache，进而 pgsql 后台进程修改 cache 中的数据块，最终再写回磁盘。后台进程如果在 cache 中找到相关数据，则直接进行操作，如果没找到，则需要从 kernel disk buffer cache 或者磁盘中读入。pgsql 默认的 shared buffer 较小，将此 cache 调大则可降低昂贵的磁盘访问。但前面提到，修改此参数时一定要避免 swap 发生，因为内存不仅仅用于 shared buffer cache。刚开始可以设置一个较小的值，比如总内存的15%，然后逐渐增加，过程中监控性能提升和swap 的情况。

（2）effective_cache_size

设置优化器假设磁盘高速缓存的大小用于查询语句的执行计划判断，主要用于判断使用索引的成本，此参数越大越有机会选择索引扫描，越小越倾向于选择顺序扫描，此参数只会影响执行计划的选择。

（3）work_mem

当 pgsql 对大表进行排序时，数据库会按照此参数指定大小进行分片排序，将中间结果存放在临时文件中，这些中间结果的临时文件最终会再次合并排序，所以增加此参数可以减少临时文件个数进而提升排序效率。如果设置过大，会导致 swap 的发生，所以设置此参数是仍然需要谨慎。同样刚开始仍可设置为总内存的5%。

（4）temp_buffers

temp_buffers 即临时缓冲区，用于数据库访问临时表数据，gp 默认值为 1M。可以在单独的 session 中对该参数进行设置，在访问比较大的临时表时，对性能提升有很大帮助。

（5）client_encoding

设置客户端字符集，默认和数据库 encoding 相同

（6）client_min_messages

控制发送至客户端的信息级别，每个级别包括更低级别的消息，越是低的消息级别发送至客户端的信息越少。此参数主要用于错误调试。

（7）cpu_index_tuple_cost

设置执行计划评估每一个索引行扫描的 CPU 成本。同类参数还包括 cpu_operator_cost、cpu_tuple_cost、cursor_tuple_fraction。

（8）debug_assertions

打开各种断言检查，这是调试助手。如果遇到了奇怪的问题或数据库崩溃，那么可以将这个参数打开，便于分析错误原因。

（9）debug_print_parse

当需要查看查询语句是分析树时，可以设置开启此参数，默认off

（10）debug_print_plan

当需要查看查询语句的执行计划时，可以设置开启此参数，默认为 off。同类参数包括 debug_print_prelim_plan、debug_print_rewritten、debug_print_slice_table。

（11）default_tablespace

指定创建对象时的默认表空间

（12）dynamic_library_path

在创建函数或者加载命令时，如果未指定目录，将会从这个路径搜索需要的文件。

（13）enable_bitmapscan

表示是否允许位图索引扫描，类似的参数还有 enable_groupagg、enable_hashagg、enable_hashjoin、enable_indexscan、enable_mergejoin、enable_nestloop、enable_seqscan、enable_sort、enable_tidscan。这些参数主要用于控制执行计划。

（14）gp_autostats_mode

指定触发自动搜集统计信息的条件。当此值为 on_no_stats 时，create table as select 会自动搜集统计信息，如果 insert 和 copy 操作的表没有统计信息，也会自动触发统计信息搜集。当此值为 on_change 时，如果变化量超过 gp_autostats_on_threshold 参数设置的值，会自动触发统计信息搜集。此参数还可设为 none 值，即不自动触发统计信息搜集。

（15）gp_enable_gpperfmon

要使用 Greenplum Performance Monitor 工具，必须开启此参数。

（16）gp_enable_max_segs

设置外部表数据扫描可用 Segment 数目

（17）gp_fts_probe_interval

设置 ftsprobe 进程对 Segment failure 检查的间隔时间

（18）gp_fts_probe_threadcount

设置 ftsprobe 线程数，此参数建议大于等于每台服务器 Segments 的数目

（19）gp_fts_probe_timeout

设置 ftsprobe 进程用于标识 Segment down 的连接 Segment 的超时时间。

（20）gp_hashjoin_tuples_per_bucket

此参数越小，hash tables 越大，可提升 join 性能，相关参数还有 gp_interconnect_hash_multiplier、gp_interconnect_hash_multiplier、gp_interconnect_depth。

（21）gp_interconnect_setup_timeout

此参数在负载较大的集群中，应该设置较大的值。

（22）gp_interconnect_type

可选值为 TCP、UDP，用于设置连接协议。TCP 最大只允许 1000 个节点实例。

（23）gp_log_format

设置服务器日志文件格式。可选值为 csv 和 text。

（24）gp_max_database

设置服务器允许的最大数据库数，相关参数还有gp_max_filespaces、gp_max_packet_size、gp_maxa_tablespaces

（25）gp_resqueue_memory_policy

此参数允许 none 和 auto 这两个值，当设置 none 时，gp 4.1 版本以前的策略一致；设置 auto 时，查询内存使用受 statement_mem 和资源队列的内存限制，而 work_mem、max_work_mem 和 maintenance_work_mem 这三个参数将失效。

（26）gp_resqueue_priority_cpucores_per_segment

指定每个 Segment 可用的 CPU 单元

（27）gp_segment_connect_timeout

设置网络连接超时时间

（28）gp_set_proc_affinity

设置进程是否绑定到 CPU

（29）gp_set_read_only

设置数据库是否允许写

（30）gp_vmem_idle_resource_timeout

设置数据库会话超时时间，超过此参数值会话将释放系统资源。此参数越小，集群并发度支持越高

（31）gp_vmem_protect_limit

设置服务器中 postgres 进程可用的总内存，建议设置为 (X * physical_memory ) / primary_segments，其中 X 可设置为 1.0 和 1.5 之间的数字，当 X=1.5 时容易引发 swap，但是会减少因内存不足而失败的查询数。

（32）log_min_duration_statement

当查询语句执行时间超过此值时，将会记录日志，相关参数参考 log_开头的所有参数。

（33）maintenance_work_mem

设置用于维护的操作可用的内存数，比如 vacuum、create index 等操作将受到这个参数的影响。

（34）max_appendonly_tables

最大可并发处理的 appendonly 表的数目

（35）max_connections

最大连接数，Segment 建议设置 Master 的5-10倍。

（36）max_statement_mem

设置单个查询语句的最大内存限制，相关参数是 max_work_mem

（37）random_page_cost

设置随机扫描的执行计划评估成本，此值越大越倾向于选择顺序扫描，越小越倾向于选择索引扫描

（38）search_path

设置未指定 schema 时，按照这个顺序选择对象的 schema

（39）statement_timeout

设置语句终止执行的超时时间，0表示永不终止

8.5 数据库集群基准测试

在集群搭建完成正式应用上线之前，对集群整体性能做一个基准测试是很有必要的，比如验证数据库参数设置是否恰当、集群稳定性如何等。

TPC-H（商业智能计算测试），主要用于 ad-hoc、决策支持等系统的基准测试。

（1）TPC_H 下载即安装

http://www.tpc.org/tpch/default.asp 下载 tpch-queries.tgz 包，解压后准备 Makefile 文件（可以将文件夹中的 makefile.suite 作为模板），Makefile 文件的第 109 行左右有项要适当的修改，如 CC=gcc、DATABASE=TDAT、MACHINE=LINUX、WORKLOAD=TPCH，修改完成之后，运行 make 命令进行编译即可

（2）测试数据生成

（以下略）

（3）测试表创建

（4）测试数据导入

（5）测试脚本准备

（6）运行基准测试脚本

Greenplum企业应用实战（笔记）：第八章 Greenplum 线上环境部署