Re: 504 gateway time-outs

On 3/31/26 12:37, Mark Millard wrote:
> On 3/31/26 06:25, Philip Paeps wrote:
>> On 2026-02-28 19:32:35 (+0800), Graham Perrin wrote:
>>> On 28/02/2026 10:32, Mark Millard wrote:
>>>> The following got "504 Gateway Time-out" when I tried them:
>>>>
>>>> <https://pkg-status.freebsd.org/beefy24/build.html?mastername=main-
>>>> amd64-default&build=pdf4f957ea181_s178d0b5b8d>
>>>>
>>>> <https://pkg-status.freebsd.org/beefy23/build.html?
>>>> mastername=150amd64-default&build=df4f957ea181>
>>>
>>> Both somewhat slow to load, however they do load for me.
>>
>> I only just noticed this thread, sorry for resurrecting it.
>>
>> I've noticed that beefy23 and beefy24 (2x EPYC 9254, 512G RAM) sometimes
>> get too busy building to schedule nginx (or sshd).  They eventually
>> manage to plough through.  Usually.
>>
>> That causes the 504 timeouts if you're going through pkg-status.f.o.  If
>> you're going directly to beefyX.chi.freebsd.org you'll just get a timeout.
>>
>> They're running exactly the same poudriere.conf as the other builders. 
>> I wonder if our calc_builders() function that tries to assign about 12G
>> per builder isn't quite right for this particular configuration of cores
>> and RAM.
>>
>> I haven't had a chance to look closely.  As far as I can tell the builds
>> do eventually succeed.  If the only problem is "I can't obsessively poll
>> pkg-status in real time", it's not a very high priority. :)
> 
> It is mostly not having a clue about the distinction between "the
> overall build failed somehow, such as by the builder system crashing"
> and "you just can not observe anything now but the system is still".
> 
> I was explicitly asked to not send in notes about potential failure
> symptoms so I no longer add to the clusteradm workload in such cases.
> 
> [I do wonder if those builders are, over significant times,
> page-thrashing or anything else that might suggest mis-tuning to the
> point that the overall builds take notably longer. I do expect load
> averages generally larger than the FreeBSD count of cpus for keeping
> overall elapsed times smaller: otherwise there is likely unused idle
> time not put to useful work. But that wording ignores issues like
> page-thrashing consequences that can be involved for too much RMA+SWAP
> resource intensive activity in parallel if some mutual exclusion of huge
> builders is not prevented.]

I will say that, for being able to check the build status of specific
packages from prior builds that have completed, I'm not a fan that those
type of checks are sometimes blocked by "504 timeouts" for unrelated
activity. It is more obvious for a bulk run that is in progress. (But
that should not establish any significant priority status overall.)

[Prompted/reminded by trying to answer a question in a way that involved
the status of xfce4-desktop in fairly recently completed builds: I hit
the "504" issue and could not check the status of such.]

Use of https://portsfallout.com/server related activity does not report
on skipped or ignored, only failed. It never indicates that any specific
builds actually were completed successfully vs. skipped/ignored.

> 
>>
>> This is on my list.  It's just a VERY long list. :)
> 
> Yep.
> 
>>
>> Philip
>>
>>
> 
> Thanks for the notes.
> 


-- 
===
Mark Millard
marklmi at yahoo.com