«Недостаточно памяти» при запуске сервера Jenkins

Question

Первый пользователь Jenkins здесь, и у него возникли проблемы с его запуском. Из оболочки Linux Я бегу команду вроде:

java -Xms512m -Xmx512m -jar jenkins.war 

и последовательно получаю сообщение об ошибке, как:

# There is insufficient memory for the Java Runtime Environment to continue. 
# pthread_getattr_np 
# An error report file with more information is saved as: 
# /home/twilliams/.jenkins/hs_err_pid36290.log 

Во-первых, основы:

• Дженкинс 1,631
• Запуск через причал, встроенный в военный файл
• OpenJDK 1.7.0_51
• Oracle Linux (3.8.13-55.1.5.el6uek.x86_64)
• 386 GB RAM
• 40 ядер

я получаю такую ​​же проблему с рядом других конфигураций, а также: с помощью Java Hotspot 1.8.0_60, проходящий через Apache Tomcat, и используя всевозможные значения для -Xms/-Xmx/-Xss и аналогичные варианты.

Я сделал справедливое исследование и думаю Я знаю, в чем проблема, но я в затруднении, как его решить. Я подозреваю, что я столкнулся с проблемой превышения виртуальной памяти, упомянутой here; соответствующие биты от: всех ограничений

--($:)-- ulimit -a 
... 
max locked memory  (kbytes, -l) 64 
max memory size   (kbytes, -m) 8388608 
stack size    (kbytes, -s) 8192 
virtual memory   (kbytes, -v) 8388608 
... 

Если я дважды виртуальный предел памяти как корень, я могу начать Дженкинс, но я предпочел бы не запустить Дженкинс в качестве корневого пользователя.

Еще одно обходное решение: машина, которая вскоре будет снята с производства, с барабаном 48 ГБ и 24 ядрами, может запустить Jenkins без проблем, хотя (я подозреваю), едва ли: согласно htop, ее площадь виртуальной памяти составляет чуть более 8 ГБ , В результате я подозреваю, что проблема с превышением памяти масштабируется с количеством процессоров на машине, по-видимому, результатом того, что Дженкинс начинает ряд потоков, пропорциональных количеству процессоров, присутствующих на главной машине. Я грубо зафиксировал количество потоков с помощью ps -eLf | grep jenkins | wc -l и обнаружил, что количество потоков увеличивается около 114 на 40-ядерном компьютере и 84 на 24-ядерном компьютере.

Является ли это объяснение показательным? При условии, что он ...

1. Есть ли способ настроить Jenkins для уменьшения количества потоков, которые он порождает при запуске? Я пробовал аргументы here, но, как было объявлено, они не оказали никакого влияния.
2. Имеются ли какие-либо виртуальные машины, которые не страдают от проблемы с превышением или какой-либо другой вариант конфигурации для ее устранения?

Самым подходящим вариантом на данном этапе может быть просто запуск Jenkins в виртуализованной среде, чтобы ограничить ресурсы в его распоряжении чем-то разумным, но на данный момент меня интересует эта проблема на интеллектуальном уровне и хочу знать, как заставить эту непокорную конфигурацию вести себя.

Редактировать

Вот отрывок из hs_error.лог-файл, который, руководствуясь мое первоначальное расследование:

# There is insufficient memory for the Java Runtime Environment to continue. 
# pthread_getattr_np 
# Possible reasons: 
# The system is out of physical RAM or swap space 
# In 32 bit mode, the process size limit was hit 
# Possible solutions: 
# Reduce memory load on the system 
# Increase physical memory or swap space 
# Check if swap backing store is full 
# Use 64 bit Java on a 64 bit OS 
# Decrease Java heap size (-Xmx/-Xms) 
# Decrease number of Java threads 
# Decrease Java thread stack sizes (-Xss) 
# Set larger code cache with -XX:ReservedCodeCacheSize= 
# This output file may be truncated or incomplete. 

Вот несколько командных строк я пробовал, все с тем же результатом.

• Начиная с жалкой суммы кучного пространства:
  • java -Xms2m -Xmx2m -Xss228k -jar jenkins.war
• Начиная с значительно больше кучи пространства:
  • java -Xms2048m -Xmx2048m -Xss1m -XX:ReservedCodeCacheSize=512m -jar jenkins.war
• номер расти:
  • java -Xms2m -Xmx1024m -Xss228k -jar jenkins.war

были испытаны, а также ряд других конфигураций. В конечном счете, я не думаю, что проблема заключается в изнурительной работе здесь - это то, что JVM пытается зарезервировать слишком много виртуальной памяти для себя (для хранения кучи, стеков потоков и т. Д.), Чем разрешено настройками ulimit. Предположительно, это результат проблемы overcommit, связанной ранее, так что если Jenkins генерирует 120 потоков, это ошибочно пытается зарезервировать 120x столько же пространства VM, сколько первоначально начальный процесс.

Сделав все, что мог, с другими вариантами, предложенными в этом журнале, я пытаюсь выяснить, как уменьшить количество потоков в Jenkins для проверки теории перенаправления VM в потоке.

Edit # 2

Per Михал Grzejszczak, это проблема с Glibc распределенной с Red Hat Enterprise Linux 6, как описано here. Проблема может быть решена путем явной установки переменной окружения MALLOC_ARENA_MAX, в моем случае export MALLOC_ARENA_MAX=2. Без явной настройки этой переменной JVM, по-видимому, попытается порождать потоки ядра (8 x cpu core), каждый из которых потребляет 64M. Моему 40-ядерному корпусу потребовалось бы севернее 10 гигабайтов виртуального барана, превышающего (сам по себе) ulimit на моей машине 8 концертов. Установка этого параметра на 2 уменьшает потребление VM до 128 мегабайт.

Answer 1

Отпечаток памяти Jenkins связан скорее с количеством и размером проектов, которыми он управляет, чем количеством процессоров или доступной памяти. Дженкинс должен отлично работать на 1 Гб памяти кучи, если у вас нет гигантских проектов.

Возможно, вы неправильно сконфигурировали JVM. Параметры -Xmx и -Xms определяют пространство кучи, которое может использовать JVM. -Xmx - это предел для памяти кучи, -Xms - это начальное значение для памяти кучи. Куча - это единая область памяти для всей JVM. Вы можете легко контролировать его с помощью различных инструментов, таких как JConsole или VisualVM.

С другой стороны, -Xss не относится к куче. Это размер стека потоков для всех потоков в этом процессе JVM. Поскольку программы Java имеют тенденцию создавать множество потоков, этот параметр слишком велик, чтобы ваша программа не запускалась. Обычно это значение находится в диапазоне от 512 kb. Ввод здесь 512 m вместо этого делает невозможным запуск JVM. Убедитесь, что ваши настройки не содержат таких ошибок (и также разместите конфигурацию вашей памяти).