2021-09-19 22:38:53 +00:00
|
|
|
<clickhouse>
|
2020-02-25 13:12:12 +00:00
|
|
|
<profiles>
|
|
|
|
|
<default>
|
|
|
|
|
<allow_introspection_functions>1</allow_introspection_functions>
|
|
|
|
|
<log_queries>1</log_queries>
|
2023-08-07 21:25:16 +00:00
|
|
|
<metrics_perf_events_enabled>0</metrics_perf_events_enabled>
|
2020-08-19 15:08:23 +00:00
|
|
|
<!--
|
|
|
|
|
If a test takes too long by mistake, the entire test task can
|
|
|
|
|
time out and the author won't get a proper message. Put some cap
|
|
|
|
|
on query execution time to prevent this. Test query run time is
|
|
|
|
|
limited to about 2 seconds, but this limit applies to all queries,
|
|
|
|
|
including fill/create and maintenance such as downloading trace
|
|
|
|
|
logs, so it must be generous enough. As a second line of defense,
|
|
|
|
|
we might also add time check to perf.py script.
|
|
|
|
|
-->
|
|
|
|
|
<max_execution_time>300</max_execution_time>
|
2020-10-19 14:39:52 +00:00
|
|
|
|
|
|
|
|
<!-- One NUMA node w/o hyperthreading -->
|
2020-11-09 16:14:05 +00:00
|
|
|
<max_threads>12</max_threads>
|
Disable min_bytes_to_use_mmap_io by default
Reading files using mmap() does not have any significant benefits over
plain read() [1].
[1]: https://gist.github.com/azat/3d6c8d82bdd91e7a38d997fd6bcfd574
And not only it does not have significant benefits, it also has some
issues, due to max_server_memory_usage (default to 90% of available
RAM), since when you read files with mmap() eventually process RSS may
exceed max_server_memory_usage, and in this case any allocation will
fail (with "Memory limit exceeded (total)") error (yes kernel will
unload pages, but likely it will happens after queries will starting to
fail), like in this test [2].
[2]: https://gist.github.com/azat/4813489828162e6c2ce131963c6a1acb
TL;DR;
Note that there was also an idea to take those mmap()'ed regions in
memory tracking (#23211), but there are some drawbacks (since accounting
mmap() is tricky, first of all you need to account only once per inode
for file and plus kernel can unload some pages and those memory will not
be used by the server anymore).
And as an adddition to #23211 there was #23212, that adds
max_bytes_to_use_mmap_io, but since mmap is not a subject for memory
accounting there is no need in it.
2021-04-19 21:11:03 +00:00
|
|
|
|
2021-09-25 17:00:55 +00:00
|
|
|
<!-- disable JIT for perf tests -->
|
2023-08-19 14:38:14 +00:00
|
|
|
<compile_expressions>1</compile_expressions>
|
|
|
|
|
<compile_aggregate_expressions>1</compile_aggregate_expressions>
|
|
|
|
|
<compile_sort_description>1</compile_sort_description>
|
2021-09-25 17:00:55 +00:00
|
|
|
|
|
|
|
|
<!-- Don't fail some prewarm queries too early -->
|
|
|
|
|
<timeout_before_checking_execution_speed>60</timeout_before_checking_execution_speed>
|
2021-10-27 20:11:38 +00:00
|
|
|
|
|
|
|
|
<!-- Query profiler enabled only for prewarm queries explicitly (see perf.py)
|
|
|
|
|
This is needed for flamegraphs. -->
|
|
|
|
|
<query_profiler_real_time_period_ns>0</query_profiler_real_time_period_ns>
|
|
|
|
|
<query_profiler_cpu_time_period_ns>0</query_profiler_cpu_time_period_ns>
|
|
|
|
|
<!-- Disable memory profiler too, since due to max_untracked_memory some queries may add trace entry and some may not -->
|
|
|
|
|
<memory_profiler_step>0</memory_profiler_step>
|
2020-02-25 13:12:12 +00:00
|
|
|
</default>
|
|
|
|
|
</profiles>
|
2021-03-03 10:42:44 +00:00
|
|
|
<users>
|
|
|
|
|
<default>
|
|
|
|
|
<access_management>1</access_management>
|
|
|
|
|
</default>
|
|
|
|
|
</users>
|
2021-09-19 22:38:53 +00:00
|
|
|
</clickhouse>
|