Server Settings

Note

We recommend not changing this if you have just started using ClickHouse.

**Configuration template**:

```
<compression>
    <case>
      <min_part_size>...</min_part_size>
      <min_part_size_ratio>...</min_part_size_ratio>
      <method>...</method>
      <level>...</level>
    </case>
    ...
</compression>
```

**`<case>` fields**:

- `min_part_size` – The minimum size of a data part.
- `min_part_size_ratio` – The ratio of the data part size to the table size.
- `method` – Compression method. Acceptable values: `lz4`, `lz4hc`, `zstd`,`deflate_qpl`.
- `level` – Compression level. See [Codecs](/docs/sql-reference/statements/create/table#general-purpose-codecs).

Note

You can configure multiple `<case>` sections.

**Actions when conditions are met**:

- If a data part matches a condition set, ClickHouse uses the specified compression method.
- If a data part matches multiple condition sets, ClickHouse uses the first matched condition set.

Note

If no conditions are met for a data part, ClickHouse uses the `lz4` compression.

**Example**

```
<compression incl="clickhouse_compression">
    <case>
        <min_part_size>10000000000</min_part_size>
        <min_part_size_ratio>0.01</min_part_size_ratio>
        <method>zstd</method>
        <level>1</level>
    </case>
</compression>
```

## concurrent\_threads\_scheduler[​](#concurrent_threads_scheduler "Direct link to concurrent_threads_scheduler")

The policy on how to perform a scheduling of CPU slots specified by `concurrent_threads_soft_limit_num` and `concurrent_threads_soft_limit_ratio_to_cores`. Algorithm used to govern how limited number of CPU slots are distributed among concurrent queries. Scheduler may be changed at runtime without server restart.

Possible values:

- `round_robin` — Every query with setting `use_concurrency_control` = 1 allocates up to `max_threads` CPU slots. One slot per thread. On contention CPU slot are granted to queries using round-robin. Note that the first slot is granted unconditionally, which could lead to unfairness and increased latency of queries having high `max_threads` in presence of high number of queries with `max_threads` = 1.
- `fair_round_robin` — Every query with setting `use_concurrency_control` = 1 allocates up to `max_threads - 1` CPU slots. Variation of `round_robin` that does not require a CPU slot for the first thread of every query. This way queries having `max_threads` = 1 do not require any slot and could not unfairly allocate all slots. There are no slots granted unconditionally.
- `max_min_fair` — Every query with setting `use_concurrency_control` = 1 allocates up to `max_threads - 1` CPU slots. Similar to `fair_round_robin`, but released slots are always granted to the query with the minimum number of currently allocated slots. This provides better fairness under high oversubscription, where many queries compete for limited CPU slots. Short-running queries are not penalized by long-running queries that have accumulated more slots over time.

## concurrent\_threads\_soft\_limit\_num[​](#concurrent_threads_soft_limit_num "Direct link to concurrent_threads_soft_limit_num")

The maximum number of query processing threads, excluding threads for retrieving data from remote servers, allowed to run all queries. This is not a hard limit. In case if the limit is reached the query will still get at least one thread to run. Query can upscale to desired number of threads during execution if more threads become available.

Note

A value of `0` (default) means unlimited.

## concurrent\_threads\_soft\_limit\_ratio\_to\_cores[​](#concurrent_threads_soft_limit_ratio_to_cores "Direct link to concurrent_threads_soft_limit_ratio_to_cores")

Same as [`concurrent_threads_soft_limit_num`](#concurrent_threads_soft_limit_num), but with ratio to cores.

## config-file[​](#config-file "Direct link to config-file")

Points to the server config file.

## config\_reload\_interval\_ms[​](#config_reload_interval_ms "Direct link to config_reload_interval_ms")

How often clickhouse will reload config and check for new changes

## core\_dump[​](#core_dump "Direct link to core_dump")

Configures soft limit for core dump file size.

Note

Hard limit is configured via system tools

**Example**

```
<core_dump>
     <size_limit>1073741824</size_limit>
</core_dump>
```

## cpu\_slot\_preemption[​](#cpu_slot_preemption "Direct link to cpu_slot_preemption")

Defines how workload scheduling for CPU resources (MASTER THREAD and WORKER THREAD) is done.

- If `true` (default), accounting is done based on actual CPU time consumed. A fair number of CPU time would be allocated to competing workloads. Slots are allocated for a limited amount of time and re-requested after expiry. Slot requesting may block thread execution in case of CPU resource overload, i.e., preemption may happen. This ensures CPU-time fairness.
- If `false`, accounting is based on the number of CPU slots allocated. A fair number of CPU slots would be allocated to competing workloads. A slot is allocated when a thread starts, held continuously, and released when the thread ends execution. The number of threads allocated for query execution may only increase from 1 to `max_threads` and never decrease. This is more favorable to long-running queries and may lead to CPU starvation of short queries.

**Example**

```
<cpu_slot_preemption>true</cpu_slot_preemption>
```

**See Also**

- [Workload Scheduling](/docs/operations/workload-scheduling)

## cpu\_slot\_preemption\_timeout\_ms[​](#cpu_slot_preemption_timeout_ms "Direct link to cpu_slot_preemption_timeout_ms")

It defines how many milliseconds could a worker thread wait during preemption, i.e. while waiting for another CPU slot to be granted. After this timeout, if thread was unable to acquire a new CPU slot it will exit and the query is scaled down to a lower number of concurrently executing threads dynamically. Note that master thread never downscaled, but could be preempted indefinitely. Makes sense only when `cpu_slot_preemption` is enabled and CPU resource is defined for WORKER THREAD.

**Example**

```
<cpu_slot_preemption_timeout_ms>1000</cpu_slot_preemption_timeout_ms>
```

**See Also**

- [Workload Scheduling](/docs/operations/workload-scheduling)

## cpu\_slot\_quantum\_ns[​](#cpu_slot_quantum_ns "Direct link to cpu_slot_quantum_ns")

It defines how many CPU nanoseconds a thread is allowed to consume after acquired a CPU slot and before it should request another CPU slot. Makes sense only if `cpu_slot_preemption` is enabled and CPU resource is defined for MASTER THREAD or WORKER THREAD.

**Example**

```
<cpu_slot_quantum_ns>10000000</cpu_slot_quantum_ns>
```

**See Also**

- [Workload Scheduling](/docs/operations/workload-scheduling)

## crash\_log[​](#crash_log "Direct link to crash_log")

Settings for the [crash\_log](/docs/operations/system-tables/crash_log) system table operation.

The following settings can be configured by sub-tags: