Высокая загрузка сервера
вывод "w" не помогает здесь очень. Отправьте вывод "vmstat 1" в течение первых 15-30 секунд, он дает намного более глубокое понимание. Сколько файлов находится в Вашем проекте Java? Действительно ли все доступно локально? Или Гудзон проверяет материал из в другом месте или копирует что-то с сети?
Вы выполняете Гудзон как автономное приложение или в веб-контейнере, например, Tomcat?
Одна мысль, которая приходит на ум, является выделением памяти для Вашего процесса Java. Если Вы не указывали дополнительные параметры памяти для JVM (-Xms и-Xmx опции), может случиться так, что выполнения JVM со значением по умолчанию 65M и сборка "мусора" умирают в той точке и останавливают Вашу систему.
Если у Вас есть возможность проверить Ваши опции во время выполнения (Ваш "PS" произвел выше, является усеченным справа, таким образом, я не вижу для меня), Вы могли проверить, является ли это первопричиной. Если это, Вы могли бы хотеть добавить больше памяти к процессу и видеть, останавливается ли это все еще в таком сценарии.
Это действительно кажется, что Ваш сервер съедает всю память и начинает подкачивать. Вы уверены в использовании памяти при компиляции? Javac легко ест несколько концертов... Я продолжил бы TOP и проверил бы то, что использование памяти посредством процесса сборки. После того как сервер начинает жевать диск из-за активных процессов, он не будет обычно отвечать, но можно часто видеть увеличение использования памяти, пока сервер не начинает Подкачивать
Другой простой способ протестировать это состоит в том, чтобы отключить Свопинг:
swapoff /dev/sda2 (or whatever your swap partition is called)
И затем попробуйте сборку. Если у Вас закончится память, то сборка, вероятно, умрет на полпути. Также возможно, что другой процесс, съедая большую память уничтожается Уничтожителем OOM в Linux.