Re: Heads Up: cirrus-ci is shutting down June 1st

Hi,

On 2026-05-29 13:38:17 +0200, Jakub Wartak wrote:
> On Fri, May 29, 2026 at 11:51 AM Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
> [..]
> Hi, thanks to everybody for working on this.
>
> > https://github.com/nbyavuz/postgres/actions/runs/26628396798
>
> Windows (runs-on: windows-2022) seems kind of slow isn't it ?
>
> Maybe that's not related to the patch itself, but any idea why the windows
> tests are so slow? Or will we able to somehow accelerate those?
>
> Windows - VS - Meson & ninja / succeeded [..] minutes ago in 31m 28s
>
> Processor(s): 1 Processor(s) Installed.
> [..]
> Total Physical Memory: 16,379 MB
> [..]
>
> but:
> NUMBER_OF_PROCESSORS=4
> [..]
> + TEST_JOBS: 8
>
> vs
>
> 392/396 test_json_parser - postgresql:test_json_parser/002_inline
> OK 152.56s 3712 subtests passed
> 393/396 pgbench - postgresql:pgbench/001_pgbench_with_server
> OK 574.61s 474 subtests passed
> 394/396 pg_rewind - postgresql:pg_rewind/002_databases
> OK 772.86s 10 subtests passed
> 395/396 pg_waldump - postgresql:pg_waldump/001_basic
> OK 771.19s 156 subtests passed
> 396/396 libpq_pipeline - postgresql:libpq_pipeline/001_libpq_pipeline
> OK 395.76s 23 subtests passed
>
> while last CirrusCI run for me for Windows took 19min 21s (4 CPUs / 4 GBs,
> but sysinfo reported there "Total Physical Memory: 16,380 MB").

The difference here likely is due to the different type of CPU cores. On
cirrus, we got 4 non-SMT cores (because the type of CPU used didn't use SMT),
whereas on GHA we have 4 hardware threads, but only two real cores.

> If that's IO traffic as Andres described, maybe we could enable feature
> called "Turn off Windows write-cache buffer flushing on the device"
> in device manager -> disk -> policies, but dunno how much that would
> help really as we seem to be already using fsync=off, maybe it helps
> when saving other files too (???)

I think I was wrong about IO being the main issue. I've measured the CPU
utilization during a linux run, and basically it's 100% busy during the whole
test run (baring the first and last few seconds). Which does seem to mainly
point to the difference being simply that we just have half the real cores as
we had before.

I do see higher %sys CPU utilization than I'd expect, so that may be worth
investigating.

Greetings,

Andres Freund