Вопросы Теги

Jenkins CI - Не может выделить память

1) Резервное копирование.

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

2) Прочитайте руководство, позвоните поставщику и т.д.

Различные системы RAID имеют различные шаги для замены диска, и сделанный неправильно Вы рискуете уничтожать целый массив. Не зная, какие аппаратные средства/программное обеспечение RAID Вы имеете, мы можем только предположить необходимые шаги.

Кроме того, медленная производительность состоит в том потому что RAID 5 в ухудшенном состоянии (т.е.: один мертвый диск), имеет ужасную производительность чтения. То, как ужасный зависит от того, как четность хранится и какой диск умер, но "хорошие" новости являются медленной производительностью с одним диском, который уводят, является известной проблемой, и не вызывают для паники.

9
задан 29 September 2011 в 23:03
3 ответа

Вероятно, что ANT_OPTS переопределены Jenkins. Вы также можете установить параметры непосредственно в файле сборки, чтобы вы могли контролировать выделение памяти независимо от среды (оболочка, Jenkins, ...). В вашем файле сборки (пример: 

<java fork="true" classname="..." >
    <jvmarg line="-Xms512M -Xmx512M" />
0
ответ дан 2 December 2019 в 22:31

Обратите внимание на сообщение об исключении: Невозможно запустить программу «/ usr / bin / env»: java.io.IOException: error = 12, Невозможно выделить память » Процесс Java пытается разветвить новый процесс для выполнения команды / usr / bin / env , но в операционной системе закончились ресурсы памяти для создания нового процесса. Это не то же самое, что заканчивается Java VM памяти, поэтому никакие манипуляции с флагами -Xmx не помогут. Вам нужно будет контролировать ресурсы памяти во время выполнения сборки. Увеличение пространства подкачки, скорее всего, решит вашу проблему.

1
ответ дан 2 December 2019 в 22:31

Ориен верен, это системный вызов fork (), инициированный ProcessBuilder или Runtime.exec или другими средствами JVM, выполняющими внешний процесс (например, другая JVM, работающая под управлением ant, git команда и т. д.).

В списках рассылки Jenkins было несколько сообщений об этом: Невозможно запустить программу "git" ... error = 12, Невозможно выделить память

Есть хорошее описание проблема в списке разработчиков SCons: fork () + exec () vs posix_spawn ()

Существует давний отчет об ошибке JVM с решениями: Используйте posix_spawn, а не fork, на S10, чтобы избежать подкачки истощение . Но я не уверен, действительно ли это вошло в JDK7, поскольку комментарии предполагают, что это был план.

Таким образом, в Unix-подобных системах, когда одному процессу (например, JVM) необходимо запустить другой процесс (например, git), выполняется системный вызов fork () , который эффективно дублирует текущий процесс. и всю его память (Linux и другие оптимизируют это с помощью копирования при записи, поэтому память фактически не копируется, пока дочерний элемент не попытается записать в нее). Затем дублированный процесс выполняет другой системный вызов, exec () , чтобы запустить другой процесс (например, git), после чего вся скопированная память из родительского процесса может быть отброшена операционной системой. Если родительский процесс использует большой объем памяти (как это обычно делают процессы JVM), вызов fork () может завершиться ошибкой, если операционная система определит, что у нее недостаточно памяти + своп для хранения двух копий. , даже если дочерний процесс никогда не будет использовать эту скопированную память.

Есть несколько решений:

  • Добавьте больше физической памяти / RAM на машину.

  • Добавьте больше места подкачки, чтобы обмануть fork () в работу, хотя пространство подкачки ни для чего строго не требуется. Это решение, которое я выбрал, потому что добавить файл подкачки довольно просто, и я не хотел жить с возможностью остановки процессов из-за чрезмерной фиксации.

  • В Linux включите параметр overcommit_memory в меню система vm ( / proc / sys / vm / overcommit_memory ). С overcommit вызов fork () всегда будет успешным, и, поскольку дочерний процесс на самом деле не будет использовать эту копию памяти, все в порядке. Конечно, возможно, что из-за чрезмерной нагрузки ваши процессы фактически попытаются использовать больше памяти, чем доступно, и будут уничтожены ядром. Уместно ли это, зависит от других вариантов использования машины. Критически важные машины, вероятно, не должны рисковать выходом из-под контроля нехватки памяти. Но внутренний сервер разработки, который может позволить себе некоторое время простоя, был бы хорошим местом для включения чрезмерной нагрузки.

  • Измените JVM, чтобы не использовать fork () + exec () , но использовать posix_spawn () , если доступно. Это решение, запрошенное в отчете об ошибке JVM выше и упомянутое в списке рассылки SCons. Это также реализовано в java_posix_spawn .

    Я пытаюсь выяснить, вошло ли это исправление в JDK7. Если нет, мне интересно, были бы люди из Дженкинса заинтересованы в такой работе, как java_posix_spawn. Похоже, были попытки интегрировать это в Apache commons-exec .

    Programmieraffe, я не уверен на 100%, но ваша ссылка действительно предполагает, что исправление находится в JDK7 и JDK6 1.6.0_23 и позже. Для справки, я использовал OpenJDK 1.6.0_18.

См. https://stackoverflow.com/questions/1124771/how-to-solve-java-io-ioexception-error-12-cannot-allocate -memory-call-run

10
ответ дан 2 December 2019 в 22:31

Теги

Похожие вопросы