单次查询表数据太大超过1G触发了oom

tidb,tikv对于task的请求属于生产者消费者模式。tidb是消费者，tikv是生产者。当tidb消费的慢（客户端获取数据慢）的时候那么会容易在tidb端的缓冲区积压导致tidb容易oom，当tidb消费的快，但是grpc网络慢的时候理论上容易在tikv端形成积压导致tikv容易oom。对于单表全表查询，当tidb客户端获取数据很快时候一般不会太大问题。还有两个地方需要注意：1、region的分裂，如果region分裂不及时导致region很大，那么可能会导致oom，所以region过大后分裂很重要；2、tidb_enable_rate_limit_action这个参数控制当cop_tak并发请求队列缓存数据过大时导致内存上线超过当前session的内存使用量后会优先触发流控，每执行完一次cop_task则判断一次，如果内存使用超过tidb_mem_quota_query那么当前并发数-1，这里会带来一个潜在问题，也就是流控的优先级高于cancel的优先级，导致最后无法流控后才会被杀掉，看到的现象就是内存超过很多了还没有被杀掉，这个情况下当并发session多可能导致tidb-server整体oom，因此建议将tidb_enable_rate_limit_action设置为OFF，来让cancel动作更及时。