[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