# Limit Parameters (Continue...)

+ Speed limit - **`store limit`** 
  + Definition: Limit the consumption rate of a single store
  + Command line: **`pd-ctl -u ip:port store limit {id} {value}`**
  + **`store limit`** limits the speed of operator ***consumption***, while the other limit settings are for ***producing***
-----------------------------------------------------------------------------------------------------------------------------
After the introduction of the store limit mechanism, we provide a way to limit the consumption speed of a single store.

Store Limit implements store-level speed limits by maintaining a store ID to a token bucket mapping in memory. The different operations here correspond to different token bucket. Currently, it is only supported to limit the speed of adding learner/peer and deleting peers, that is, two types of token bucket exist in each store.

Each time an operator is spawned, it checks to see if there are enough tokens in the token bucket corresponding to the included operation. If the token is sufficient, the operator will be added to the scheduling queue, and the corresponding token will be removed from the token bucket, otherwise the operator will be discarded. The token bucket replenishes the token at a fixed rate to implement the purpose of limiting the speed.

Store Limit differs from PD other limit related parameters (such as region-schedule-limit, leader-schedule-limit, etc.), that the Store Limit limit is mainly the consumption speed of the operator, while the other limits are mainly Limits the speed at which operators are generated. Prior to the introduction of the Store Limit feature, the speed limit for scheduling was mainly global, so even if the global speed was limited, it was possible that scheduling was concentrated on some stores, thus affecting the performance of the cluster. By further refining the granularity of the speed limit, Store Limit can better control the scheduling behavior.