兄弟，我来给你捋捋这个问题——你遇到的Check added_tokens >=0 failed错误是TiFlash准入控制模块的典型问题，结合查询卡壳、存储疯长这俩现象，我给你整理几个靠谱的排查方向和解决建议：

一、先盯紧TiFlash准入控制的配置参数 #

这个错误直接来自LocalAdmissionController模块，说白了就是TiFlash用来管控请求的"令牌"不够用了，先从配置入手：

• 检查admission_control_max_memory_usage参数：这个参数管的是TiFlash给准入控制留的内存阈值，要是节点内存吃紧或者这个值设得太抠，就容易触发错误。K8s环境里你可以通过PD配置中心或者TiFlash的启动参数调大它（比如从默认20%调到30%，具体看你节点内存总量）
• 再看admission_control_queue_size：如果请求队列塞爆了也会出问题，适当调大队列大小试试，给请求多留点儿缓冲空间

二、揪出TiFlash存储疯长的真凶 #

存储持续膨胀大概率和历史版本堆积、快照清理不及时有关：

• 查TiDB的gc_life_time参数：要是GC周期设得太长，TiFlash会攒一堆历史版本占空间。先确认GC是不是正常跑着，有没有被大事务或者未完成的任务卡住
• 排查特定表的存储占用：进TiFlash的data目录看看，是不是某张表的副本占了大半空间？可能是这表突然被疯狂写入，或者TiFlash同步出了问题，导致版本越攒越多
• 检查DDL任务状态：执行ADMIN SHOW DDL看看有没有挂着的DDL任务，要是DDL卡着，GC也没法正常回收旧版本数据

三、排查K8s环境的资源限制坑 #

毕竟是在K8s里跑，节点资源卡脖子也会引发连锁反应：

• 看TiFlash Pod的资源请求和限制：resources.requests和resources.limits要是设得太低，尤其是内存限制不够，TiFlash处理大量查询时直接内存告急，触发准入控制错误
• 检查节点磁盘IO：进容器用iostat看看IO使用率，要是磁盘跑满了，TiFlash读写数据慢不说，还可能因为数据没法及时整理导致存储膨胀
• 确认磁盘空间和性能：看看挂载的磁盘是不是快满了？或者像云盘这类存储的IOPS不够用，拖慢了TiFlash的读写速度

四、检查TiFlash副本的同步状态 #

副本同步出问题也会搞出一堆麻烦：

• 执行SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA查所有表的TiFlash副本状态，看看有没有available不是1的表，或者副本数和你设置的不一致
• 要是有表同步异常，TiFlash会一直重试同步，生成大量临时文件占存储，查询的时候还会因为副本不可用反复重试，导致变慢甚至失败

五、深挖日志和监控找线索 #

除了你给的那条错误日志，再挖挖其他细节：

• 翻TiFlash的error.log，看看有没有内存不足、磁盘IO错误这类相关日志
• 看PD监控，重点关注TiFlash同步进度、GC状态、集群事务情况
• 打开TiFlash的监控面板，盯紧Admission Control相关指标，比如Token Available、Queue Size，看看错误发生时这些指标是不是异常波动

你之前重启过Pod但问题还在，说明不是临时进程抽风，得从配置、资源、数据版本这些根儿上找问题，按上面的方向一步步排查，应该能找到突破口。

内容来源于stack exchange