YMatrix 文档

版本发布历史
系统需求

关于 YMatrix

快速上手

标准集群部署

数据建模

连接到数据库

数据写入

数据迁移

数据查询

运维监控

性能调优

故障诊断

参考指南

SQL 参考

常见问题（FAQ）

场景应用

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 传输效率。

解决方案

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


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

问题描述

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

解决方案

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

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


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

问题分析

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

解决方案

以下两步均需执行：

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

5 由于 addr2line 工具引起 Postgres 崩溃或内存资源占用较大的问题，如何替换成 llvm-addr2line

问题描述

在数据库集群正常运行一段时间后，服务器出现资源紧张宕机的问题，导致数据库集群节点异常，无法通过 ssh 进行连接

问题分析

通过查看系统 message 日志信息，发现服务器在某个时间点出现大量 addr2line 进程，造成服务器资源紧张

Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400707] [  96593]  1001 96593    78471    24188   249856        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400708] [  96594]  1001 96594    85480    28085   290816        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400709] [  96595]  1001 96595    85480    29534   307200        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400710] [  96596]  1001 96596    77318    23547   249856        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400711] [  96597]  1001 96597    85480    29597   294912        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400712] [  96598]  1001 96598    85480    31518   315392        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400714] [  96599]  1001 96599    85480    29146   290816        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400715] [  96600]  1001 96600    77318    23283   253952        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400716] [  96601]  1001 96601    77318    23322   253952        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400718] [  96602]  1001 96602    76199    22816   241664        0             0 addr2line
......
......
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.402077] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/matrixdb5.supervisor.service,task=addr2line,pid=96124,uid=1001
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.402084] Out of memory: Killed process 96124 (addr2line) total-vm:355284kB, anon-rss:141732kB, file-rss:0kB, shmem-rss:0kB
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.427650] oom_reaper: reaped process 96124 (addr2line), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

解决方案

可将系统原有的 addr2line 工具进行备份，替换为 llvm-addr2line，以银河麒麟V10 SP3版本为例

  1. 安装 llvm
# yum install llvm -y
  1. 备份原有 addr2line
# mv /usr/bin/addr2line /usr/bin/addr2line_bak
  1. 建立软链接
# ln -s /usr/bin/llvm-addr2line /usr/bin/addr2line
  1. 验证是否替换成功
# addr2line --version