Closed aleksbykov closed 3 years ago
This nemesis is quite new nemesis (introduced in 4.2) to help testing the swap and memory locking configuration. What the nemesis does is trying to consume all the free memory in the system.
We will not chace this - the coredump is a bug in the JVM which is old
Scylla version: 4.2.rc4-0.20200923.2893f6e43 with build-id 35882560db8cf11bd2758115c78cb9be2bd1e49b timestamp: 2020-09-23T16:13:41Z git@github.com:scylladb/scylla.git-sha: 2893f6e43b2862e4a3e761bad6f5d8d1b5b0c45f git@github.com:scylladb/scylla-jmx.git-sha: ade4edaa20349c84cacd70e8caec1764986ed96d git@github.com:scylladb/scylla-tools-java.git-sha: cd0987292d82d78c4702e8300ff0b7db07e67c7f During the job https://jenkins.scylladb.com/job/scylla-4.2/job/longevity/job/longevity-100gb-4h-test/65/ on node 9 memory stress nemesis started. This nemesis try to allocate the memory:
1st command executed without errors:
2nd command execution triggered the scylla-jmx coredump:
Jmx coredump:
Messages from log:
db log:messages.zip