[devel] Сборочница - правильные настройки.

[devel] Сборочница - правильные настройки.

[Igor Vlasenko]

Уважаемые коллеги,

чтобы продвинуться с обновлением java
нужна срочная помощь со сборчницей.

Начал обновление gradle. Залил бутстрап,
а полноценный gradle отправить в Сизиф не могу.
На локальной машине gradle собирается. Но там 4 ядра.

На сборчнице же, как предполагаю,
16 или 32 виртуальных ядра и дефолтный
$ ulimit -u
512

Чем это плохо? Непуганные апстримы практикуют индийский код вида
for Runtime.getRuntime().availableProcessors():
    create a thread, а иногда, возможно, и fork().
При этом сама JVM thread - прожорлива, запускает JIT threads
по числу availableProcessors().
При вложении индийского кода друг в друга мы с легкостью получаем
C*N^2 threads. Для N=2 или N=4 это чепуха,
но для N=32 это уже немало. На нашей сборчнице
это упирается в ее ulimit -u=512
и сборка падает с unable to create new native thread (Хотя памяти в
системе хватает).

Конкретно с gradle N^2 threads, рождаются не только из-за
самого gradle, (хотя и внутри его есть много подобного кода,
но есть хотя бы ограничивающие опции)
а еще внутри используемых им библиотек (ivy,...?).
Апстрим это рассматривает как неправильную конфигурацию -
если у вас такая крутая машина с N ядер и N Gb памяти -
просто поднимите лимит до соответствующих 4096/8192.

Я так понимаю, со сборочницей мы уже наступали на эти грабли,
на что намекает текущий хак с NPROC=1, чтобы сборочнице
не плохело от make -j32.

Чем плох наш NPROC=1 костыль, что он не универсальный - заточен под make.

Я бы советовал cpuset(7) -- нарезать ноду на K пользователей,
и дать каждому пользователю N/K ядер. Приложения, и в частности, JVM,
будут тогда думать, что запущены на N/K ядерной машине и проблема исчезнет.
и ulimit -u поднять, конечно, XXI век на дворе, все-таки.
Заодно в перспективе это поможет уплотнить сборочные ноды,
чтобы на одной ноде можно было бы  параллельно пускать больше сборок.

А прямо сейчас прошу хотя бы только ulimit -u поднять,
чтобы gradle мог собраться и на нашей сборочнице.

-- 

I V

Re: [devel] Сборочница - правильные настройки.

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

On Tue, May 29, 2018 at 11:03:25PM +0300, Igor Vlasenko wrote:
> Уважаемые коллеги,
> 
> чтобы продвинуться с обновлением java
> нужна срочная помощь со сборчницей.
> 
> Начал обновление gradle. Залил бутстрап,
> а полноценный gradle отправить в Сизиф не могу.
> На локальной машине gradle собирается. Но там 4 ядра.
> 
> На сборчнице же, как предполагаю,
> 16 или 32 виртуальных ядра и дефолтный
> $ ulimit -u
> 512
> 
> Чем это плохо? Непуганные апстримы практикуют индийский код вида
> for Runtime.getRuntime().availableProcessors():
>     create a thread, а иногда, возможно, и fork().
> При этом сама JVM thread - прожорлива, запускает JIT threads
> по числу availableProcessors().
> При вложении индийского кода друг в друга мы с легкостью получаем
> C*N^2 threads. Для N=2 или N=4 это чепуха,
> но для N=32 это уже немало. На нашей сборчнице
> это упирается в ее ulimit -u=512
> и сборка падает с unable to create new native thread (Хотя памяти в
> системе хватает).
> 
> Конкретно с gradle N^2 threads, рождаются не только из-за
> самого gradle, (хотя и внутри его есть много подобного кода,
> но есть хотя бы ограничивающие опции)
> а еще внутри используемых им библиотек (ivy,...?).
> Апстрим это рассматривает как неправильную конфигурацию -
> если у вас такая крутая машина с N ядер и N Gb памяти -
> просто поднимите лимит до соответствующих 4096/8192.
> 
> Я так понимаю, со сборочницей мы уже наступали на эти грабли,
> на что намекает текущий хак с NPROC=1, чтобы сборочнице
> не плохело от make -j32.

Первоначально nprocs=1 был выставлен для лучшей воспроизводимости сборки.

> Чем плох наш NPROC=1 костыль, что он не универсальный - заточен под make.
> 
> Я бы советовал cpuset(7) -- нарезать ноду на K пользователей,
> и дать каждому пользователю N/K ядер. Приложения, и в частности, JVM,
> будут тогда думать, что запущены на N/K ядерной машине и проблема исчезнет.

Уже.  Я экспериментирую с раздачей по одной numa node на пользователя,
nproc(1) там показывает 8, %__nprocs с недавних пор по умолчанию
содержит то, что выводит nproc(1).

Но некоторые это игнорируют, разными способами (_SC_NPROCESSORS_ONLN,
/proc/stat, /proc/cpuinfo, ...) берут число видимых cpu units,
и получается фигня.

Мы попробовали ограничить видимую часть /proc/stat и /proc/cpuinfo
cpuset'ом, но эксперименты показывают, что, например, maven от этого
сходит с ума:
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-May/103621.html

> и ulimit -u поднять, конечно, XXI век на дворе, все-таки.

Кто-нибудь знает, сколько им надо тредов на N cpu units?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Сборочница - правильные настройки.

[Igor Vlasenko]

On Tue, May 29, 2018 at 11:29:47PM +0300, Dmitry V. Levin wrote:
> > и ulimit -u поднять, конечно, XXI век на дворе, все-таки.
> 
> Кто-нибудь знает, сколько им надо тредов на N cpu units?

есть два кролика для тестирования.
#207136 FAILED #1 sisyphus srpm=gradle-4.3.1-alt1_5jpp8.src.rpm
#207006 FAILED #3 sisyphus srpm=gradle-4.3.1-alt1_5jpp8.src.rpm

207006 - ванильный, собирается на 4-х ядрах.
а в #207136 - пытался везде где можно 
вкрутить ручки на минимум - не помогло.

-- 

I V

Re: [devel] Сборочница - правильные настройки.

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Tue, May 29, 2018 at 11:58:53PM +0300, Igor Vlasenko wrote:
> On Tue, May 29, 2018 at 11:29:47PM +0300, Dmitry V. Levin wrote:
> > > и ulimit -u поднять, конечно, XXI век на дворе, все-таки.
> > 
> > Кто-нибудь знает, сколько им надо тредов на N cpu units?
> 
> есть два кролика для тестирования.
> #207136 FAILED #1 sisyphus srpm=gradle-4.3.1-alt1_5jpp8.src.rpm
> #207006 FAILED #3 sisyphus srpm=gradle-4.3.1-alt1_5jpp8.src.rpm
> 
> 207006 - ванильный, собирается на 4-х ядрах.

Для nproc(1) == 8:
512 было недостаточно, а 1024 хватило.
Т.е. N * 2^6 мало, а N * 2^7 достаточно.

Тем временем ванильный кролик уже в Сизифе.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Сборочница - правильные настройки.

[Igor Vlasenko]

On Wed, May 30, 2018 at 12:22:51AM +0300, Dmitry V. Levin wrote:
> 512 было недостаточно, а 1024 хватило.
> Т.е. N * 2^6 мало, а N * 2^7 достаточно.
> 
> Тем временем ванильный кролик уже в Сизифе.

Большое спасибо!


-- 

I V