Та же среда (узел jenkins), более медленный исполняемый файл jar

Ну, это может быть вызвано самим приложением — например, если количество потоков зависит от количества доступных ядер, но накладные расходы на синхронизацию заглушают преимущества даже для небольшого количества потоков — это, очевидно, зависит от того, что делает приложение .

Не говоря уже о том, что есть и другие характеристики, которые могут иметь значение.

Иногда предоставление большего объема памяти также может замедлить работу (накладные расходы GC медленно увеличиваются с размером управляемой памяти и т. д. некоторые вещи, которые быстро выходят из строя с небольшим объемом памяти, требуют больше времени для сбоя с большим объемом памяти и множеством других эффектов).

Вы не предоставляете достаточно информации в своем вопросе. Что именно вы выполняете и какие процессоры используете? Если ваш код однопоточный, количество ядер ЦП не имеет значения, если ваш код связан с вводом-выводом, специфика вашего хранилища или даже скорость сети могут быть более актуальными. В зависимости от того, что вы выполняете, время доступа к вашей памяти может быть более важным, чем ее размер...

Я заметил, что вы сказали «vCPU», а не CPU. Обратите внимание, что производительность «виртуального ЦП» зависит от того, насколько занят вычислительный узел, а также от того, что другие виртуальные серверы могут делать на вычислительном узле. Это также может зависеть от того, насколько загружена дисковая часть сервера. Короче говоря, вам следует поговорить со своим провайдером облачных вычислений....

Всем привет. Извините за поздний комментарий. Я сравнил все настройки сервера на старом сервере узла с новым сервером и обнаружил, что конфигурация ssh была установлена ​​на старом сервере: StrictHostKeyChecking=no. Поэтому я добавил параметр на новый сервер узла, и задание выполняется вовремя, как я и ожидал. Спасибо вам за все.