This test creates too much threads (1500), and sometimes there are some
stalls on arm64 [1]:
2024.10.07 21:06:38.768974 [ 4479 ] {3041e49a-89c3-4991-a59f-6ae221a5afd0} <Debug> executeQuery: (from [::1]:52210) (comment: 00913_many_threads.sql) SELECT count() FROM t; (stage: Complete)
...
2024.10.07 21:07:37.028725 [ 15271 ] {3041e49a-89c3-4991-a59f-6ae221a5afd0} <Trace> AggregatingTransform: Aggregated. 1 to 1 rows (from 0.00 B) in 58.247881431 sec. (0.017 rows/sec., 0.00 B/sec.)
2024.10.07 21:11:20.662232 [ 15270 ] {3041e49a-89c3-4991-a59f-6ae221a5afd0} <Trace> AggregatingTransform: Aggregating
...
As you can see there are zero logs for almost 4 minutes, and trace_log
contains zero records for the interval event_time between '2024.10.07
21:07:37' and '2024.10.07 21:11:20'.
[1]: https://s3.amazonaws.com/clickhouse-test-reports/70448/cd826389e90065466ddfef140fc344b30e8c6de0/stateless_tests__aarch64_.html
At first I thought about adding some new metrics like
GlobalThreadPoolThreadSlowCreationMicroseconds, but it will unlikely
help with understading the root cause.
Then I thought about exposing CPU steal metric, but the problem is that
AWS uses Nitro instead of Xen for this instances (r6g.2xlarge), and
Nitro does not expose this metric.
So let's just disable parallel execution of this test to stabilize the
CI.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
