Errored: apache/geode-examples#703 (rel/v1.15.0.RC0 - d494b12)
Build Update for apache/geode-examples - Build: #703 Status: Errored Duration: 58 secs Commit: d494b12 (rel/v1.15.0.RC0) Author: Owen Nichols Message: GEODE-10089: Bump version to 1.15.0 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.15.0.RC0 View the full build log and details: https://app.travis-ci.com/github/apache/geode-examples/builds/247180804?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807635_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Canceled: apache/geode-examples#701 (support/1.15 - d7974b3)
Build Update for apache/geode-examples - Build: #701 Status: Canceled Duration: ? Commit: d7974b3 (support/1.15) Author: Owen Nichols Message: GEODE-10089: Set temporary staging repo This serves two purposes: it gives the RC pipeline a way to get the nexus staging repo id needed for various tests, and it gives the Jenkins server a valid configuration during the voting period. View the changeset: https://github.com/apache/geode-examples/compare/0ba9282f00d8...d7974b38c7a3 View the full build log and details: https://app.travis-ci.com/github/apache/geode-examples/builds/247180797?utm_medium=notification_source=email Restart your build: https://app.travis-ci.com/github/apache/geode-examples/builds/247180797?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807635_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: Question about crossing NUMA boundary
The NUMA settings really only affects transient / non-shared objects. These are objects where the thread that allocated them is most likely to be the one to access them and in a short enough time span that the thread is not scheduled in a different NUMA zone core. Non-transient and shared objects may have to cross NUMA because there is no way to know what NUMA zones a scheduled thread will need to access. So if anything was going to show the affects it would be on something that generates lots of transient objects really fast. For that I would look to the geode-benchmark get server side tests. They do local gets on a server without a client and can produce lots of transient objects, though not as many as it used to. Run with and without NUMA settings and see what it yields. I recall doing this a while ago for one benchmark and non-NUMA performance wasn’t great compared to NUMA but I was specifically looking at issue regarding network buffer saturation in the kernel on 72 core machines. -Jake On Feb 28, 2022, at 12:39 PM, Alberto Gomez mailto:alberto.go...@est.tech>> wrote: Hi, We understand the recommendation is to fit the Geode JVM within one NUMA node for optimal performance, so in case we're running in a system with multiple NUMA nodes and our JVM can fit in the memory available in a single NUMA, it is recommended to pin it there ([1]). However, does anyone have any numbers to compare the performance of the same-sized Geode JVM when run on non-NUMA hardware vs run on NUMA hardware where JVM is spread on more NUMA nodes? Have you played with newer JDKs and GCs that have better NUMA awareness to quantify if the drop in performance could be reduced to acceptable levels? Thanks! Alberto [1]: https://geode.apache.org/docs/guide/114/managing/monitor_tune/performance_on_vsphere.html
Question about crossing NUMA boundary
Hi, We understand the recommendation is to fit the Geode JVM within one NUMA node for optimal performance, so in case we're running in a system with multiple NUMA nodes and our JVM can fit in the memory available in a single NUMA, it is recommended to pin it there ([1]). However, does anyone have any numbers to compare the performance of the same-sized Geode JVM when run on non-NUMA hardware vs run on NUMA hardware where JVM is spread on more NUMA nodes? Have you played with newer JDKs and GCs that have better NUMA awareness to quantify if the drop in performance could be reduced to acceptable levels? Thanks! Alberto [1]: https://geode.apache.org/docs/guide/114/managing/monitor_tune/performance_on_vsphere.html
1.15.0 release status update
One month after cutting support/1.15, Jira shows 5 blockers remaining [1]. Great work, keep those bug reports and fixes coming! This week I will be conducting a practice exercise of creating a 1.15.0.RC0 to test release scripts and pipelines. Please ignore this RC0 tag (no need to review or vote on it). Thanks, -Geode 1.15.0 Release Manager [1] https://issues.apache.org/jira/browse/GEODE-10063?jql=project%3DGEODE%20AND%20(labels%3Dblocks-1.15.0%E2%80%8B)%20AND%20resolution%20is%20empty
