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=10485762 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参数。
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版本为例
- 安装 llvm
# yum install llvm -y- 备份原有 addr2line
# mv /usr/bin/addr2line /usr/bin/addr2line_bak- 建立软链接
# ln -s /usr/bin/llvm-addr2line /usr/bin/addr2line- 验证是否替换成功
# addr2line --version