搭出来的Tidb集群读性能差,cpu、内存、磁盘利用率都非常低

集群拓扑

资源利用情况:



诊断结果:

测试命令是
sysbench --config-file=config1 oltp_point_select --tables=5 --table-size=100000000 --threads=64 run

感觉基本上资源都没有利用起来,不知道是哪个环节出了问题 :sob:

sysbench 服务器 cpu 使用率多少,config 可以配置多个 ip 的,不要通过负载均衡。
如果 sysbench、负载均衡 数据库都没有瓶颈,就加压。64 不够就加到 256

sysbench服务器的cpu远远没跑满,加压也没有带来性能的提升

还有你这个集群部署的不是很合理,为啥 tikv 是两个服务器,有一个还是双实例。

因为只找到了俩高性能硬盘 :joy:

哈哈 一看就是紧巴巴凑出来的服务器。

发下 overview 的 cpu 内存截图,先看下服务器的cpu 内存 io 情况

2Tikv服务器

Tikv+Tidb服务器

Tidb+PD服务器

感觉都远远不到瓶颈 :dotted_line_face:

这样测得的结果point_select的QPS只有3w+

无法理解,难道是做了什么配置?
发下 tiup cluster config-show 的内容,看看配置是否预期捏

global:
  user: tidb
  ssh_port: 22
  ssh_type: builtin
  deploy_dir: /data/tidb-deploy
  data_dir: /data/tidb-data
  os: linux
  arch: arm64
monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115
  deploy_dir: /data/tidb-deploy/monitor-9100
  data_dir: /data/tidb-data/monitor-9100
  log_dir: /data/tidb-deploy/monitor-9100/log
server_configs:
  tidb:
    log.level: error
    performance.max-procs: 32
    performance.run-auto-analyze: false
    performance.txn-total-size-limit: 10485760000
    prepared-plan-cache.enabled: true
    token-limit: 3001
  tikv:
    coprocessor.split-region-on-table: false
    log-level: error
    raftdb.max-background-jobs: 16
    raftstore.apply-max-batch-size: 1024
    raftstore.apply-pool-size: 3
    raftstore.hibernate-regions: true
    raftstore.raft-max-inflight-msgs: 1024
    raftstore.store-max-batch-size: 1024
    raftstore.store-pool-size: 8
    rocksdb.compaction-readahead-size: 2M
    rocksdb.defaultcf.max-write-buffer-number: 32
    rocksdb.writecf.max-write-buffer-number: 32
    server.grpc-concurrency: 5
    server.max-grpc-send-msg-len: 5242880
    storage.block-cache.capacity: 64G
    storage.reserve-space: 0MB
    storage.scheduler-worker-pool-size: 8
  pd:
    replication.location-labels:
    - zone
    - host
  tidb_dashboard: {}
  tiflash: {}
  tiflash-learner: {}
  pump: {}
  drainer: {}
  cdc: {}
  kvcdc: {}
  grafana: {}
tidb_servers:
- host: 10.10.12.9
  ssh_port: 22
  port: 4000
  status_port: 10080
  deploy_dir: /data/tidb-deploy/tidb-4000
  log_dir: /data/tidb-deploy/tidb-4000/log
  numa_node: "0"
  arch: arm64
  os: linux
- host: 10.10.12.78
  ssh_port: 22
  port: 4000
  status_port: 10080
  deploy_dir: /data/tidb-deploy/tidb-4000
  log_dir: /data/tidb-deploy/tidb-4000/log
  numa_node: "1"
  arch: arm64
  os: linux
tikv_servers:
- host: 10.10.12.78
  ssh_port: 22
  port: 20160
  status_port: 20180
  deploy_dir: /data/tidb-deploy/tikv-20160
  data_dir: /data/tidb-data/tikv-20160
  log_dir: /data/tidb-deploy/tikv-20160/log
  numa_node: "0"
  config:
    server.labels:
      host: h1
      zone: z0
  arch: arm64
  os: linux
- host: 10.10.12.6
  ssh_port: 22
  port: 20160
  status_port: 20180
  deploy_dir: /data/tidb-deploy/tikv-20160
  data_dir: /data/tidb-data/tikv-20160
  log_dir: /data/tidb-deploy/tikv-20160/log
  numa_node: "0"
  config:
    server.labels:
      host: h2
      zone: z0
  arch: arm64
  os: linux
- host: 10.10.12.6
  ssh_port: 22
  port: 20161
  status_port: 20181
  deploy_dir: /data/tidb-deploy/tikv-20161
  data_dir: /data/tidb-data/tikv-20161
  log_dir: /data/tidb-deploy/tikv-20161/log
  numa_node: "1"
  config:
    server.labels:
      host: h2
      zone: z1
  arch: arm64
  os: linux
tiflash_servers: []
pd_servers:
- host: 10.10.12.9
  ssh_port: 22
  name: pd-10.10.12.9-2379
  client_port: 2379
  peer_port: 2380
  deploy_dir: /data/tidb-deploy/pd-2379
  data_dir: /data/tidb-data/pd-2379
  log_dir: /data/tidb-deploy/pd-2379/log
  numa_node: "1"
  arch: arm64
  os: linux
monitoring_servers:
- host: 10.10.12.9
  ssh_port: 22
  port: 9090
  deploy_dir: /data/tidb-deploy/prometheus-9090
  data_dir: /data/tidb-data/prometheus-9090
  log_dir: /data/tidb-deploy/prometheus-9090/log
  external_alertmanagers: []
  arch: arm64
  os: linux
grafana_servers:
- host: 10.10.12.9
  ssh_port: 22
  port: 3000
  deploy_dir: /data/tidb-deploy/grafana-3000
  arch: arm64
  os: linux
  username: admin
  password: admin
  anonymous_enable: false
  root_url: ""
  domain: ""
alertmanager_servers:
- host: 10.10.12.9
  ssh_port: 22
  web_port: 9093
  cluster_port: 9094
  deploy_dir: /data/tidb-deploy/alertmanager-9093
  data_dir: /data/tidb-data/alertmanager-9093
  log_dir: /data/tidb-deploy/alertmanager-9093/log
  arch: arm64
  os: linux
  1. tikv 能不要改配置就不要改
  2. 我看了 tidb 做了绑核,而且就绑了 1 哥 node,你服务器是 lscpu 能看到几个 node ? 每个服务器多少 cpu 呢

就是Tikv直接用默认的配置吗,一台服务器是2 node,每个node 40cores。
印象里看文档的时候有一些配置应该是需要改的,因为我把俩tikv实例放一个服务器上了 :joy:

嗯 如果是 2node,每个 node 40vc,那绑核代表着对应的组件可以用到 40vc

你就光配置个 tikv 多实例部署需要配置的参数即可。也就是内存、cpu、capacity 就够了。其他参数去掉吧。

cpu 主要需要配哪几项的呢,感觉里面涉及线程数的参数还是比较多的

https://docs.pingcap.com/zh/tidb/v5.0/hybrid-deployment-topology 这个

okk 我试试,感谢!!

一通操作QPS还是没什么变化

几项资源感觉还是没用起来,好奇怪 :disappointed_relieved:

server_configs:
  tidb:
    log.level: error
    performance.run-auto-analyze: false
    performance.txn-total-size-limit: 10485760000
    prepared-plan-cache.enabled: true
    token-limit: 6000
  tikv:
    #coprocessor.split-region-on-table: false
    log-level: error
    raftstore.capacity: 1000GB
    readpool.coprocessor.use-unified-pool: true
    readpool.storage.use-unified-pool: true
    readpool.unified.max-thread-count: 32
    storage.block-cache.capacity: 64G
    storage.block-cache.shared: true
  pd:
    replication.location-labels:
    - zone
    - host

配置文件应该是没啥大问题了吧

顺便还想确认一下,有没有可能就是这样的拓扑结构导致的,但我觉得不至于影响这么大吧 :rofl:实在不行我再去弄一块盘来试试

服务器不给力

1 个赞

你的机器是arm的,arm本身就是比较弱 :crazy_face:
绑核要绑好
跑跑压测,看看numastate,有多少跨node访问的内存。
把这些问题解决,调调线程池,arm机器对应的优化有一大批动作,大概就是原来一个线程就能干的活,可能现在得多几个线程搞。否则就是瓶颈。

1 个赞

不合理 理论上没有发现明显瓶颈的时候 加并发 cpu 肯定能上去的