[
https://issues.apache.org/jira/browse/CASSANDRA-10730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036284#comment-15036284
]
Jim Witschey commented on CASSANDRA-10730:
------------------------------------------
Looking at the build #19's console in flight, I'm seeing output like this:
{code}
17:30:29 /usr/lib/jvm/jdk1.8.0_45/bin/jmap stdout:
17:30:29 Attaching to process ID 22370, please wait...
17:30:29 Debugger attached successfully.
17:30:29 Server compiler detected.
17:30:29 JVM version is 25.45-b02
17:30:29
17:30:29 using parallel threads in the new generation.
17:30:29 using thread-local object allocation.
17:30:29 Concurrent Mark-Sweep GC
17:30:29
17:30:29 Heap Configuration:
17:30:29 MinHeapFreeRatio = 40
17:30:29 MaxHeapFreeRatio = 70
17:30:29 MaxHeapSize = 524288000 (500.0MB)
17:30:29 NewSize = 52428800 (50.0MB)
17:30:29 MaxNewSize = 52428800 (50.0MB)
17:30:29 OldSize = 471859200 (450.0MB)
17:30:29 NewRatio = 2
17:30:29 SurvivorRatio = 8
17:30:29 MetaspaceSize = 21807104 (20.796875MB)
17:30:29 CompressedClassSpaceSize = 1073741824 (1024.0MB)
17:30:29 MaxMetaspaceSize = 17592186044415 MB
17:30:29 G1HeapRegionSize = 0 (0.0MB)
17:30:29
17:30:29 Heap Usage:
17:30:29 New Generation (Eden + 1 Survivor Space):
17:30:29 capacity = 47185920 (45.0MB)
17:30:29 used = 16887904 (16.105560302734375MB)
17:30:29 free = 30298016 (28.894439697265625MB)
17:30:29 35.790134006076386% used
17:30:29 Eden Space:
17:30:29 capacity = 41943040 (40.0MB)
17:30:29 used = 11645024 (11.105560302734375MB)
17:30:29 free = 30298016 (28.894439697265625MB)
17:30:29 27.763900756835938% used
17:30:29 From Space:
17:30:29 capacity = 5242880 (5.0MB)
17:30:29 used = 5242880 (5.0MB)
17:30:29 free = 0 (0.0MB)
17:30:29 100.0% used
17:30:29 To Space:
17:30:29 capacity = 5242880 (5.0MB)
17:30:29 used = 0 (0.0MB)
17:30:29 free = 5242880 (5.0MB)
17:30:29 0.0% used
17:30:29 concurrent mark-sweep generation:
17:30:29 capacity = 471859200 (450.0MB)
17:30:29 used = 13839168339227 MB
17:30:29 free = 3935324293707312952 (3.7530177056382305E12MB)
17:30:29 -8.340039344862734E11% used
17:30:29
17:30:29 14570 interned Strings occupying 1998248 bytes.
{code}
I'm concerned in particular about the
{code}
17:30:29 Heap Configuration:
...
17:30:29 MaxHeapSize = 524288000 (500.0MB)
{code}
Does this mean our assumption that the JVM's heap is always at least 1G is
incorrect?
> periodic timeout errors in dtest
> --------------------------------
>
> Key: CASSANDRA-10730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10730
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jim Witschey
> Assignee: Jim Witschey
>
> Dtests often fail with connection timeout errors. For example:
> http://cassci.datastax.com/job/cassandra-3.1_dtest/lastCompletedBuild/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3/deletion_test/
> {code}
> ('Unable to connect to any servers', {'127.0.0.1':
> OperationTimedOut('errors=Timed out creating connection (10 seconds),
> last_host=None',)})
> {code}
> We've merged a PR to increase timeouts:
> https://github.com/riptano/cassandra-dtest/pull/663
> It doesn't look like this has improved things:
> http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/363/testReport/
> Next steps here are
> * to scrape Jenkins history to see if and how the number of tests failing
> this way has increased (it feels like it has). From there we can bisect over
> the dtests, ccm, or C*, depending on what looks like the source of the
> problem.
> * to better instrument the dtest/ccm/C* startup process to see why the nodes
> start but don't successfully make the CQL port available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
