[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-07-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-8681:


Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/4110


> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.7
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-07-03 Thread Ivan Rakov (JIRA)


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

Ivan Rakov commented on IGNITE-8681:


Thanks for your contribution! Merged to master.

> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.7
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-06-06 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov commented on IGNITE-8681:
--

I believe this failure caused by throttling for in-memory mode. I've disable it 
and re-run test [1].



We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart. 
I'm in the middle of investigation and seems, we have a bug in 
GridCacheMapEntry.innerGet0() method that ignores entry expiration is some 
cases. Most probably, this bug is causes TCK test failures.

 

[1]https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck

> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.6
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-06-05 Thread Ivan Rakov (JIRA)


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

Ivan Rakov commented on IGNITE-8681:


[~amashenkov], code changes look good. However, there are some suspicious test 
fails:
IgniteClientNodesTestSuite: 
IgniteClientReconnectFailoverTest.testReconnectStreamerApi (fail rate 0,0%)
org.jsr107.tck.expiry.CacheExpiryTest.expire_whenAccessed (fail rate 0,0%) 
org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAll (fail rate 
0,0%)
While first one is probably flaky, last two failures look like real issues.

> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.6
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-06-05 Thread Andrew Mashenkov (JIRA)


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

Andrew Mashenkov commented on IGNITE-8681:
--

[~dpavlov],

Hi, I've asked  [~ivan.glukos] to review this one. 

> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.6
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-06-05 Thread Dmitriy Pavlov (JIRA)


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

Dmitriy Pavlov commented on IGNITE-8681:


Hi [~amashenkov],  do you know Igniter who can review this change? Could you 
mention he or she in the ticket?

> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: performance
> Fix For: 2.6
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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


[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.

2018-06-01 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-8681:


GitHub user AMashenkov opened a pull request:

https://github.com/apache/ignite/pull/4110

IGNITE-8681: Introduce expiry throttling.

Thread will avoid try to clean expired entries if recent try has finished 
with "nothing to clean".

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8681

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4110


commit c069f31c90a5b4be02d4d6b4b390f278fb6c98f3
Author: Andrey V. Mashenkov 
Date:   2018-06-01T15:51:37Z

WIP. Introduce expiry throttling.
Thread will avoid try to clean expired entries if recent try has finished 
with "nothing to clean".




> Using ExpiryPolicy with persistence causes significant slowdown.
> 
>
> Key: IGNITE-8681
> URL: https://issues.apache.org/jira/browse/IGNITE-8681
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Almost all ignite operations calls CU.unwindEvicts() on finish to help to 
> evict expired entries.
> In unwindEvicts(), threads iterate over all node partitions and check every 
> partition PendingTree for expired entries. This costs too much.
> We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is 
> used. It raised once expiring entry has been put to cache or we initialize 
> non-empty pending tree from persistence.
> So, we have to optimize a case when there is no expired pending entries, but 
> pending tree is non-empty.
> We can add some throttling on per-partition basis to reduce useless pending 
> tree lookups. 
> E.g. if there is nothing to clean, no thread should check partition during 
> next 100ms interval.



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