From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1527624207; bh=Vo1KID6xnW7JDbXMadK0fwAzRcsV1CkjBOu/GS7T5UM=; h=Date:From:To:Subject; b=U2CPBwLjJdsC4iM9ro+YY+wNU9rpHMoc7OHJg6HmZLmXAt1tvrBglOvf1iJ4wlBi6 f91LY4bJZLQLnHv9pRWyzN8FNds3bN3pdIoUk0mEXoB9IhCHt3Bbjgs+RyMJQiu/x7 5EvjDt4MbghjT1OsjEJpNpVTDYiAhRLWSZrBbApY= Date: Tue, 29 May 2018 23:03:25 +0300 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20180529200325.GA8502@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] =?utf-8?b?0KHQsdC+0YDQvtGH0L3QuNGG0LAgLSDQv9GA0LDQstC4?= =?utf-8?b?0LvRjNC90YvQtSDQvdCw0YHRgtGA0L7QudC60Lgu?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:03:30 -0000 Archived-At: List-Archive: List-Post: Уважаемые коллеги, чтобы продвинуться с обновлением 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