常见问题

1. 安装

问题1

现象

yum install matrixdb安装包后报错cpio read error

原因

用户环境为windows,使用vm15虚拟机,windows下载安装包后文件拖拽到虚拟机,导致文件被截断

解决方案

使用vm共享目录机制传输数据,参考https://blog.csdn.net/highning/article/details/106000215

问题2

现象

创建mars扩展时,报错:

could not load library "/usr/local/matrixdb-4.0.0.enterprise/lib/postgresql/mars.so": /lib64/libarrow.so.300: undefined symbol: LZ4F_resetDecompressionContext

原因

matrixdb 4依赖arrow 300, arrow需要LZ4的版本>= 1.8

解决方案

升级lz4

问题3

现象

初始化时报错:

could not connect to server: No route to host
 Is the server running on host "192.168.88.203" and accepting
 TCP/IP connections on port 40000?
 (seg0 192.168.88.203:40000)

原因

203机器关掉了iptables,但是没有disable,重启机器后,防火墙又起动了,端口默认没有放开,导致初始化时机器无法通信,现象就是初始化一直卡住,无法完成。

解决方案

清空203机器上的防火墙规则,停掉iptables服务并且disable,防止重启后,网络不通。

问题4

现象

setuptools报告不支持参数:

unknown distribution option:"long_description_content_type'

原因

setuptools 版本比较老

解决方案

sudo python3 -m pip install --upgrade setuptools

问题5

现象

卸载重装后,无法重新初始化集群

原因

重装集群需要做必要的清理工作

解决方案

  1. 删除 mxadmin用户的~/.matrixdb.env
  2. 删除 /etc/matrixdb/cluster.conf
  3. 重启supervisor
    • systemctl restart matrixdb.supervisor.service
  4. 再次刷新安装界面: http://[主节点IP]:8240/installer

2. 网络

问题1

现象

JDBC查询压力测试,并发50,连接池采用阿里的druid。2.5分钟内响应时间平稳,之后响应时间变长,master开始出现如下错误:

ERROR "failed to acquire resources on one or more segments", "could not connect to server: Connection timed out"

segment无error/panic log

原因

分布式数据库会有大量的TCP/UDP数据传输,每次传输都会使用不同的端口号,这些端口号或连接在OS看来都是一次路由(连接conn),系统参数nf_conntrack_max的意思是OS最多可以同时维护路由信息的个数。因为我们的多台虚拟机在一个物理机上,虚拟网络用的应该是NAT,这样当大量并发查询同时来的时候,会导致虚拟路由信息暴增,可能在短时间内超过nf_conntrack_max限制,进而导致网卡主动丢弃掉来不及处理的package。这也可以解释之前一段时间内并发查询越大越容易发生丢包的现象。

解决方案

修改内核参数

sudo sysctl net.netfilter.nf_conntrack_buckets=262144
sudo sysctl net.netfilter.nf_conntrack_max=1048576

问题2

现象

查询中motion开销大

原因

  1. 环境为云环境,云环境对UDP处理低效,或导致UDF延迟高或丢包概率高,间接导致UDF数据传输时间变长
  2. 用户日志级别设置为debug5,大量log输出的过程中会影响UDP传输效率

解决方案

  1. 切换TCP interconnect
  2. 开启ic proxy
  3. 调整log Level

3. 查询

问题1

现象

UI客户端访问远程数据库,长查询过程中或长时间idle后发查询,客户端有些时候会收到log:

server closed the connection unexpectedly

原因

客户端存在查询超时cancel设置,或idle超时cancel连接设置

解决方案

更改客户端超时设置,取消超时

问题2

现象

PARTITION表简单Filter操作的UNION ALL查询比IN查询慢

原因

PARTITION表的IN查询,分区裁剪后只有1个default分区,但UNION ALL查询中每个子查询都裁剪到了default分区,做了多次default分区的扫描,性能影响明显

解决方案

对于PARTITION表

  1. 尽量避免default分区
  2. 尽量不用UNION而用in子句

问题3

现象

insert int类型,再select查询单独跑很快,放到plpgsql function里很慢

原因

plpgsql function内的查询是通过SPI运行,SPI Plan输出结果里是两表Join,采用了nestloop,语句rows=1,没有analyze

解决方案

执行analyze

问题4

现象

PARTITION分区裁剪更新操作,两个session独立更新会导致互锁

原因

分布式死锁

解决方案

打开分布式死锁检测

gpconfig -c gp_enable_global_deadlock_detector -v on

4. 存储

问题1

现象

数据加载性能低

原因

gpcheckperf看磁盘性能,网络性能,发现磁盘性能仅 80MB/s

解决方案

加载多块磁盘提升IO性能,WAL和Data数据盘分开提升IO性能

问题2

现象

mxgate同时开启加载30张表 ,报错:

failed to acquire resources on on or more segments ,fatal out of memory

原因

PG/GP是多进程模式,高并发请求过来,连接数过多,无法分配内存给相应的请求,从而报错。

解决方案

调整参数/etc/sysctl.conf vm.overcommit_memory = 2 mxgate prepared=10改为prepared=5

5. PXF

问题1

现象

PXF部署后,访问HDFS报错:

remote component error,Failed connect to localhost:5888; Connection refused (libchurl.c:950)

解决方案

  1. PXF访问文件的方式需要在master节点开启pxf server,但是数据文件需要在segment pxf上
  2. pxf/servers/core-site.xml和hdfs-site.xml一定要和hadoop配置文件相同
  3. pxf/servers/core-site.xml配置用户访问权限
  4. hadoop上文件的用户名和组需要和pxf/core-site.xml指定的一致

问题2

现象

文件入库时,某一个字段包含换行符,将一行数据切分成两行,再以分隔符切分,就会导致数据与字段数不一致,也就是说一行数据里有两个\n 一个在中间一个在尾部 但是中间那个不能被当做换行符处理

解决方案

  1. 可以在option里加入escaple 'off'
  2. 也可以使用 format 'text:multi'