HAWQ技术解析（十八） —— 问题排查

谁借莪１个温暖的怀抱￠ 2023-01-09 12:47 126阅读 0赞

（原文地址：http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/troubleshooting/Troubleshooting.html）本章描写叙述怎样解决HAWQ系统中常见的错误和问题。

## 一、查询性能问题 ##

问题：查询慢。  
原因：一个查询执行缓慢可能有多个原因。  
比如，数据分布的位置。虚拟段的数量。查询使用的主机数量等都可能影响查询性能。

下面过程描写叙述怎样排查查询性能问题。  
一个查询不像预期执行的那么快。  
下面是怎样调查慢的可能原因。

*  检查集群健康状况：（1）是否有DataNode、segment或其它节点宕机？（2）是否有非常多失效磁盘？
 *  检查表统计。查询中的表是否已经分析过？
 *  检查查询计划并执行EXPLAIN ANALYZE确定瓶颈。  
    有时。对某些操作没有足够的内存。比方Hash Join。或使用了溢出文件。假设一个操作不能全部在分配给它的内存中执行，它将数据缓存到磁盘上的溢出文件里。相对于不使用溢出文件。查询会慢得多。
 *  使用EXPLAIN ANALYZE检查数据本地化统计。或者检查日志文件。每一个查询的数据本地化情况也可在HAWQ日志中找到。  
    统计信息參见Data Locality Statistics。
 *  检查资源队列状态。你能够查询pg\_resqueue\_status视图。检查目标队列是否已经为查询分派了资源，或者目标队列缺少资源。參见Checking Existing Resource Queues。
 *  分析资源管理器状态的转储，查看很多其它资源队列状态。參见Analyzing Resource Manager Status。

## 二、拒绝查询资源请求 ##

问题：HAWQ资源管理器拒绝了查询的资源分配请求。  
原因：出现下面情况时，HAWQ资源管理器拒绝查询的资源分配请求：

*  太多物理段不可用。  
    HAWQ资源管理器期望$GPHOME/etc/slaves文件里列出的物理段均已注冊，并能够从gp\_segment\_configuration表查询到。假设资源管理器确定未注冊的或不可用的HAWQ物理段数量大于hawq\_rm\_rejectrequest\_nseg\_limit。那么资源管理器直接拒绝查询的资源请求。拒绝查询的目的是要保证查询执行在完整的集群中。这让查询性能问题的诊断更easy。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（虽然这会影响查询性能）。

## 三、VMEM使用超高引起的查询取消 ##

问题：使用太多虚拟内存的特定查询被取消。实例错误消息：  
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实例的日志文件里。

## 四、segment没在gp\_segment\_configuration中出现 ##

问题：段启动成功，但没有出如今gp\_segment\_configuration表中。  
原因：你的段可能分配了同样的IP地址。  
有些软件和项目具有使用自己主动配置IP地址的虚拟网卡。  
这可能引起HAWQ的段获得同样的IP地址。资源管理器的容错服务组件只能识别具有同样IP地址的段中的一个。  
解决方式：启动HAWQ集群前，改动网络配置，禁止IP地址同样。

## 五、调查标记为Down的segment ##

问题：HAWQ容错服务（fault tolerance service，FTS）在gp\_segment\_configuration文件夹表中标记一个段为down。  
原因：当段碰到严重错误时，FTS标记该段为down。比如，由于硬件问题导致段上的暂时文件夹失效。其它原因可能包含网络或通信错误、资源管理器错误。或简单的心跳超时等。段通过心跳报告向主节点报告一个严重故障。  
解决方式：依赖于不同的原因，须要存取不同的恢复操作。  
有些情况下。段不过被暂时标记为down，直到心跳周期再次检查段的状态。为了调查段被标记为down的原因，从gp\_configuration\_history文件夹表查找相应的原因。容错服务将段标记为down的各种原因。參见Viewing the Current Status of a Segment的描写叙述。

## 六、处理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。  
假设出现资源碎片。排队的请求不被处理，直到一些执行的查询返还资源，或者全局资源管理器提供了很多其它的资源。假设你碰到资源碎片，你应该检查资源队列设置的配额。找到为不论什么错误的配置。比如，可能的一个错误是。全局资源容器的内存核数比率，不是虚拟段资源限额的倍数。