I don't know what is causing that. Whether MBS is just spawning too many newRepo and counts those into the concurrency limit or just waiting for newRepo is just slow. Or tagging counts into the concurrency limit.
I don't know, but this is really pissing me off. When you can build all packages on your laptop within 15 minutes and in infra it takes 9+ hours... Something is really broken.
For the first build, it looks like there's a 14 hour window before the build is actually resubmitted:
2019-06-22 17:29:06,039 - PoolThread-twisted.internet.reactor-1 - MBS.builder.KojiModuleBuilder - INFO - <KojiModuleBuilder module: ffsend, tag: module-ffsend-latest-3120190622153640-22d7e2a5> buildroot sucessfully connected. 2019-06-23 07:04:14,981 - PoolThread-twisted.internet.reactor-1 - MBS.scheduler.handlers.modules - INFO - Found build=<ModuleBuild ffsend, id=4807, stream=latest, version=3120190622153640, scratch=False, state 'wait', batch 0, state_reason u'Resubmitted by ignatenkobrain'> from message
There's still, of course, 2 hours unaccounted for. Both examples seem to indicate the same performance issue.
In my case it is because it inevitable is picking extremely slow 32bit arm builders for some of my noarch packages, even though I specify arches: [x86_64, ppc64le, aarch64, s390x] for all my components
arches: [x86_64, ppc64le, aarch64, s390x]
If I get a long running build stuck on a 32bit arm machine I just cancel and resubmit the build if I want the module build to complete in less than one day.
The ticket #1311 is related to this
The issue described in #1312 can also contribute to perceived performance issues.
I'm going to close this ticket in favor of #1311. In #1312, we already disabled the concurrent build threshold in Fedora which has helped. #1311 is still needed since MBS is easily overwhelmed.
Metadata Update from @mprahl: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.