Мне было интересно, почему вы используете древнюю копию Perl, тогда я понимаю, что вы используете продукты IBM Rational - может быть, даже ClearCase. Теперь я чувствую вашу боль.
Очевидным ответом является то, что ваш скрипт Perl едет в памяти каждый раз, когда он вызывает Win32::Process:Create. Это особенно верно, если старый процесс еще не умер, прежде чем вызывать новый процесс. Если вы посмотрите на Диспетчер задач, вы сможете увидеть, как ресурсы будут съедаться при каждом вызове.
Почему вы получаете эту проблему сейчас, а не раньше? Возможно, ваши сборки становятся более сложными или занимают больше времени. Раньше, возможно, сборки заканчивались, пока вы не создавали новых.
Вы можете использовать Activity Monitor для просмотра памяти и других ресурсов или загрузить Sysinternals tools от Microsoft, что позволит вам углубиться в проблему.
Вы можете взглянуть на Средство просмотра событий и посмотреть, есть ли что-нибудь еще, что он вам скажет.
Есть две рекомендации я могу сделать:
- Используйте новую версию Perl. Возможно, ваша версия Perl имеет некоторую утечку памяти. Вы можете загрузить более новую версию Perl, которая может помочь. Проблема в том, что если вы используете инструменты Rational, вы не можете избавиться от старого. Вы можете установить две версии в двух разных местах, но вам нужно будет убедиться, что вы используете правильную версию.
- Еще одна возможность - переключиться на использование Jenkins в качестве инструмента построения вместо использования вашего Perl-скрипта.
Jenkins прост в установке и дает вам больше возможностей в управлении процессом сборки. Путь по умолчанию (и это не то, что Дженкинс настроен так, чтобы это делалось так, как это обычно делается с большинством людей) заключается в том, чтобы сбивать сборку каждый раз, когда происходит изменение. Однако вы можете сделать это вручную, в определенное время суток или даже путем попадания на определенный URL-адрес. Последнее удобно, когда вы хотите сэкономить дюжину или около того сборок в одно и то же время. Один скрипт может сделать это за вас.
Главное преимущество заключается в том, что Jenkins будет стоять в очереди на сборки, чтобы не перегружать ресурсы вашей системы сборки. Например, у вас могут быть 3 или 4 исполнителя сборки, и только 3 или 4 сборки будут выполнены одновременно. Любая другая сборка, которую вы запускаете, просто ждет следующего бесплатного исполнителя. У вас может быть всего один исполнитель, или столько, сколько ... У меня было до 16 одновременно.
Возможно, будет легко перейти на использование Дженкинса. Дженкинс занимает от 10 до 20 минут, чтобы настроить (и я включил загрузку Jenkins из Интернета в этом тоже.) Настройка проекта сборки выполняется быстро, и вы, вероятно, можете использовать ту же самую команду, которую используете, чтобы отключить сборку слишком. Если это проект .NET, вы можете загрузить плагин MSBuild для Jenkins.
Спасибо за подробный ответ! Мы на самом деле используем рациональные инструменты (мы перешли на git для большинства репозиториев, но все еще застряли в CC для более старых). У нас также есть Jenkins (это там, где сбои не срабатывали). Однако, может быть, мы используем Дженкинса неправильно? Мы просто используем его для запуска этих скриптов perl для нас ... – MrDuk
Какие проекты вы строите? Я предположил, что ваш скрипт Perl запускает сразу несколько разных сборок - одна сборка за 'Win32 :: Process :: Create'. –
Просто построение одного проекта win64 C++ - процесс создания - это то, что мы можем сделать вид потоковой сборки. – MrDuk