1. Dropped support for DatabaseOrdinary for MaterializeMySQL. It
is marked as experimental, and dropping support makes the code
more maintaible, and speeds up integration tests by 50%.
2. Get rid of thread name logic for StorageMaterializeMySQL wrapping,
use setInternalQuery instead (similar to MaterializedPostgreSQL).
Only query profiler cannot work reliably with sanitizers (due to
unwinding from signal handler), but memory profiler should be fine.
Plus sometimes the problem appears only on build with sanitizers, so it
will be useful to have memory related profiling in trace_log.
Also there is a flaky check for stateless tests, that uses build with
ASan, and now trace_log there is empty, which sometimes does not allow
to debug further.
Right now to configure memory_profiler_step/total_memory_profiler_step
you need to call:
MemoryTracker::setOrRaiseProfilerLimit()
MemoryTracker::setProfilerStep()
But it is easy to forget about setOrRaiseProfilerLimit(), since there is
no even any comments about this.
So instead, make setOrRaiseProfilerLimit() private and call it from
setProfilerStep()
It was 64 for a long time, and even linux kernel never has such a small
limit, it had 128 (net.core.somaxconn sysctl).
But recently, in 5.4, the default value had been increased even in
linux kernel, to 4096 [1].
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4
Let's increase it in ClickHouse too.
Also note, that I've looked through some instances with
clickhouse-server only, and TcpExtListenOverflows was non zero (`nstat
-za`), in other words backlog of the listen socket indeed overflowed
there.
So it is better to increase the default to move the problem to
clickhouse-server itself (yes you will unlikely have 4K new incomming
connections at one time, with accept thread do not accept them all, but
still seems that it is possible, maybe due to some locks or something
else).
vdimir