GreenPlum的最佳配置

2023-11-28 16:28:16 浏览数 (1)

1.配置时区

Greenplum数据库会从存储在PostgreSQL内部的一个时区集合种选择一个时区使用。PostgreSQL中存储的可用时区 全部取自于Internet Assigned Numbers Authority (IANA) 时区数据库,一旦PostgreSQL的IANA数据库发生 改变,Greenplum数据库也会随之更新它的可用时区列表。

Greenplum通过将用户定义的时区与PostgreSQL的时区进行匹配来选择自身的时区,如果用户时区没配置,则会采用 操作系统主机时区。例如,当选择默认时区时,Greenplum会基于主机操作系统时区文件并根据算法来选择PostgreSQL 的时区。如果系统时区包含闰秒信息,Greenplum数据库便不能用PostgreSQL的时区匹配到系统时区。这种情形下, Greenplum数据库会基于主机系统的相关信息来计算一个最佳的PostgreSQL时区匹配值。 作为最佳实践,应该配置Greenplum数据库和主机系统采用已知的被支持的时区。采用当前系统时区和Greenplum数据库 时区文件(该信息可能自上次重启后已经从IANA数据库更新)来匹配,这样做可以设置好Greenplum数据库master和 segment实例的时区,防止Greenplum数据库每次重启后都重新计算这个最佳匹配值。使用gpconfig工具 设置和显示Greenplum数据库时区。例如,以下命令显示Greenplum数据库时区并设置时区为US/Pacific。

代码语言:javascript复制
# gpconfig -s TimeZone
# gpconfig -c TimeZone -v 'US/Pacific'

修改时区后必须重启Greenplum数据库。重启Greenplum数据库的命令为 “gpstop -ra”。系统视图 pg_timezone_names提供Greenplum数据库时区相关的信息。

2.文件系统

XFS是Greenplum数据库数据目录的最佳实践文件系统。XFS应该用下列选项挂载:

代码语言:javascript复制
rw,nodev,noatime,nobarrier,inode64

3.网络配置

ip_local_port_range应该被设置为不与Greenplum数据库端口范围冲突。例如, /etc/sysctl.conf文件中的设置:

代码语言:javascript复制
net.ipv4.ip_local_port_range = 10000  65535

客户可以设置Greenplum数据库基础端口号为下列值。

代码语言:javascript复制
PORT_BASE = 6000
MIRROR_PORT_BASE = 7000

4.I/O配置

在含有数据目录的设备上,blockdev预读尺寸应该被设置为16384。 下列命令设置/dev/sdb的预读值大小。

代码语言:javascript复制
# /sbin/blockdev --setra 16384 /dev/sdb

下列命令显示/dev/sdb的预读值大小。

代码语言:javascript复制
# /sbin/blockdev --getra /dev/sdb
16384

应该为所有数据目录设备设置deadline IO调度器。

代码语言:javascript复制
# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq

应该在/etc/security/limits.conf文件中增加OS文件和进程的最大数量。

代码语言:javascript复制
* soft  nofile 65536
* hard  nofile 65536
* soft  nproc 131072
* hard  nproc 131072

让内核文件输出到一个已知的位置并且确保limits.conf允许输出内核文件。

代码语言:javascript复制
kernel.core_pattern = /var/core/core.%h.%t
# grep core /etc/security/limits.conf  
* soft  core unlimited

5.OS内存配置

Linux中sysctl的变量 vm.overcommit_memory和vm.overcommit_ratio 影响操作系统管理内存分配的方式。这些变量应该按照下面的方式设置:

  1. vm.overcommit_memory 决定OS用于确定为进程可以分配多少内存的方法。这个变量应该总是被 设置为2,它是对数据库唯一安全的设置。 Note: 有关如何配置overcommit memory的信息,参见: https://en.wikipedia.org/wiki/Memory_overcommitment https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
  2. vm.overcommit_ratio是被用于应用进程的RAM的百分数。在Red Hat Enterprise Linux上默认是50。 为这一变量计算最优值的公式可见资源队列的segment内存配置。
  3. 不要启用操作系统大页设置。

6.共享内存设置

Greenplum数据库使用共享内存在postgres进程之间通信,这些进程是同一个postgres 实例的组成部分。下面的共享内存设置应该在sysctl中设定并且很少会被修改。

代码语言:javascript复制
kernel.shmmax = 500000000
kernel.shmmni = 4096
kernel.shmall = 4000000000

7.验证操作系统

运行gpcheck来验证操作系统配置。

每台主机上的Segment数量 每台segment主机上运行的segment数量对总体系统性能有着巨大的影响。这些segment之间以及主机上的其他进程 共享该主机的CPU核心、内存和网络接口。过高估计一台服务器能容纳的segment数量是导致非最优性能的常见原因。

在选择每台主机上运行多少Segment时必须要考虑的因素包括:

  • 核心数量
  • 安装在该服务器上的物理RAM容量
  • NIC数量
  • 附加到服务器的存储容量
  • 主segment和镜像segment的混合
  • 将在主机上运行的ETL进程
  • 运行在主机上的非Greenplum进程

8.资源队列的segment内存配置

gp_vmem_protect_limit 服务器配置参数指定单个segment的所有活动postgres进程在任何给定时刻能够消耗的内存量。查询一旦超过该值则会失败。可使用下面的计算方法为gp_vmem_protect_limit 估计一个安全值。

step 1.使用这个公式计算gp_vmem(Greenplum数据库可用的主机内存):

代码语言:javascript复制
gp_vmem = ((SWAP   RAM) – (7.5GB   0.05 * RAM)) / 1.7

其中SWAP是主机的交换空间(以GB为单位)而RAM是主机上安装的 内存(以GB为单位)。

step 2.计算max_acting_primary_segments。当镜像segment由于集群中其他主机上的 segment或者主机故障而被激活时,这是能在一台主机上运行的主segment的最大数量。例如,对于布置在 每台主机有8个主segment的四主机块中的镜像来说,单一segment主机失效将会在其所在块中剩余每台主机 上激活2个或者3个镜像segment。这一配置的max_acting_primary_segments值是11 (8个主Segment外加3个故障时激活的镜像)。

step 3.通过将总的Greenplum数据库内存除以活动主segment的最大数量来计算gp_vmem_protect_limit:

代码语言:javascript复制
gp_vmem_protect_limit = gp_vmem / max_acting_primary_segments

转换成兆字节就是gp_vmem_protect_limit系统配置参数的设置。

对于有大量工作文件产生的场景,可调整gp_vmem的计算以增加工作文件条件:

代码语言:javascript复制
gp_vmem = ((SWAP   RAM) – (7.5GB   0.05 * RAM - (300KB * total_#_workfiles))) / 1.7

用户可以根据gp_vmem的值计算操作系统参数 vm.overcommit_ratio的值:

代码语言:javascript复制
vm.overcommit_ratio = (RAM - 0.026 * gp_vmem) / RAM

9.资源队列语句内存配置

statement_mem服务器配置参数是分配给segment数据库中任何单个查询的内存量。如果一个 语句要求额外的内存,它将溢出到磁盘。用下面的公式计算statement_mem的值:

代码语言:javascript复制
(gp_vmem_protect_limit * .9) / max_expected_concurrent_queries

例如,如果gp_vmem_protect_limit被设置为8GB(8192MB),对于40个并发查询, statement_mem的计算可以是:

代码语言:javascript复制
(8192MB * .9) / 40 = 184MB

在每个查询被溢出到磁盘之前,它被允许使用184MB内存。

要安全地增加statement_mem的值,用户必须增加gp_vmem_protect_limit 或者减少并发的查询数量。要增加gp_vmem_protect_limit,用户必须增加物理RAM或者交换空间, 也可以减少每台主机上的segment数量。

注意在集群中增加segment主机无助于内存不足错误,除非用户使用额外的主机来减少每台主机上的segment数量。

当不能提供足够的内存来映射所有的输出时,才会创建溢出文件。通常发生在缓存空间占据达到80%以上时。

另外,使用资源队列管理查询内存的最佳实践可参考资源管理。

10.资源队列溢出文件配置

如果查询没有被分配足够的内存,Greenplum数据库会在磁盘上创建溢出文件(也被称为工作文件)。 默认单个查询可以创建不超过100,000个溢出文件,这对大部分查询来说都是足够的。

用户可以用配置参数gp_workfile_limit_files_per_query控制每个查询和每个segment 创建的溢出文件最大数量。设置该参数为0将允许查询创建无限个溢出文件。限制允许的溢出文件数量可以防止失控的 查询损坏系统。

如果一个查询没有被分配足够的内存或者被查询数据中存在数据倾斜,查询可能会生成大量溢出文件。如果查询创建 超过指定数量的溢出文件,Greenplum数据库会返回这个错误:

代码语言:javascript复制
ERROR: number of workfiles per query limit exceeded

在增加gp_workfile_limit_files_per_query的值之前,尝试通过更改查询、改变数据分布 或者更改内存配置来降低溢出文件的数量。

gp_toolkit模式包括一些视图可以允许用户查看所有正在使用溢出文件的查询的信息。这些信息 可以被用来排查故障以及查询调优:

  • gp_workfile_entries视图中包含当前在某个segment上使用工作文件的操作。有关操作 的信息请见如何阅读执行计划。
  • gp_workfile_usage_per_query视图包含当前在某个segment上使用工作文件的查询。
  • gp_workfile_usage_per_segment视图为包含segment信息。每一行显示当前在该 segment上用于工作文件的磁盘空间总量。

这些视图中列的描述请见Greenplum数据库参考指南。

gp_workfile_compression配置参数指定是否压缩溢出文件。默认设置为off。 启用压缩可以提高文件溢出时的性能。

0 人点赞