Ninja: 닌자는 사용 가능한 모든 메모리를 소비합니다.

ninja는 실행되는 프로세스에 대해 알지 못합니다. 또한 프로세스가 하나의 CPU 코어를 사용하는 모델이 대부분의 건물에 가장 적합하다고 생각합니다.
그러나 메모리 소비는 명령 간에 크게 다르며(예: 간단한 Python 스크립트 대 대형 개체 연결) 이러한 명령에 대한 메모리 사용에 대한 공통된 가정을 갖기가 어렵습니다.

메모리 소모 프로세스의 병렬 처리를 제어하려면 빌드의 메모리 풋프린트를 잘 알고 있을 때 더 낮은 -j를 지정하거나 풀 기능을 사용하는 것이 좋습니다.
https://ninja-build.org/manual.html#ref_pool

프로세스가 하나의 CPU 코어를 사용하는 모델이 대부분의 건물에 가장 적합하다고 생각합니다.

RAM의 총량도 고려해야 한다고 생각합니다. 하드 드라이브로 바꾸는 것은 실제 성능에 도움이 되지 않습니다.

메모리 소비 프로세스의 병렬 처리를 제어하려면 더 낮은 -j를 지정하거나 풀 기능을 사용하는 것이 좋습니다.

저는 Android NDK 빌드 시스템의 개발자가 아니므로 ninja 명령에 명령줄 인수를 전달하지 않습니다. — Android 빌드 시스템은 그렇습니다.

환경 변수 MAKEFLAGS="-j4"를 설정했지만(대부분의 make 기반 빌드 시스템에서 이를 준수함) 닌자는 이를 사용하지 않는 것 같습니다.

gradle에서 cmake를 통해 직접 ninja에 인수를 제공할 수 있다고 생각합니다. 내가 볼 수 있듯이 gradle의 cmake 통합 에는 arguments 필드가 있습니다. 어쩌면 이것이 효과가 있을까요?

@jimon

당신이 돕고 싶어한다는 것을 이해하지만 그게 요점이 아닙니다.

내 입장:

1) make 는 안전한 기본값을 가지며 환경 변수를 통해 더 큰 병렬 처리로 전환할 수 있습니다.
2) 닌자는 안전하지 않은 기본값을 가지고 있습니다. 일부 프로그램을 빌드하면 내 시스템이 중단될까 항상 두려워합니다(빌드하기 전에 각 임의의 AUR 소프트웨어에서 어떤 빌드 시스템을 사용하는지 확인하고 싶지 않습니다!). 잘 모르겠습니다. 기본값을 전역적으로 변경하는 방법 닌자의.

@Alexander-- , (스왑 파일 또는 다른 수단을 통해) 가지고 있는 것보다 더 많은 RAM을 할당하는 단일 실행 파일(컴파일러 또는 이와 유사한 것)이 있다고 상상해 보십시오. 해당 앱과 비올라만 실행하는 빌드 시스템이 있습니다. 시스템이 응답하지 않습니다. 이 정신적 예를 통해 이 문제는 절대적으로 해결할 수 없음이 분명합니다. 이제 실행 파일이 시간이 지남에 따라 점진적으로 메모리를 할당하는 경우를 상상해 봅시다. 닌자는 메모리 사용량에 대한 사전 지식이 없으며 RAM이 실제로 사라진 후에야 비로소 명백해질 것입니다. 문제는 쉽게 해결할 수 없으며 프로젝트의 범위가 되어야 한다고 생각하지 않습니다.

make가 더 안전한 기본값을 갖는 것에 관해서는 - 개발자가 make에서 병렬 처리를 인식하지 못하거나 귀찮게 할 수 없기 때문에 얼마나 많은 개발자 시간이 낭비되는지 상상할 수 없습니다. 저는 동료들이 기본적으로 하나의 스레드에서 빌드하는 것을 인식하지 못하기 때문에 몇 분 또는 몇 시간을 낭비하는 것을 끊임없이 봅니다.

나는 당신의 문제를 해결하는 것을 반대하고 싶지 않으며 거칠게 들리고 싶지 않습니다. :) 그러나 가장 최적의 솔루션은 gradle 동작을 무시하고 계속 진행하는 것입니다. 프로젝트/컴퓨터에 매우 고유하고 더 큰 규모로 표시되지 않을 수 있기 때문입니다.

어떤 Android 빌드 시스템을 사용하고 있습니까? NDK로 Android 앱을 빌드하시겠습니까? 아니면 전체 플랫폼(ROM)을 빌드하시겠습니까?

Ninja + Gradle + Jack = 지옥. (최소 16GB RAM을 차지함)
정확히 어디에 문제가 있는지 모르겠습니다. 그러나 주요 문제는 jack-server를 사용하는 Java 빌드에서 비롯된 것 같습니다. 더 중요한 것은 Ninja(from Soong)가 모든 레거시를 변경하고 너무 많은 작은 소프트웨어를 도입하므로 빌드 시스템에서 길을 잃고 문제와 솔루션을 찾을 수 없다는 것입니다.
예전 메이크가 그리웠어요. 이 지옥에서 저를 꺼내주세요.
이 "No Jack 서버가 실행 중입니다. 'jack-admin start-server'를 사용해 보세요'"를 해결하기 위해 돌아와야 합니다.

@atetubou 를 다시 표현하자면 CPU에 64개의 코어가 있는 경우 64개의 프로그램을 병렬로 실행할 수 있다고 가정하는 것이 합리적입니다. 이 가정이 문제가 되는 이유는 컴파일 작업이 일반 프로그램보다 커 보이기 때문입니다. Ninja에는 '풀' 기능을 통해 이 정보를 전달하는 메커니즘이 있습니다. 해당 문서 섹션을 읽으면 정확히 이 문제를 위해 설계되었음을 알 수 있습니다. https://ninja-build.org/manual.html#ref_pool

나는 당신의 문제에 공감하지만 Ninja가 그것을 해결할 쉬운 방법을 보지 못합니다. 총 RAM 양을 "고려해야" 한다고 말하지만 어떤 종류의 공식을 사용할 수 있습니까?

@av930 잭은 P에서 사라지고 O 빌드에서 비활성화될 수 있습니다. O 빌드에서 잭 사용을 제거했으며 12기가 메모리가 있는 8코어는 16개 이상의 스레드로 실행하는 데 문제가 없습니다. ninja가 빌드 중에 사용하는 인수를 변경할 수도 있습니다. 문제는 닌자가 아니라 잭입니다.

또한 이 변경 사항이 도움이 될 수 있습니다. https://github.com/ninja-build/ninja/pull/1399

세상에! 감사합니다. 작동합니다. 마지막으로 16GRAM 머신에서 AOSP 전체 빌드를 완료했습니다.
잭 비활성화: ANDROID_COMPILE_WITH_JACK := build/make/core/javac.mk에서 false

이것은 로그입니다.
[ 99% 101694/101695] 시스템 fs 이미지 설치: out/target/product/taimen/system.img
out/target/product/taimen/system.img+ maxsize=2740531200 blocksize=135168 total=1076289888 reserve=27709440
[100% 101695/101695] 대상 vbmeta 이미지: out/target/product/taimen/vbmeta.img

빌드가 성공적으로 완료되었습니다(04:43:31(hh:mm:ss)).

n 실행 중인 프로세스 그룹의 경우 메모리 부족 상황에서 최대 n-1 프로세스를 일시 중단해도 된다고 OS에 알려서 이 문제를 해결할 수 있다고 생각합니다. 이것이 Linux에서 cgroup으로 달성될 수 있는지 아는 사람이 있습니까?

실제로 메모리 제한을 구현하는 두 개의 PR이 있습니다: #1354 및 #660. 후자의 논의는 흥미롭다.

이것은 대부분 Android 빌드가 풀에 잭을 넣지 않아 닌자를 잘못 잡고 있는 것처럼 들립니다.

@니코

이 문제를 해결한 특정 Ninja 버전을 지적해 주시겠습니까? AUR에서 무언가를 빌드할 때마다 기본적으로 Ninja가 너무 많은 병렬 작업을 사용하는 것을 여전히 보고 있습니다. Ninja는 사용 가능한 RAM 양에 관계없이 16코어 머신에서 18스레드를 생성하려고 시도하는 것 같습니다.

Ninja는 여기서 아무 것도 하지 않습니다. 많은 RAM(또는 이와 유사한 것)이 필요한 것이 적절한 크기의 풀에 있는지 확인하는 것은 생성기에 달려 있습니다.

많은 RAM(또는 이와 유사한 것)이 필요한 것이 적절한 크기의 풀에 있는지 확인하는 것은 생성기에 달려 있습니다.

이것은 당신의 개인적인 의견입니까, 아니면 Ninja 개발자의 공식 입장입니까? 문서 에서는 그러한 책임에 대해 언급한 적이 없으며 실제로 Ninja 병렬 처리에 간섭하는 생성기에 대해서도 들어본 적이 없습니다.

어느 쪽이든, 생성기 작성자는 실행할 병렬 프로세스 수를 선택하는 것보다 더 나은 위치에 있지 않습니다. 이는 buildserver 관리자가 가장 잘 결정합니다.

사용된 생성기에 관계없이 작동하는 Ninja 리소스 사용량을 낮추는 일반적인 방법은 없으며 절대 있어서는 안 됩니다. 나는 동의하지 않는다. 해당 기능을 가진 빌드 도구(예: GNU Make)가 있으므로 이러한 기능에 대한 선례가 이미 있습니다.

문서에서는 그러한 책임에 대해 언급한 적이 없으며 실제로 Ninja 병렬 처리에 간섭하는 생성기에 대해서도 들어본 적이 없습니다.

RAM에 대해 명시적으로는 아니지만:

"빌드 시 사용자 정의 빌드. 옵션은 닌자 파일을 생성하는 프로그램에 속합니다."

"Ninja에는 기능이 거의 없습니다. 빌드를 수정하는 데 필요한 기능만 있으면 되고 닌자 입력 파일을 생성하는 데 가장 복잡합니다."

사용된 생성기에 관계없이 작동하는 Ninja 리소스 사용량을 낮추는 일반적인 방법은 없으며 절대 있어서는 안 됩니다.

-j 및 -l 플래그의 두 가지 방법이 있습니다.

AUR에서 무언가를 빌드할 때마다 기본적으로 Ninja가 너무 많은 병렬 작업을 사용하는 것을 여전히 보고 있습니다.

AUR이 어떻게 작동하는지 정확히 모르지만 다음 스크립트를 /usr/local/bin 에 넣고 chmod +x /usr/local/bin/ninja 를 통해 실행 가능하게 만들까요?

#!/usr/bin/env python3

import sys
import subprocess

try:
    subprocess.check_call(['/usr/bin/ninja', '-j1'] + sys.argv[1:])
except subprocess.CalledProcessError as e:
    exit(e.returncode)

-j1 는 첫 번째 응답에서와 같이 언급될 수 있습니다.
시간이 지남에 따라 많은 내부 external_projects를 확보한 이 프로젝트가 있습니다. 즉, 공통 makefile이 사용하는 동적 빌드 대신 정적으로 빌드하므로 빌드되는 자체 플래그와 소스가 있습니다.
오늘날 이 구형 노트북에서(이 시스템에서 닌자를 사용한 적이 없음) 코어 i7(8 스레드)이 있는 4GB Windows 7 시스템일 뿐입니다. 빌드를 시작했을 때 전체 시스템이 디스크에서 교환되는 동안 30분 동안 크롤링되었습니다.
바이자레 오류가 발생했습니다.

C:/general/build/mingw64-x64/sack/RelWithDebInfo_out/core/include/SACK/stdhdrs.h:259:24: fatal error: C:/general/build/mingw64-x64/sack/RelWithDebInfo_out/core/include/SACK/loadsock.h: Invalid argument
compilation terminated.

파일을 포함하는 것이 잘못된 인수인 이유는 무엇입니까? 파일이 존재합니다....
그래서 전체 빌드가 완료되었지만 많은 대상을 성공적으로 빌드하지 못했습니다...
내가 지금 사용하는 경우에도

ninja -j1 -v install 

내부 닌자 프로세스는 여전히 -j8을 사용합니다.

빌드는 각각 -j8을 사용하여 8개의 외부 프로젝트를 시작한 첫 번째에서 -j8이 되었기 때문에 -j64는 메모리가 없을 때까지 최대 메모리를 사용했습니다...

이 경우 작업 서버 지원이 도움이 될 수 있습니다. #1139

독립적인 Ninja 빌드 언어 재구현 https://github.com/michaelforney/samurai 는 환경 변수 SAMUFLAGS를 통해 이를 지원합니다. 닌자를 사용하려는 모든 곳에서 samu를 사용하거나 시스템 /usr/bin/ninja로 samu를 설치하기만 하면 됩니다(일부 Linux 배포판에는 이 경쟁 구현을 기본 또는 닌자 전용으로 설치하는 옵션이 있습니다).

커뮤니티/사무라이를 대신 사용하려면 닌자로 빌드하는 AUR 패키지를 업데이트하는 것이 좋습니다.