# Performance (C)
+ `force-priority`
  + Control tidb-server priority. When It is set, all the requests will be executed by this priority.
![center](./student-guide/diagram/06-performance-03-01.png)
-------------------------------------------------------------
Performance
- max-procs
  - Control the number of CPU cores used by tidb-server. Deploying multiple tidb-servers on a single machine Set this variable to limitation the resources used by tidb-server to avoid affecting other processes
  - It is recommended to deploy n TiDB (n = the number of NUMA CPUs) on the NUMA schema server, and set the value of the max-procs variable of TiDB to the same number of cores as the NUMA CPU.
  - This parameter controls the number of CPU cores that can be used by the entire Go process. By default, the number of CPUs of the current machine or cgroups. The Go runtime regularly uses a percentage of thread for background work such as GC. In hybrid deployment mode, if you do not limitation this parameter, background operations such as GC can consume too much CPU resources.
- token-limit
  - Configure the number of sessions that can execute request at the same time for traffic flow control to avoid tidb-server resource exhaustion due to excessive number of concurrent request, and service failure to respond
  - Default: 1000
  - If there are more connections currently running than the token-limit, the request will block, waiting for the completed operation to release the token
If you increase the token-limit to 3000, then the number of connections running at the same time will be 3000, so the impact to consider is whether many of these sessions will put a lot of pressure on tidb-server and tikv-server.
You can view the current monitoring system resources, over-view, if the peak business period, the system resource consumption is very low, then there should be no problem to increase the token-limit, if the peak time period, the system load is already high, and the service latency is also relatively high, then it is recommended to try not to adjust, or you can try to lower it first.
- force-priority
  - Control the priority of the tidb-server. Once set, all request will be executed using that priority. A common scenario is to configure a separate tidb-server to set a low priority and execute AP request.
Default: NO_PRIORITY
The statement priorities supported by TiDB include NO_PRIORITY, LOW_PRIORITY, DELAYED, and HIGH_PRIORITY.
scenario 1: If you need to specify a dedicated server pool for OLAP query, you can set this value to LOW_PRIORITY to ensure that the TiKV server prioritizes OLTP request received by other TiDB server pools. This allows OLTP performance to be more stable, but OLAP performance may decrease slightly.
scenario 2: TiDB automatically sets the table scan to LOW_PRIORITY. By setting the DML modifier to HIGH PRIORITY or LOW PRIORITY, you can override the priority of a statement.
scenario 3: Database low-speed export configuration —params “tidb-force-priority=low_priority, tidb_distsql_scan_concurrency=5" can lower the execution priority of export statement and reduce the concurrency of scan data during TiDB export, so as to implementation Slow-speed backup data with low database impact.
- committer-concurrency
  - Controls the maximum number of concurrency for the commit phase of a transaction. For a large transaction, committing a transaction requires sending a large number of write request to TiKV. Setting up a larger concurrency may allow large transaction to be committed faster, but it can also cause the TiKV to become overwhelmed by instantaneous stress, and request pile up and become unresponsive.