@qoega Sorry, but it's totally wrong.

2020-09-02 01:50:38 /bin/sh: 1: 16: not found
2020-09-02 01:50:38 /bin/sh: 1: 16: not found
2020-09-02 01:50:38 /bin/sh: 1: 16: not found
2020-09-02 01:50:38 /bin/sh: 1: 16: not found
2020-09-02 01:50:38 # Fix for ninja. Do not add -O.
2020-09-02 01:50:38 /bin/sh: 1: 16: not found
2020-09-02 01:50:38 /usr/bin/ninja  -C obj-x86_64-linux-gnu clickhouse-bundle

And you forgot to assign yourself and mark the pull request as "Approved" (to indicate that you have reviewed it).

If you can write makefiles, you can help...

This increased our internal build times significantly, to the point where they started breaching 3h timeout. Previous build of v20.7 took just 1h14m.

On a system with 2 x Xeon E5-2630 v3 (32 logical CPUs in total) I see:

• 92m with job-per-logical-cpu (before)
• 100m with job-per-physical-core (after)

Memory usage between two builds, taken at 1m interval:

Seems like there's also some other regression in terms of compilation times:

• Another 256-bit integers (strict 32 bytes) #14229 (comment)

Either way, I don't think Clickhouse build should make assumptions about CPU topology:

• Not all CPUs have hyperthreads (many aarch64, some x86_64)
• VMs may be scheduled across physical CPUs even when there are hyperthreads
• Linux scheduler won't necessarily spread jobs ideally across non-hypertheaded cores

From the log you linked it seems that your build system doesn't have enough memory and compiler/linker gets killed when many copies run at the same time (has and concat are particularly memory hungry functions to compile, 256 bit integer change doesn't help). I suggest bumping memory or maybe adding swap if memory is not an option instead of crippling CPUs.

@bobrik This is just a temporary change to allow CI to run before we optimize the build.
Now the build is optimized and we are changing it back.

PS. We don't control the amount of memory on CI servers. I think, we should assume that they have 128 GiB.