MatrixDB 性能常见问题

本文档记录 MatrixDB 常见性能优化相关问题。

1 Java 压测报 Connection timed out

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 SQL 查询 motion 算子耗时长

查询执行计划中发现 motion 算子开销大。

问题分析

业务环境可能为云环境。云环境对 UDP 处理低效，或导致 UDF 延迟高或丢包概率高，间接导致 UDF 数据传输时间变长。
此外，用户日志级别可能设置为了 debug5 等较高等级，大量 log 输出的过程中同样会影响 UDP 传输效率。

解决方案

切换 TCP interconnect。
开启 ic proxy。
调整 log Level

3 客户端返回大量数据时时间较长

问题描述

在使用 PSQL 客户端或使用其他客户端时返回大量数据用时较长。

解决方案

在查询前设置 FETCH_COUNT 参数限制一次性返回的数据行数。

postgres=# \set FETCH_COUNT 200
postgres=# SELECT *  FROM test_table;