【 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
那这个方面的监控，从哪里可以看出来。
有的人说这个管的就是并发数，有的说是session数，不明白这个参数到底是干啥用的？
我的sysbench设置的并发数是100，token-limit设置的是3，就算是管token的，我觉得这个并发100也上不去吧，但是我看grafana，一点问题没有。
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吗？
默认值
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。