[jira] [Commented] (IGNITE-3905) Optimize RendezvousAffinityFunction

2017-01-10 Thread Taras Ledkov (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814302#comment-15814302
 ] 

Taras Ledkov commented on IGNITE-3905:
--

The results of optimization is available at the IGNITE-3018.

> Optimize RendezvousAffinityFunction
> ---
>
> Key: IGNITE-3905
> URL: https://issues.apache.org/jira/browse/IGNITE-3905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, community, general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently RendezvousAffinityFunction.assignPartition generates a lot of 
> garbage if called very often, on example in case of rebalancing a lot of 
> caches.
> This causes excessive pressure on GC, which is not always fast enough to 
> clear memory, producing long GC pauses leading to node segmentation.
> We should cache calculation of nodeHashBytes in node attribute or resort to 
> more efficient node hash calculation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3905) Optimize RendezvousAffinityFunction

2016-09-28 Thread Andrey Gura (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529389#comment-15529389
 ] 

Andrey Gura commented on IGNITE-3905:
-

One more idea for increase perfromance. In case of partitioned cache we usually 
have a few backups so sorting of all nodes is redundant. We can just find a 
{{backups + 1}} minimal ellements in collection if {{nodes * (backups + 1)}} < 
{{nodes * log(nodes)}}.

> Optimize RendezvousAffinityFunction
> ---
>
> Key: IGNITE-3905
> URL: https://issues.apache.org/jira/browse/IGNITE-3905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, community, general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently RendezvousAffinityFunction.assignPartition generates a lot of 
> garbage if called very often, on example in case of rebalancing a lot of 
> caches.
> This causes excessive pressure on GC, which is not always fast enough to 
> clear memory, producing long GC pauses leading to node segmentation.
> We should cache calculation of nodeHashBytes in node attribute or resort to 
> more efficient node hash calculation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3905) Optimize RendezvousAffinityFunction

2016-09-15 Thread Andrey Gura (JIRA) 

[ 
https://issues.apache.org/jira/browse/IGNITE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492900#comment-15492900
 ] 

Andrey Gura commented on IGNITE-3905:
-

One thing that can be made: {{lsn}} variable in {{assignPartition}} method can 
be replcaed by array and {{Collections.sort()}} call can be replaced by 
{{Arrays.sort()}}. {{Collections.sort()}} creates new array instance and it can 
be avoided.

See also IGNITE-3018.

> Optimize RendezvousAffinityFunction
> ---
>
> Key: IGNITE-3905
> URL: https://issues.apache.org/jira/browse/IGNITE-3905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, community, general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently RendezvousAffinityFunction.assignPartition generates a lot of 
> garbage if called very often, on example in case of rebalancing a lot of 
> caches.
> This causes excessive pressure on GC, which is not always fast enough to 
> clear memory, producing long GC pauses leading to node segmentation.
> We should cache calculation of nodeHashBytes in node attribute or resort to 
> more efficient node hash calculation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)