cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hanna (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-14847) improvement of nodetool status -r
Date Mon, 29 Oct 2018 16:29:28 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-14847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jeremy Hanna updated CASSANDRA-14847:
-------------------------------------
    Description: 
Hello,

When using "nodetool status -r", I found a problem that the response time becomes longer depending
on the number of vnodes.
 In my testing environment, when the num_token is 256 and the number of nodes is 6, the response
takes about 60 seconds.

It turned out that the findMaxAddressLength method in status.java is causing the delay.
 Despite only obtaining the maximum length of the address by the number of vnodes, `tokenrange
* vnode` times also loop processing, there is redundancy.

To prevent duplicate host names from being referenced every time, I modified to check with
hash.
 In my environment, the response time has been reduced from 60 seconds to 2 seconds.

I attached the patch, so please check it.
 Thank you
{code:java}
[before]
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******

time : 66s

[after]
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******

time : 2s
{code}

  was:
Hello,

When using "nodetool -r", I found a problem that the response time becomes longer depending
on the number of vnodes.
 In my testing environment, when the num_token is 256 and the number of nodes is 6, the response
takes about 60 seconds.

It turned out that the findMaxAddressLength method in status.java is causing the delay.
 Despite only obtaining the maximum length of the address by the number of vnodes, `tokenrange
* vnode` times also loop processing, there is redundancy.

To prevent duplicate host names from being referenced every time, I modified to check with
hash.
 In my environment, the response time has been reduced from 60 seconds to 2 seconds.

I attached the patch, so please check it.
 Thank you
{code:java}
[before]
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******

time : 66s

[after]
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******

time : 2s
{code}


> improvement of nodetool status -r
> ---------------------------------
>
>                 Key: CASSANDRA-14847
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14847
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Fumiya Yamashita
>            Priority: Major
>             Fix For: 3.11.x
>
>         Attachments: 3.11.1.patch
>
>
> Hello,
> When using "nodetool status -r", I found a problem that the response time becomes longer
depending on the number of vnodes.
>  In my testing environment, when the num_token is 256 and the number of nodes is 6, the
response takes about 60 seconds.
> It turned out that the findMaxAddressLength method in status.java is causing the delay.
>  Despite only obtaining the maximum length of the address by the number of vnodes, `tokenrange
* vnode` times also loop processing, there is redundancy.
> To prevent duplicate host names from being referenced every time, I modified to check
with hash.
>  In my environment, the response time has been reduced from 60 seconds to 2 seconds.
> I attached the patch, so please check it.
>  Thank you
> {code:java}
> [before]
> Datacenter: dc1
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
> UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
> UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
> UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
> UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
> UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******
> time : 66s
> [after]
> Datacenter: dc1
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN ******* 559.32 KB 256 48.7% 0555746a-60c2-4717-b042-94ba951ef679 *******
> UN ******* 721.48 KB 256 51.4% 1af4acb6-e0a0-4bcb-8bba-76ae2e225cd5 *******
> UN ******* 699.98 KB 256 48.3% 5215c728-9b80-4e3c-b46b-c5b8e5eb753f *******
> UN ******* 691.65 KB 256 48.1% 57da4edf-4acb-474d-b26c-27f048c37bd6 *******
> UN ******* 705.66 KB 256 52.8% 07520eab-47d2-4f5d-aeeb-f6e599c9b084 *******
> UN ******* 610.87 KB 256 50.7% 6b39acaf-6ed6-42e4-a357-0d258bdf87b7 *******
> time : 2s
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message