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