(原文地址:http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/troubleshooting/Troubleshooting.html) 本章描述如何解决 HAWQ 系统中常见的错误和问题。
查询慢。
原因:一个查询执行缓慢可能有多个原因。例如,数据分布的位置,虚拟段的数量,查询使用的主机数量等都可能影响查询性能。以下过程描述如何排查查询性能问题。 一个查询不像预期执行的那么快。以下是如何调查慢的可能原因。
HAWQ 资源管理器拒绝了查询的资源分配请求。
原因:出现以下情况时,HAWQ 资源管理器拒绝查询的资源分配请求:
HAWQ 资源管理器期望 $GPHOME/etc/slaves 文件中列出的物理段均已注册,并可以从 gp_segment_configuration 表查询到。如果资源管理器确定未注册的或不可用的 HAWQ 物理段数量大于 hawq_rm_rejectrequest_nseg_limit,那么资源管理器直接拒绝查询的资源请求。拒绝查询的目的是要保证查询运行在完整的集群中。这让查询性能问题的诊断更容易。hawq_rm_rejectrequest_nseg_limit 的缺省值为 0.25,就是说如果发现不可用或未注册的数量大于 0.25 * $GPHOME/etc/slaves 文件中所列的段数,资源管理器拒绝查询的资源请求。例如,如果 slaves 文件中有 15 个段,资源管理器计算不可用的段不能超过 4(0.25 * 15)。大多数情况下,你不需要修改该此缺省值。
超过了 hawq_rm_tolerate_nseg_limit 中定义的限制。
为保证最佳查询性能,HAWQ 资源管理器试图尽可能均匀地在物理段间为查询分配虚拟段。但是可能存在分配偏差。当偏差大于 hawq_rm_nvseg_variance_amon_seg_limit 设置的值,HAWQ 拒绝查询的资源分配请求。例如,一个查询引起 2 个物理段分派 9 个虚拟段。假设一个段分配 7 个虚拟段,另一个分配 2 个虚拟段。段间偏差是 5。如果 hawq_rm_nvseg_variance_amon_seg_limit 的设置为缺省值 1,那么为此查询的资源分配被拒绝,并将在以后分配。但如果一个物理段分配 5 个虚拟段,另一个物理段是 4 个,则接收此资源分配。
检查集群中节点的状态。如果有必要,重启或新增节点。修改 hawq_rm_nvseg_variance_amon_seg_limit(尽管这会影响查询性能)。
使用太多虚拟内存的特定查询被取消。实例错误消息:
原因:
- ERROR: Canceling query because of high VMEM usage.Used: 1748MB,
- available 480MB,
- red zone: 9216MB(runaway_cleaner.c: 135)(seg74 bcn - w3: 5532 pid = 33619)(dispatcher.c: 1681)
当一个段上虚拟内存的使用超过了由 runaway_detector_activation_percent 配置的虚拟内存百分比阈值,就会发生此错误。 如果一个物理段使用的虚拟内存总量超过计算阈值,HAWQ 开始基于内存使用终止查询,从消耗最大内存量的查询开始。直到虚拟内存使用低于指定的百分比才停止对查询的终止。
解决方案:临时加大 hawq_re_memory_overcommit_max 的值,允许特性查询无误运行。 检查 pg_log 文件,得到会话和 QE 进程使用内存的更多细节。HAWQ 记录查询终止信息,如内存分配历史、上下文信息,以及查询计划操作符的内存使用信息。这些信息被发送到 master 和 segment 实例的日志文件中。
段启动成功,但没有出现在 gp_segment_configuration 表中。
原因:你的段可能分配了相同的 IP 地址。 有些软件和项目具有使用自动配置 IP 地址的虚拟网卡。这可能引起 HAWQ 的段获得相同的 IP 地址。资源管理器的容错服务组件只能识别具有相同 IP 地址的段中的一个。
解决方案:启动 HAWQ 集群前,修改网络配置,禁止 IP 地址相同。
HAWQ 容错服务(fault tolerance service,FTS)在 gp_segment_configuration 目录表中标记一个段为 down。
原因:当段碰到严重错误时,FTS 标记该段为 down。例如,因为硬件问题导致段上的临时目录失效。其它原因可能包括网络或通信错误、资源管理器错误,或简单的心跳超时等。段通过心跳报告向主节点报告一个严重故障。
解决方案:依赖于不同的原因,需要存取不同的恢复操作。有些情况下,段仅仅是被临时标记为 down,直到心跳周期再次检查段的状态。为了调查段被标记为 down 的原因,从 gp_configuration_history 目录表查找对应的原因。容错服务将段标记为 down 的各种原因,参见 Viewing the Current Status of a Segment 的描述。
不同 HAWQ 资源队列的虚拟段资源限额可以不同,由此可能导致资源碎片。例如,一个 HAWQ 集群有 4GB 内存可用于当前排队的查询,但是资源队列被配置为在 4 个不同的段上分裂成四个 512MB 的内存块。它不可能分配两个 1GB 内存的虚拟段。
在独立资源模式中,所有段资源为 HAWQ 所独占。当段的配额不是虚拟段资源限额的倍数时,就可能出现资源碎片。例如,一个段有 15GB 的内存配额,但是虚拟段资源限额设置成 2GB。一个段最多可以消耗 14GB 内存。因此,你应该配置段的资源配额为所有虚拟段资源限额的倍数。
YARN 模式里,资源从 YARN 资源管理器分配。HAWQ 资源管理器通过一个 vcore 获得一个 YARN 容器。例如,如果 YARN 报告一个段为 YARN 应用配置了 64GB 内存和 16 个 vcore,HAWQ 通过 4GB 内存和 1 个 vcore 请求 YARN 容器。照此方法,HAWQ 资源管理器按需获取 YARN 容器。如果 YARN 容器的配额不是虚拟段资源限额的倍数,可能发生资源碎片。例如,YARN 容器的资源配额为 3GB 内存和 1 个 vcore,每个段可以有 1 个或 3 个 YARN 容器用于 HAWQ 执行查询。在这种情况下,如果虚拟段的资源限额为 2GB 内存,那么 HAWQ 总有 1GB 内存不能利用。因此,推荐仔细配置 YARN 模式的资源配额,使 YARN 容器资源限额是所有虚拟段资源限额的倍数。另外,确认你的 CPU、内存比率是 yarn.scheduler.minimum-allocation-mb 配置的倍数。更多信息参见 Setting HAWQ Segment Resource Capacity in YARN。
如果出现资源碎片,排队的请求不被处理,直到一些运行的查询返还资源,或者全局资源管理器提供了更多的资源。如果你碰到资源碎片,你应该检查资源队列设置的配额,找到为任何错误的配置。例如,可能的一个错误是,全局资源容器的内存核数比率,不是虚拟段资源限额的倍数。
来源: http://blog.csdn.net/wzy0623/article/details/70911364