YMatrix 性能常见问题

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

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;

4 在 JAVA 应用层进行点查询操作后，数据库日志中出现大量 bind 绑定变量

问题分析

大量 bind 绑定变量会占用大量性能开销。你可以通过修改 preferQueryMode 参数来避免这部分开销。preferQueryMode 是一个与数据库驱动程序相关的参数，它决定了在执行查询时使用的查询模式。将 preferQueryMode 设置为 simple 通常会获得更好的查询性能，这是因为查询只在数据所在的节点上执行，不需要进行分布式的准备过程和数据传输。

解决方案

以下两步均需执行：

URI 中加上选项 preparedThreshold=0&preferQueryMode=simple。
JDBC 版本需要升级到 postgresql-9.4.1210.jar 及以上版本，老版本 JDBC 不支持 preferQueryMode 参数。

YMatrix 性能常见问题

1 Java 压测报 Connection timed out

2 SQL 查询 motion 算子耗时长

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

4 在 JAVA 应用层进行点查询操作后，数据库日志中出现大量 bind 绑定变量

1 Java 压测报 `Connection timed out`