AskTUG Weekly (20191028-20191103):TiDB 单线程 Insert 慢如何解决?大数据量分页查询速度慢如何调优?

Q1: 【TiDB】10 月 29 号晚上,开发在 TiDB 的线上运行了几次有关于 sum 的操作,导致 CPU 直线飙升。首先需要承认的是,他们的这种做法欠妥当。在第一次没运行完 SQL 的前提下,又执行了几次。后来接到了 Zabbix 告警后(CPU 超出设定的阈值),用 kill tidb XXX 进程的方式将 SQL 的进程给 KILL 掉。现在已经过去很久,CPU 利用率真还是一直没有下降的趋势。如图:

请问这个现象该如何排查以及解决。查看详情:tidb-server 的 CPU 居高不下

Q2:【TiDB】集群节点分布:pd/kv/db:55 pd/kv/db:56 pd/kv/db:57,三台服务器都是 8 个 CPU,其中 56,57 两个节点的 load【1m】经常处于 8 以上,而 55 这台服务器负载在 3左右。下面是 Grafana 的监控指标:

show processlist 没有复杂的 SQL 在跑,请问这种问题该如何排查呢?查看详情:TiDB 各个节点的负载不一致

Q3:【TiDB】TiDB 版本 3.0.1,单线程插入速度只有每秒 15 条左右(表只有 2 个字段),20 线程测试,CPU,内存,IO 和网络没有什么压力,量也能上去,为什么单线程会很慢?

查看详情:TiDB 单线程 Insert 很慢

Q4:【TiDB】TiDB 版本 3.0.5,数据量 700W,做分页查询 LIMIT 0, 100LIMIT 6000000, 100 查询效率的区别,发现大数据分页查询会越来越慢,如何调优

Q5:【Tools】请问 TiDB 的 Drainer Binlog 的过期时间需要怎么配置,没有看到 TiDB 相关配置的参数。查看详情:请问 TiDB 的 Drainer Binlog 的过期时间需要怎么配置?

Q6:【系统优化】单表 500W 数据量,通过索引查询数据有 100万 左右,耗时 7S 左右。

1、第一次使用 classid 索引进行查询,速度在 8s 左右,

2、通过添加复合索引idx_2(classid,paperAuditstatus,paperAvlstatus,paperPublicstatus,paperDelstatus)速度提升了 1 秒

3、请问针对提取的数据量比较多,如何优化?查看详情:单表提取数据量较大,如何优化

Q7:【DM】我的需求:把一个 MySQL 库下面的所有表实时同步到 TiDB 中,比如现在是 4 张表(后面可能随时增加),我通过 dm-portal 生成 task 配置里面是写死表名了,如果 MySQL 里面加了表不能自动配置,有正则方式全部匹配嘛?查看详情:DM 如何生成同步一个库的所有表的 task.任务

Q8:【TiDB】部署目标机器数据盘请格式化成 EXT4 文件系统,挂载时请添加 nodelalloc 和 noatime 挂载参数。 nodelalloc 是必选参数,否则 Ansible 安装时检测无法通过,noatime 是可选建议参数。我的问题是:

1:如果目标机器硬盘不是 EXT4 的可以部署么,可以用么?

2:如果硬盘不是 SSD 的可以部署么?查看详情:部署 TiDB 时如果目标机器数据盘不是EXT4 可以么

活动

10 月华南 TUG 把“不同业务场景下的数据库技术选型思路”的话题带到了深圳,在 Shopee 办公室和大家聊聊数据库选型那些事儿

活动一共给大家带来了三个分享:

  • 来自 Shopee 的 DBA 刘春辉和洪超分享了“Shopee 的数据库技术选型思路”及 TiDB 在 Shopee 的运维实践;
  • 网易互娱高级 DBA 李文杰为大家分享了网易互娱的业务架构现状、TiDB 技术选型、TiDB 最佳实践;
  • PingCAP 的互联网架构师李坤为大家介绍了分库分表、高可用/数据强一致场景、高写入场景等使用 TiDB 的常用场景。

文章

  1. 随着部门业务量的激增,单机 MySQL 在容量、性能、扩展性等方面都遇到了瓶颈,网易互娱计费组开始对其他数据库产品进行调研选型。网易互娱的数据库选型和 TiDB 应用实践详细介绍了
  • 网易互娱计费组针对自己场景的数据库选型对比方案;

  • 使用 TiDB 后解决的问题,

  • 使用 TiDB 过程中集群管理、监控和数据迁移等方面的最佳实践。

    TiDB 兼容 MySQL 协议,支持 TP/AP 事务且扩展性好,能很好地解决网易互娱计费组业务大容量、高可用等问题。目前网易互娱计费组的业务也在不断深入和扩大规模使用 TiDB。

  1. 在 TiDB 的架构中,所有的数据按照 range 划分成一个个 Region 分布在多个 TiKV 实例上。随着数据的写入,一个集群中会产生上百万,甚至千万个 Region。而量变引起质变,单 TiKV 实例上过多的 Region 无疑会带来比较大的负担,进而影响整个集群的性能表现。TiDB 最佳实践之海量 Region 集群调优介绍了 TiKV 核心模块 Raftstore 的处理流程以使大家更好得理解海量 Region 导致性能问题的根源,以及针对这种情况的一些优化手段

  2. 丰巢第一次在生产环境实际使用 TiDB,是在 2018 年,其场景是每天产生一亿条以上数据的推送平台。这次因为实际的项目需要,丰巢选择了 QPS 和数据一致性要求更高的支付平台,作为第二个迁移到 TiDB 上的项目。TiDB 在丰巢核心支付平台百亿级数据的深度实践详细介绍了迁移过程中的:

  • 标准步骤;
  • 数据同步方案;
  • 流量回放方案;
  • 灰度发布方案;
  • 快速回滚方案;
  • 迁移过程中的坑。

老房说数

上周“老房说数”栏目老房与大家聊了聊大家在面对新数据库,是如何快速学习 trouble shooting 能力的。在与大家的互动中老房还分享了 TiDB performance map,不可错过。


相关阅读

AskTUG Weekly (20191021-20191027)

1赞