You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Andrey Dolmatov <it...@gmail.com> on 2019/07/12 06:19:38 UTC
ServiceGrid CheckpointReadLock. Performance issue
Hi!
We call cache.get method using services and we found, that it acquires
checkpoint read lock. If we have done many updates and chckpointing process
has started (checkpoint write lock has acquired), then business critical
read operations are waiting for lock! Is it by design?
SimpleService proxy =
ignite.services(ignite.cluster().forServers()).serviceProxy(....)
proxy.callSomeMethod()
callSomeMethod(){
...
cache.get(K);
}
at
java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:481)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1327)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
at
o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1483)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:685)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:477)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:354)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:225)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:217)
at
o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:272)
at
o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4716)
at o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4697)
at o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1415)
at
o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:928)
at
o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
Re: ServiceGrid CheckpointReadLock. Performance issue
Posted by Majid Salimi <ma...@gmail.com>.
Unsubscribe
On Fri, Jul 12, 2019 at 10:50 AM Andrey Dolmatov <it...@gmail.com>
wrote:
> Hi!
>
> We call cache.get method using services and we found, that it acquires
> checkpoint read lock. If we have done many updates and chckpointing process
> has started (checkpoint write lock has acquired), then business critical
> read operations are waiting for lock! Is it by design?
>
> SimpleService proxy =
> ignite.services(ignite.cluster().forServers()).serviceProxy(....)
> proxy.callSomeMethod()
>
> callSomeMethod(){
> ...
> cache.get(K);
> }
>
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:481)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1327)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1483)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:685)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:477)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:354)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:225)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:217)
> at
> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:272)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4716)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4697)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1415)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:928)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
>
>
>
--
*Regards,Majid Salimi BeniM.Sc. Student of Computer Engineering,Department
of Computer Science and Engineering & IT*
*Shiraz University*
Attachments area
Re: ServiceGrid CheckpointReadLock. Performance issue
Posted by Majid Salimi <ma...@gmail.com>.
unsubscribe
On Fri, Jul 12, 2019 at 2:58 PM Ilya Kasnacheev <il...@gmail.com>
wrote:
> Hello!
>
> AFAIK, Checkpoint lock works like a barrier here: everyone has to wait
> until checkpoint starts, then they can resume operations while it is
> running.
>
> If there is some long operation which blocks checkpoint start then all
> operations may be waiting.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
>
> пт, 12 июл. 2019 г. в 09:20, Andrey Dolmatov <it...@gmail.com>:
>
>> Hi!
>>
>> We call cache.get method using services and we found, that it acquires
>> checkpoint read lock. If we have done many updates and chckpointing process
>> has started (checkpoint write lock has acquired), then business critical
>> read operations are waiting for lock! Is it by design?
>>
>> SimpleService proxy =
>> ignite.services(ignite.cluster().forServers()).serviceProxy(....)
>> proxy.callSomeMethod()
>>
>> callSomeMethod(){
>> ...
>> cache.get(K);
>> }
>>
>> at
>> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:481)
>> at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1327)
>> at
>> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
>> at
>> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1483)
>> at
>> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:685)
>> at
>> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:477)
>> at
>> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:354)
>> at
>> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:225)
>> at
>> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:217)
>> at
>> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:272)
>> at
>> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4716)
>> at
>> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4697)
>> at
>> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1415)
>> at
>> o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:928)
>> at
>> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
>>
>>
>>
--
*Regards,Majid Salimi BeniM.Sc. Student of Computer Engineering,Department
of Computer Science and Engineering & IT*
*Shiraz University*
Attachments area
Re: ServiceGrid CheckpointReadLock. Performance issue
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
AFAIK, Checkpoint lock works like a barrier here: everyone has to wait
until checkpoint starts, then they can resume operations while it is
running.
If there is some long operation which blocks checkpoint start then all
operations may be waiting.
Regards,
--
Ilya Kasnacheev
пт, 12 июл. 2019 г. в 09:20, Andrey Dolmatov <it...@gmail.com>:
> Hi!
>
> We call cache.get method using services and we found, that it acquires
> checkpoint read lock. If we have done many updates and chckpointing process
> has started (checkpoint write lock has acquired), then business critical
> read operations are waiting for lock! Is it by design?
>
> SimpleService proxy =
> ignite.services(ignite.cluster().forServers()).serviceProxy(....)
> proxy.callSomeMethod()
>
> callSomeMethod(){
> ...
> cache.get(K);
> }
>
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:481)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1327)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1483)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:685)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:477)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:354)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:225)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:217)
> at
> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:272)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4716)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4697)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1415)
> at
> o.a.i.i.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:928)
> at
> o.a.i.i.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
>
>
>