token-limit连接数控制

【 TiDB 使用环境】线上、测试、调研
【 TiDB 版本】
【遇到的问题】

我将 token-limit设置为3,使用sysbench进行压测,配置的threads=100,在压测期间,观察tidb的连接数就是100,tps也挺高的,感觉这个token-limit没有管控住,查看tidb.log,也没有看到相关连接数报错。

【复现路径】做过哪些操作出现的问题
【问题现象及影响】

【附件】

请提供各个组件的 version 信息,如 cdc/tikv,可通过执行 cdc version/tikv-server --version 获取。

连接数是 max-server-connections控制,这个默认不受限,都可以连接
token-limit是活跃连接数,应该要看这个了

token管的是SQL能不能执行,不是连接数,执行SQL要拿token

那这个方面的监控,从哪里可以看出来。

  • TiDB 中同时允许运行的 Session 数量,用于流量控制
  • 默认:1000
  • 如果当前运行的连接多于该 token-limit,那么请求会阻塞,等待已经完成的操作释放 Token

有的人说这个管的就是并发数,有的说是session数,不明白这个参数到底是干啥用的?

我的sysbench设置的并发数是100,token-limit设置的是3,就算是管token的,我觉得这个并发100也上不去吧,但是我看grafana,一点问题没有。:sweat_smile:

token-limit是这100个线程,只能并发执行3个。你就是开10000个线程,同时执行sql解析、发送kv、收数据的也是3个。从grafana、tidb的面板中间有个token的获取时间,哪里可以看到。如果说你的sql执行的非常快,你也感觉不到变化。就像你pc可能就8核,但是pc上所有进程的线程数上千,为什么感觉不卡呢,就是轮流来啊。

那后台有相关警报信息吗?我在tidb.log里面没有找到。

为什么要报警呢?不会有的啊。sql可以正常执行啊。只不过排队等着。

嗯,明白了,我把这个limit调高,确实get token的时间有明显的变化。qps也有明显的变化。

SQL 在 TiDB 内部的处理分为四个阶段,get token、parse、compile 和 execute。
我想问一下,假设我的token-limit=1,那么一个SQL是经历完上面的四个阶段以后并释放token,下一个排队的SQL才能执行,是这样的吧?

是的,入口处申请的token。其实这个功能我感觉有点鸡肋,如果说不限连接数,只限执行,当并发数来个几千的时候,内存同样占很多,从一堆goroutine中挑3个可以执行的也是挺费劲的。反正我试过这个,不好使。还是限连接数好使,能处理多少线程就允许多少线程就行了。前面的代理设置 最少链接优先,就是说如果10个tidb节点,前面的代理不要设置轮询,设置挑10个节点中连接最少的一个。这样就比较均衡了。轮询的话慢慢就不均衡了。

这个参数终于搞懂了,以前稀里糊涂的。谢谢!

那你们的环境里面,token-limit配置了多少呀,还是默认的1000吗?

默认值