Re: Reducing buildfarm disk usage: remove temp installs when done

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Reducing buildfarm disk usage: remove temp installs when done
Date: 2015-01-19 04:10:27
Message-ID: 54BC83B3.5030305@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: buildfarm-members pgsql-hackers


On 01/18/2015 09:20 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 01/18/2015 05:48 PM, Tom Lane wrote:
>>> One of the biggest causes of buildfarm run failures is "out of disk
>>> space". That's not just because people are running buildfarm critters
>>> on small slow machines; it's because "make check-world" is an enormous
>>> space hog. Some numbers from current HEAD:
>> I don't have an issue, but you should be aware that the buildfarm
>> doesn't in fact run "make check-world", and it doesn't to a test install
>> for each contrib module, since it runs "installcheck", not "check" for
>> those. It also cleans up some data directories as it goes.
> Darn. I knew that it didn't use check-world per se, but I'd supposed
> it was doing something morally equivalent. But I checked just now and
> didn't see the space consumption of the pgsql.build + inst trees going
> much above about 750MB, so it's clearly not as bad as "make check-world".
>
> I think the patch I proposed is still worthwhile though, because it
> looks like the buildfarm is doing this on a case-by-case basis and
> missing some cases: I see the tmp_check directories for pg_upgrade and
> test_decoding sticking around till the end of the run. That could
> be fixed in the script of course, but why not have pg_regress do it?
>
> Also, investigating space consumption on my actual buildfarm critters,
> it seems like there might be some low hanging fruit in terms of git
> checkout management. It looks to me like each branch has a git repo
> that only shares objects that existed as of the initial cloning, so
> that over time each branch eats more and more unshared space. Also
> I wonder about the value of keeping around a checked-out tree per
> branch and copying it each time rather than just checking out fresh.
> What I see on dromedary, which has been around a bit less than a year,
> is that the at-rest space consumption for all 6 active branches is
> 2.4G even though a single copy of the git repo is just over 400MB:
>
> $ du -hsc pgmirror.git HEAD REL*
> 416M pgmirror.git
> 363M HEAD
> 345M REL9_0_STABLE
> 351M REL9_1_STABLE
> 354M REL9_2_STABLE
> 358M REL9_3_STABLE
> 274M REL9_4_STABLE
> 2.4G total
>
> It'd presumably be worse on a critter that's existed longer.
>
> Curious to know if you've looked into alternatives here. I realize
> that the tradeoffs might be different with an external git repo,
> but for one being managed by the buildfarm script, it seems like
> we could do better than this space-wise, for (maybe) little time
> penalty. I'd be willing to do some experimenting if you don't have
> time for it.

This isn't happening for me. Here's crake:

[andrew(at)emma root]$ du -shc pgmirror.git/ [RH]*/pgsql
218M pgmirror.git/
149M HEAD/pgsql
134M REL9_0_STABLE/pgsql
138M REL9_1_STABLE/pgsql
140M REL9_2_STABLE/pgsql
143M REL9_3_STABLE/pgsql
146M REL9_4_STABLE/pgsql
1.1G total

Maybe you need some git garbage collection?

An alternative would be to remove the pgsql directory at the end of the
run and thus do a complete fresh checkout each run. As you say it would
cost some time but save some space. At least it would be doable as an
option, not sure I'd want to make it non-optional.

cheers

andrew

In response to

Responses

Browse buildfarm-members by date

  From Date Subject
Next Message Tom Lane 2015-01-19 05:28:54 Re: Reducing buildfarm disk usage: remove temp installs when done
Previous Message Tom Lane 2015-01-19 02:20:39 Re: Reducing buildfarm disk usage: remove temp installs when done

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-01-19 04:42:24 Re: install libpq.dll in bin directory on Windows / Cygwin
Previous Message Amit Langote 2015-01-19 04:09:43 Re: Partitioning: issues/ideas (Was: Re: On partitioning)