Project

General

Profile

Bug #49583

Master RPM builds in OBS run out of memory while attempting in-memory parallel compression

Added by Nathan Cutler almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

b50fc9e61c39e6f9544b67cb5cd49c67bf6dd02e introduced the use of "multi-threaded xz compression so we can build the compressed src rpm and binary rpms with smaller latency". This causes Ceph builds of the upstream master branch to fail in the OBS because OBS workers can theoretically run a high number of concurrent execution threads (typically 16), yet do not have enough memory to sustain all-out in-memory xz compression at the maximum number of threads. Since build workers in OBS have heterogeneous hardware, the maximum sustainable concurrency has to be calculated at build-time (in the %build section of the spec file). However, the number of threads for xz compression is set much higher up in the spec file.

Since this change - b50fc9e61c39e6f9544b67cb5cd49c67bf6dd02e - caused OBS builds to start failing 100% of the time, and it's not clear how to calculate the maximum sustainable number of xz compression threads (like we are able to do for %_smp_mflags in the %build section of the spec file), we can at least surround these two lines in a conditional so they don't get executed in OBS builds.

History

#1 Updated by Nathan Cutler almost 2 years ago

  • Status changed from New to Fix Under Review
  • Pull request ID set to 39813

#2 Updated by Nathan Cutler almost 2 years ago

  • Status changed from Fix Under Review to Resolved

Also available in: Atom PDF