chore: patch jsii-rosetta to limit the number of worker threads #14389
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jsii-rosetta uses multiple worker threads by default to speed up sample extraction. It defaults to spawning workers equal to half the number of cores. On extremely powerful build machines (e.g., CodeBuild X2_LARGE compute with 72 vCPUs), the high number of workers (36) results in thrash and high memory usage due to duplicate loads of source files. This was causing the v2 builds to fail with: "FATAL ERROR: NewSpace::Rebalance Allocation failed - JavaScript heap out of memory" The patch simply limits the top number of worker threads to an arbitrarily-chosen maximum limit of 16. We could simply disable the worker threads, but this takes much longer to process. With single-threading, rosetta takes ~35 minutes to extract samples from the CDK; with 16 workers, it takes ~3.5 minutes. I absolutely want to find the proper way to backfeed this into rosetta, but opting for the simple patch approach at the moment because our v2 builds have been blocked for about a week already.
|
|
RomainMuller
approved these changes
Apr 27, 2021
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
@Mergifyio backport master |
mergify bot
pushed a commit
that referenced
this pull request
Apr 27, 2021
jsii-rosetta uses multiple worker threads by default to speed up sample extraction. It defaults to spawning workers equal to half the number of cores. On extremely powerful build machines (e.g., CodeBuild X2_LARGE compute with 72 vCPUs), the high number of workers (36) results in thrash and high memory usage due to duplicate loads of source files. This was causing the v2 builds to fail with: "FATAL ERROR: NewSpace::Rebalance Allocation failed - JavaScript heap out of memory" The patch simply limits the top number of worker threads to an arbitrarily-chosen maximum limit of 16. We could simply disable the worker threads, but this takes much longer to process. With single-threading, rosetta takes ~35 minutes to extract samples from the CDK; with 16 workers, it takes ~3.5 minutes. I absolutely want to find the proper way to backfeed this into rosetta, but opting for the simple patch approach at the moment because our v2 builds have been blocked for about a week already. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* (cherry picked from commit 07fe771)
|
Command
|
njlynch
added a commit
to aws/jsii
that referenced
this pull request
Apr 27, 2021
The current behavior of rosetta (extract) is to use a number of node worker threads equal to half the number of CPU cores. On large CI/CD build hardware, this may mean creating a huge number of worker threads which causes more contention than benefit. Introduce JSII_ROSETTA_MAX_WORKER_COUNT to limit the maximum number of workers (defaults to 16). See aws/aws-cdk#14389 for more motivation from the AWS CDK.
mergify bot
added a commit
that referenced
this pull request
Apr 27, 2021
…port #14389) (#14393) This is an automatic backport of pull request #14389 done by [Mergify](https://mergify.io). --- <details> <summary>Mergify commands and options</summary> <br /> More conditions and actions can be found in the [documentation](https://docs.mergify.io/). You can also trigger Mergify actions by commenting on this pull request: - `@Mergifyio refresh` will re-evaluate the rules - `@Mergifyio rebase` will rebase this PR on its base branch - `@Mergifyio update` will merge the base branch into this PR - `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch Additionally, on Mergify [dashboard](https://dashboard.mergify.io/) you can: - look at your merge queues - generate the Mergify configuration with the config editor. Finally, you can contact us on https://mergify.io/ </details>
njlynch
added a commit
to aws/jsii
that referenced
this pull request
Apr 27, 2021
The current behavior of rosetta (extract) is to use a number of node worker threads equal to half the number of CPU cores. On large CI/CD build hardware, this may mean creating a huge number of worker threads which causes more contention than benefit. Introduce JSII_ROSETTA_MAX_WORKER_COUNT to limit the maximum number of workers (defaults to 16). See aws/aws-cdk#14389 for more motivation from the AWS CDK.
mergify bot
pushed a commit
to aws/jsii
that referenced
this pull request
Apr 27, 2021
The current behavior of rosetta (extract) is to use a number of node worker threads equal to half the number of CPU cores. On large CI/CD build hardware, this may mean creating a huge number of worker threads which causes more contention than benefit. Introduce `JSII_ROSETTA_MAX_WORKER_COUNT` to limit the maximum number of workers (defaults to `16`). See aws/aws-cdk#14389 for more motivation from the AWS CDK. --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
john-tipper
pushed a commit
to john-tipper/aws-cdk
that referenced
this pull request
May 10, 2021
…port aws#14389) (aws#14393) This is an automatic backport of pull request aws#14389 done by [Mergify](https://mergify.io). --- <details> <summary>Mergify commands and options</summary> <br /> More conditions and actions can be found in the [documentation](https://docs.mergify.io/). You can also trigger Mergify actions by commenting on this pull request: - `@Mergifyio refresh` will re-evaluate the rules - `@Mergifyio rebase` will rebase this PR on its base branch - `@Mergifyio update` will merge the base branch into this PR - `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch Additionally, on Mergify [dashboard](https://dashboard.mergify.io/) you can: - look at your merge queues - generate the Mergify configuration with the config editor. Finally, you can contact us on https://mergify.io/ </details>
hollanddd
pushed a commit
to hollanddd/aws-cdk
that referenced
this pull request
Aug 26, 2021
…port aws#14389) (aws#14393) This is an automatic backport of pull request aws#14389 done by [Mergify](https://mergify.io). --- <details> <summary>Mergify commands and options</summary> <br /> More conditions and actions can be found in the [documentation](https://docs.mergify.io/). You can also trigger Mergify actions by commenting on this pull request: - `@Mergifyio refresh` will re-evaluate the rules - `@Mergifyio rebase` will rebase this PR on its base branch - `@Mergifyio update` will merge the base branch into this PR - `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch Additionally, on Mergify [dashboard](https://dashboard.mergify.io/) you can: - look at your merge queues - generate the Mergify configuration with the config editor. Finally, you can contact us on https://mergify.io/ </details>
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
jsii-rosetta uses multiple worker threads by default to speed up sample
extraction. It defaults to spawning workers equal to half the number of
cores. On extremely powerful build machines (e.g., CodeBuild X2_LARGE compute
with 72 vCPUs), the high number of workers (36) results in thrash and high
memory usage due to duplicate loads of source files. This was causing the v2
builds to fail with:
"FATAL ERROR: NewSpace::Rebalance Allocation failed - JavaScript heap out of memory"
The patch simply limits the top number of worker threads to an
arbitrarily-chosen maximum limit of 16. We could simply disable the worker
threads, but this takes much longer to process. With single-threading, rosetta
takes ~35 minutes to extract samples from the CDK; with 16 workers, it takes
~3.5 minutes.
I absolutely want to find the proper way to backfeed this into rosetta, but
opting for the simple patch approach at the moment because our v2 builds have
been blocked for about a week already.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license