You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When @ryanaslett and I were setting up these new instances, we noticed that total build time was significantly affected by caching. When the cache empty or invalidated the builds would take significantly longer (around 3+h). Builds with valid cache will take about 30-40m (IIRC).
I don’t really understand what the caching situation is, Ryan may be able to share more details. But to my knowledge this isn’t an OS controlled behavior.
If someone who is more familiar with the build system and the caching model is available and up to it, we can try to help debug this live to figure out what’s going on.
Do you have a specific build log where it took 6h with a known valid cache that I could look at? I would definitely want to start by looking at that log before attempting to replicate it.
Do you have a specific build log where it took 6h with a known valid cache that I could look at? I would definitely want to start by looking at that log before attempting to replicate it.
The closest I can find right now is URLPattern PR. It is still building for almost 4 hours and didn't start running the tests...
Yes but that shows that our smartOS machine count is not sufficient enough to handle our CI run which impacts the PR time to land. URLPattern PR shares an example where it takes more than 4 hours...
Yes but that shows that our smartOS machine count is not sufficient enough to handle our CI run which impacts the PR time to land. URLPattern PR shares an example where it takes more than 4 hours...
How many runners do you suggest? We can create more.
#/bin/bash -xe
curl https://raw.githubusercontent.com/nodejs/build/main/jenkins/scripts/node-test-commit-pre.sh | bash -ex -s before
export CCACHE_BASEDIR=$(pwd)
export CC="ccache gcc"
export CXX="ccache g++"
# Need to add this to ENV var to make behaviors match between smart os platforms: See: https://github.com/nodejs/build/issues/3731#issuecomment-2546193074
export CXXFLAGS="${CXXFLAGS} -fno-zero-initialized-in-bss"
curl -sLO https://raw.githubusercontent.com/nodejs/build/main/jenkins/scripts/select-compiler.sh
. ./select-compiler.sh
# configure will pick the correct version of Python to use on all currently supported Node.js versions.
# Starting from SmartOS 20 the unversioned `python` is Python 3 which doesn't work with Node.js 12.
./configure
JOBS=4 NODE_TEST_DIR=${HOME}/node-tmp NODE_COMMON_PORT=15000 FLAKY_TESTS=dontcare TEST_CI_ARGS="-t 300" make run-ci -j $JOBS
curl https://raw.githubusercontent.com/nodejs/build/main/jenkins/scripts/node-test-commit-diagnostics.sh | bash -ex -s after
The build went fine (in less than 15 minutes!), so the cache was probably hot.
But then the documentation generation failed with an out of memory error from V8.
We may need a larger RSS or swap cap on the containers. Is there a document that describes the resource usage of the build? How are the sizes and resource limits chosen for CI runners on other platforms?
For follow up later on I think that JOBS was being set through ansible when it configures the jenkins agent on a machine.
In terms of resources, I don't know if that is written down, but 8G and 4CPU is in the general category if not a bit higher. I do know that @richardlau has added additional swap to some machines.
On some machines we do see that with higher parallelism we can run out of memory with v8 using more as more threads are available. (Edit and maybe that is what happend with the doc generation as well)
@jclulow, @bahamat if we can just up the available memory to get it running with -J4 and then investigate how to better tune that would be great.
In terms of resources, I don't know if that is written down, but 8G and 4CPU is in the general category if not a bit higher. I do know that @richardlau has added additional swap to some machines.
These instances have 7GB (a consequence of running a zone in a VM) and 4 cpus. So we're in the neighborhood, although not quite where we'd like.
@jclulow, @bahamat if we can just up the available memory to get it running with -J4 and then investigate how to better tune that would be great.
I'm working on resizing these to give them ore resources. @jclulow and I were thinking around 12GB for the instances should do it.
And a significantly higher swap allowance as well, to account for differences in memory overcommit between Linux and illumos, and for the fact that /tmp is tmpfs/swap-backed on illumos, etc.
I don't think there's more protocol than using a GitHub issue. I suggest we do it when the CI is relatively quiet. You just need someone from @nodejs/jenkins-admins to put the workers offline during the operation.
I had to rebuild some of the smartOS machines in support of another effort, and now all the machines are configured to use the available ram on the instances (not sure if that was the right way to do this).
They are currently running in around 45 minutes which seems on par with the rest of the infrastructure.
@bahamat / @jclulow Can you review the docs I put together #4055 ? These are the steps I've had to go through to provision a new smartos machine. Some of those steps may be able to be moved to ansible, and perhaps something can be done on the smartos side to not require a custom legacy image as well.
Ideally we'd have a more finished base image with python etc already installed.
I believe we can close this issue given that we've got builds under control.
Activity
bahamat commentedon Jan 31, 2025
When @ryanaslett and I were setting up these new instances, we noticed that total build time was significantly affected by caching. When the cache empty or invalidated the builds would take significantly longer (around 3+h). Builds with valid cache will take about 30-40m (IIRC).
I don’t really understand what the caching situation is, Ryan may be able to share more details. But to my knowledge this isn’t an OS controlled behavior.
If someone who is more familiar with the build system and the caching model is available and up to it, we can try to help debug this live to figure out what’s going on.
targos commentedon Jan 31, 2025
Merging nodejs/node#55014 completely invalidated the cache.
anonrig commentedon Jan 31, 2025
There are even cases where it takes 6 hours: https://ci.nodejs.org/job/node-test-commit-smartos/58762/
anonrig commentedon Jan 31, 2025
There are examples where the builds take 6 hours. Even with or without ccache, I think there is something wrong.
[-]smartOS builds are taking more than 3.5 hours[/-][+]smartOS builds are taking more than 6 hours[/+]bahamat commentedon Jan 31, 2025
Do you have a specific build log where it took 6h with a known valid cache that I could look at? I would definitely want to start by looking at that log before attempting to replicate it.
targos commentedon Jan 31, 2025
@anonrig The number on the top-right of these pages includes the time that the job was waiting for available machines. The jobs themselves (https://ci.nodejs.org/job/node-test-commit-smartos/58762/nodes=smartos22-x64/ and https://ci.nodejs.org/job/node-test-commit-smartos/58762/nodes=smartos23-x64/) didn't take that long.
bahamat commentedon Jan 31, 2025
This is useful information, and is definitely a significant contributor to what’s going on.
How does this cache affect other builds?
anonrig commentedon Jan 31, 2025
The closest I can find right now is URLPattern PR. It is still building for almost 4 hours and didn't start running the tests...
targos commentedon Jan 31, 2025
But I agree that more than 4 hours to build without cache doesn't seem reasonable. Are those executors on particularly old or undersized hardware?
anonrig commentedon Jan 31, 2025
Yes but that shows that our smartOS machine count is not sufficient enough to handle our CI run which impacts the PR time to land. URLPattern PR shares an example where it takes more than 4 hours...
bahamat commentedon Jan 31, 2025
They have 8GB of RAM and 4 CPUs. If it needs to be increased, I can do that.
bahamat commentedon Jan 31, 2025
How many runners do you suggest? We can create more.
targos commentedon Jan 31, 2025
https://ci.nodejs.org/view/All/job/node-test-commit-smartos/nodes=smartos22-x64/58957/consoleFull
It looks like only one CPU is used??? I don't know which will take precedence between
-j 1andJOBS=4Also, it seems that
./configureis called once for nothing beforemake run-ci(which calls it again)targos commentedon Jan 31, 2025
https://ci.nodejs.org/view/All/job/node-test-commit-smartos/configure contains:
17 remaining items
targos commentedon Jan 31, 2025
I don't know if you can.
targos commentedon Jan 31, 2025
I think the parallelism is working on https://ci.nodejs.org/job/node-test-commit-smartos/58964/nodes=smartos23-x64/ (by looking at the timestamps of log lines)
targos commentedon Jan 31, 2025
The build went fine (in less than 15 minutes!), so the cache was probably hot.
But then the documentation generation failed with an out of memory error from V8.
jclulow commentedon Jan 31, 2025
We may need a larger RSS or swap cap on the containers. Is there a document that describes the resource usage of the build? How are the sizes and resource limits chosen for CI runners on other platforms?
mhdawson commentedon Jan 31, 2025
For follow up later on I think that JOBS was being set through ansible when it configures the jenkins agent on a machine.
In terms of resources, I don't know if that is written down, but 8G and 4CPU is in the general category if not a bit higher. I do know that @richardlau has added additional swap to some machines.
On some machines we do see that with higher parallelism we can run out of memory with v8 using more as more threads are available. (Edit and maybe that is what happend with the doc generation as well)
@jclulow, @bahamat if we can just up the available memory to get it running with -J4 and then investigate how to better tune that would be great.
targos commentedon Jan 31, 2025
That's for building V8. I'm very surprised to see an error at the doc building step, which should not be done in parallel with anything else.
mhdawson commentedon Jan 31, 2025
Not sure then, worth re-running so see if it was a one-off ?
targos commentedon Jan 31, 2025
The other build didn't fail and is now running tests: https://ci.nodejs.org/job/node-test-commit-smartos/58964/nodes=smartos22-x64/console
bahamat commentedon Feb 1, 2025
These instances have 7GB (a consequence of running a zone in a VM) and 4 cpus. So we're in the neighborhood, although not quite where we'd like.
I'm working on resizing these to give them ore resources. @jclulow and I were thinking around 12GB for the instances should do it.
jclulow commentedon Feb 1, 2025
And a significantly higher swap allowance as well, to account for differences in memory overcommit between Linux and illumos, and for the fact that
/tmpis tmpfs/swap-backed on illumos, etc.bahamat commentedon Feb 1, 2025
@targos @mhdawson @ryanaslett I need to reboot the SmartOS jenkins instances in order to apply the new memory settings.
Is there a protocol for requesting down time?
targos commentedon Feb 1, 2025
I don't think there's more protocol than using a GitHub issue. I suggest we do it when the CI is relatively quiet. You just need someone from @nodejs/jenkins-admins to put the workers offline during the operation.
jasnell commentedon Feb 1, 2025
Thank you @bahamat and @jclulow for the effort on this
ryanaslett commentedon Mar 30, 2025
I had to rebuild some of the smartOS machines in support of another effort, and now all the machines are configured to use the available ram on the instances (not sure if that was the right way to do this).
They are currently running in around 45 minutes which seems on par with the rest of the infrastructure.
@bahamat / @jclulow Can you review the docs I put together #4055 ? These are the steps I've had to go through to provision a new smartos machine. Some of those steps may be able to be moved to ansible, and perhaps something can be done on the smartos side to not require a custom legacy image as well.
Ideally we'd have a more finished base image with python etc already installed.
I believe we can close this issue given that we've got builds under control.