Capture cpu profile for keynote bench in nightly job#5163
Capture cpu profile for keynote bench in nightly job#5163joshua-spacetime wants to merge 2 commits into
Conversation
joshua-spacetime
requested review from
bfops,
cloutiertyler and
jdetter
as code owners
|
I'd like @jdetter to review this one. |
| name: keynote-bench-nightly-profile | ||
| path: ${{ env.KEYNOTE_PROFILE_DIR }} | ||
| if-no-files-found: warn | ||
| retention-days: 90 |
There was a problem hiding this comment.
Note for @jdetter: I'm not sure if or how much of an impact this will have on our github actions spend. Happy to reconfigure this. I would just like some level of cpu profile history for diagnostic purposes.
There was a problem hiding this comment.
This should be fine for now, if the spend here becomes too large then we can always move these to an S3 bucket or something
There was a problem hiding this comment.
How large are these artifacts?
joshua-spacetime
force-pushed
the
joshua/samply-keynote-bench
branch
from
4293798 to
e6e1c18
Compare
jdetter
left a comment
jdetter
left a comment
There was a problem hiding this comment.
Nothing blocking this from merging, just a few comments and a question
| name: keynote-bench-nightly-profile | ||
| path: ${{ env.KEYNOTE_PROFILE_DIR }} | ||
| if-no-files-found: warn | ||
| retention-days: 90 |
There was a problem hiding this comment.
This should be fine for now, if the spend here becomes too large then we can always move these to an S3 bucket or something
| name: keynote-bench-nightly-profile | ||
| path: ${{ env.KEYNOTE_PROFILE_DIR }} | ||
| if-no-files-found: warn | ||
| retention-days: 90 |
There was a problem hiding this comment.
How large are these artifacts?
| CARGO_TARGET_DIR: ${{ github.workspace }}/target | ||
| RUST_BACKTRACE: full | ||
| CARGO_TARGET_DIR: ${{ github.workspace }}/target | ||
| CARGO_PROFILE_RELEASE_DEBUG: line-tables-only |
There was a problem hiding this comment.
This may cause cargo cache misses with the new vm caching change but that's more of a me problem for later
| --release | ||
| -p spacetimedb-cli | ||
| -p spacetimedb-standalone | ||
| --features spacetimedb-standalone/perfmap |
There was a problem hiding this comment.
This will also probably cause a cache miss - if this workflow ends up being too slow I can bake a new cache with all of these options enabled so we're more likely to get a compilation cache hit.
There was a problem hiding this comment.
FWIW, I think --features spacetimedb-standalone/perfmap should be the default for all of our release builds.
| on: | ||
| schedule: | ||
| # Nightly at 3 AM UTC. | ||
| - cron: '0 3 * * *' |
There was a problem hiding this comment.
I would prefer this to run more around 8am UTC - when we do maintenance on the runners we typically like to do it in the middle of the night when nobody is working to reduce the impact on productivity. If you keep this as 3AM UTC you will just run the risk of it getting cancelled sometimes.
3 participants
Description of Changes
Also capture a cpu profile on a keynote bench job failure.
API and ABI breaking changes
N/A
Expected complexity level and risk
2
Testing