Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

Don Lewis truckman at FreeBSD.org
Thu Dec 7 23:35:03 UTC 2017


On  7 Dec, Jan Bramkamp wrote:
> On 06.12.17 23:23, Dave Horsfall wrote:
>> On Wed, 6 Dec 2017, Jan Bramkamp wrote:
>> 
>>> Synth and poudriere are parallel build tools and as such are very 
>>> taxing on the system. I suspect your system is unstable under such 
>>> load, because of a configuration error or unreliable hardware. One 
>>> such configuration error that bit me is tmpfs mounted without size 
>>> limitation. Without size limits it can exhaust RAM + swap and crash 
>>> the system. Limit the sum of all your tmpfs mounts to significantly 
>>> less than RAM + swap.
>> 
>> What happens then?  Does the build process merely crash instead?  I ask 
>> because my minimal system (all I can afford on my "income") has 512MB 
>> memory (all it will take) ad 1GB swap; building Ruby etc kills it, so I 
>> use packages in that case i.e. no customisation if I wanted it.
> 
> In that case I wouldn't use tmpfs at all. One conceptual difference 
> between the old portmaster/portupgrade tools and the newer tools like 
> poudriere and synth is that the old tools try to minimize rebuilds by 
> modifying the live system. This can break the system if the upgrade 
> fails and will leave it inconsistent while the upgrade runs. Also some 
> ports misbehave and interact with installed software they didn't list as 
> dependency if it is installed. For these reasons the new tools create 
> jail/chroot environments to build ports in a clean environment. 
> Poudriere is designed around ZFS features (snapshots and cloning). Those 
> can be emulated with UFS and overlay file systems, but Poudriere works 
> best on a big ZFS based system with enough RAM to keep the build dirs in 
> tmpfs (e.g. 8GB RAM per parallel builder and one builder per CPU 
> core/thread). You can configure poudriere to use a single builder and 
> UFS, but it will be a slow process.

I get adequate performance with about half that amount of RAM, even with
ALLOW_MAKE_JOBS=yes and using tmpfs for everything that makes sense, and
building a lot of the extra-large ports. My eight core package builder
is maxed out at 32 GB of RAM.  I just end up using swap pretty heavily.

Towards the end of my package build runs, I typically see chromium,
firefox, libreoffice, openoffice-4, openoffice-devel, and thunderbird
all being built in parallel.  The openoffice builds claim to need 11 GB
of free diskspace each.  Fortunately the stuff in tmpfs is not randomly
accessed, so not much RAM is needed to hold the working set, so the
machine seldom thrashes.  I actually see very little disk activitity
much of the time.

At higher core counts, it's probably best to set a MAKE_JOBS_NUMBER
limit.  If you don't do that, then the number of parallel running
threads will increase as the square of the number of CPU cores.  My not
yet in production Ryzen machine has eight cores and 16 SMT threads and
is maxed out at 64 GB of RAM.  I get the best overall poudriere run time
with MAKE_JOBS_NUMBER=7.  The problem not setting ALLOW_MAKE_JOBS=yes is
that towards the end of the run, ports that take a long time to build
will run for a long time with only one core being used and all of the
other CPU cores idle.  It would be nice if this was more dynamic, but
that's difficult with each builder contained in its own jail.


> Synth reduces that overhead somewhat by reusing the host system. Its 
> focus is more on keeping a single system up to date instead of compiling 
> sets of ports to custom repos for other systems and the curses UI is a 
> nice touch. Also synth can try to avoid building ports by prefetching 
> packages from an upstream repo.
> 
> To be honest few FreeBSD devs still care about self hosting FreeBSD on 
> such tiny systems (0.5GB RAM, 1-2 cores). There are devs interested on 
> optimizing FreeBSD for small embedded systems but you aren't expected to 
> rebuild FreeBSD from source on a wireless access point or dedicated 
> firewall appliance. If you have to compile and value your time get 
> adequate hardware. Old 2U dual sockets servers may burn a lot of power 
> but are quite cheap and you don't have to run a compile server 24/7.

My Pentium-M laptop with 1 or 2 GB of RAM is getting questionable for
self-hosting.  Just doing buildworld + buildkernel is an all day affair.
Trying to use portmaster to do an upgrade in place would probably take a
week assuming that it didn't run out of space or thrash itself to death.
It runs firefox and OpenOffice just fine, but it is questionable as to
whether it could build them.

Then there is this machine:
CPU: VIA Nehemiah (1000.06-MHz 686-class CPU)
  Origin="CentaurHauls"  Id=0x698  Family=0x6  Model=0x9  Stepping=8
  Features=0x381b93f<FPU,VME,DE,PSE,TSC,MSR,CX8,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,S
SE>
  VIA Padlock Features=0xdd<RNG,AES>
real memory  = 268435456 (256 MB)
avail memory = 245055488 (233 MB)

It is still perfectly adequate for the work that it does, but I don't
even think I could "make buildworld" on it anymore, let alone build
ports.  I keep it up to date with freebsd-update and packages built on
my package builder.  World and kernel are actually customized, so I had
to set up my own freebsd-update server for it, which is not for the
faint of heart.  I'm really looking forward to packaged base to make
keeping it up to date easier.



More information about the freebsd-ports mailing list