public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind
Date: Mon, 16 Sep 2024 13:34:04 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>



On 9/15/24 21:47, Tomas Vondra wrote:
> On 9/15/24 20:31, Tom Lane wrote:
>> Tomas Vondra <[email protected]> writes:
>>> [ 002_pg_upgrade and 027_stream_regress are slow ]
>>
>>> I don't have a great idea how to speed up these tests, unfortunately.
>>> But one of the problems is that all the TAP tests run serially - one
>>> after each other. Could we instead run them in parallel? The tests setup
>>> their "private" clusters anyway, right?
>>
>> But there's parallelism within those two tests already, or I would
>> hope so at least.  If you run them in parallel then you are probably
>> causing 40 backends instead of 20 to be running at once (plus 40
>> valgrind instances).  Maybe you have a machine beefy enough to make
>> that useful, but I don't.
>>
> 
> I did look into that for both tests, albeit not very thoroughly, and
> most of the time there were only 1-2 valgrind processes using CPU. The
> stream_regress seems more aggressive, but even for that the CPU spikes
> are short, and the machine could easily do something else in parallel.
> 
> I'll try to do better analysis and some charts to visualize this ...

I see there's already a discussion about how to make these tests cheaper
by running only a subset of the regression tests, but here are two
charts showing how many processes and CPU usage for the two tests (under
valgrind). In both cases there are occasional spikes with >10 backends,
and high CPU usage, but most of the time it's only 1-2 processes, using
1-2 cores.

In fact, the two charts are almost exactly the same - which is somewhat
expected, considering the expensive part is running regression tests,
and that's the same for both.

But doesn't this also mean we might speed up check-world by reordering
the tests a bit? The low-usage parts happen because one of the tests in
a group takes much longer, so what if moved those slow tests into a
group on their own?

regards

-- 
Tomas Vondra


Attachments:

  [image/png] 027_stream_regress.png (53.3K, ../[email protected]/2-027_stream_regress.png)
  download | view image

  [image/png] 002_pg_upgrade.pl.png (47.4K, ../[email protected]/3-002_pg_upgrade.pl.png)
  download | view image

view thread (7+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: how to speed up 002_pg_upgrade.pl and 025_stream_regress.pl under valgrind
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox