生产环境tidb和tikv放一台服务器

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:
  • 【问题描述】:服务器 16核 内存64G 共三台服务器 其中一台同时部署了tidb和tikv 查询单表数据300w ,查询特别慢 请问这跟部署的有关系吗

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

生产环境建议按照官网推荐的标准部署。 https://pingcap.com/docs-cn/stable/how-to/deploy/hardware-recommendations/

tikv 是不建议和 pd 或者 tidb 混合部署的,如果是简单 sql 的话,可以结合执行计划以及慢查询来看下是否可以优化。

能否帮忙看一下

辛苦你这边 检查 SQL 涉及的表的执行计划是否是最新,注意 https://pingcap.com/docs-cn/v3.0/reference/performance/statistics/

另外麻烦提供下 tidb 的版本、两个表结构、数据量、以及该 sql 的慢查询日志吧

慢查询日志 SELECT * FROM michain_enterprise_test.t_bill LIMIT 0, 1000 2020-02-20 16:31:42.353867 00:00:04 Process_time: 0.012 Request_count: 1 Total_keys: 2017 Process_keys: 2016 1 16 414760960611844097 root michain_enterprise_test [4635] 0 d090fb61de8f46382f98ad19b6f30cbc9697db801b4c2c8531dc07f06ff72afd tidb 版本是 3.0.9 b_bill 是300万数据
%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20200220163736

您好,您这边提供的两个 sql 前后不一致,请确认下,是哪个 sql 执行比较慢?要分析哪个 sql 呢 ?

第一个是两个表走了 hash join ,如果确认cpu 资源比较多,可以尝试调整 hash join 的 concurrency 的大小。另外一张表应该也可以加索引试试。

目前服务器是16核的 查询时发现tidb-server占用内存和cpu较多 内存一直再涨 %E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20200221110639

您好:预格式化文本

  1. 麻烦再明确一下当前的问题,您觉得哪里有问题? 是不该占用这么多cpu,还是需要查看哪个sql运行慢?
  2. tidb-server的cpu达到98%时,总的cpu使用率是多少? 请截取top的完整信息
  3. 看你的这个sql是查询对吧? 请帮忙执行explain analyze 看一下实际执行的执行计划,多谢.

1.上个问题是 tidb和tikv放一起会严重影响性能吗
如果我再添加一台服务器 ,默认配置的话 ,请问查询速度能否上去 3.查询sql 这是查询慢日志 select SUM(t.sum_bill_price) as sumBillPrice from t_bill t left join t_company tc on tc.company_code=t.company_code WHERE 1=1 2020-02-21 11:05:22.455113 00:00:00 Process_time: 5.236 Wait_time: 0.008 Request_count: 19 Total_keys: 3000397 Process_keys: 3000378 1 2 414778477100138499 root@172.18.218.80 michain_enterprise_test [4635] [t_company:t_company_code] 0 fdf99c586286fab67b9961badd75aab963d60f6ec967fc7723685f9647b96716 执行计划

您好:预格式化文本

1.从你的执行计划看当前执行此sql语句只需要769ms, 但是慢日志中达到了5s多, 所以你的问题不是这个sql执行的慢,是你在开启了并发的时候,sql执行变慢,对吗? 你的并发数是多少? 如果是并发的问题,请反馈一下grafana的监控,看一下系统的瓶颈在哪里. 采集over-view,tidb, tikv-detail三个面板 ,步骤如下:

(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl (2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。 (3)、使用这个 full-page-screen-capture 插件进行截屏保存

您好: 感谢反馈,但是看这个截图好像没有业务量,看起来duration也在60ms比较正常.
麻烦取一下,你觉得慢的时间段的监控信息. 监控右上角可以设置时间

你好请问 我该从哪个方向下手呢 ,如果是机器不够的话 打算添加机器试试 ,如果是并发或者其他的,要从哪里下手调试呢

  1. 从监控看leader分布不均匀,149和77的leader差的比较多,这两个tikv上的磁盘空间不一样大吗? df -h检查下

  2. 看起来有热点读的问题,你在大概11点左右测试的吧,当时使用的测试sql,都是这一条sql吗? select SUM(t.sum_bill_price) as sumBillPrice from t_bill t left join t_company tc on tc.company_code=t.company_code WHERE 1=1

  3. t_company 和 t_bill 表的数量是多少,有没有哪个表很小?

1.149磁盘较小 120G 77为300G

2.测试sql有两条 这是另一条 SELECT count(0) FROM t_bill t LEFT JOIN t_bill_company tc ON tc.company_code = t.company_code LEFT JOIN t_bill_tobeinvoiced tbt ON tbt.bill_serial_num = t.bill_serial_num 3.t_company 表400条 t_bill 300万条数据

慢日志

SELECT count(0) FROM t_bill t LEFT JOIN t_bill_company tc ON tc.company_code = t.company_code LEFT JOIN t_bill_tobeinvoiced tbt ON tbt.bill_serial_num = t.bill_serial_num 2020-02-21 11:05:20.711449 00:00:01 Process_time: 2.072 Request_count: 7 Total_keys: 3012430 Process_keys: 3012423 1 2 414778476641386498 root@172.18.218.80 michain_enterprise_test [t_bill:t_company_code_bill_serial_num,t_bill_company:companyCode,t_bill_tobeinvoiced:t_b_tobe_t_bill_tobeinvoiced] 0 bdc40366fd81c2e788ecbb6285ff75b3a36bef294d0d29c5373dfe562bd3ecf9

请保证每个tikv上的容量一致,不然会出现当前leader不均衡的情况,大多数查询都落在了77上。 试着先让leader均衡,再试一下.

需要增加一下149的容量对吗? 增加容量后,需要重新插入测试数据吗?

你可以再找一个相同容量的机器,先扩容tikv,再缩容这个容量小的tikv就可以了.