performance issues
Hi, I am trying to run the yardstick ignite benchmark test on my local VM having 8 Cores and 16GB RAM. I could see that the performance of Optimistic PUT/GET is way low for a client-server mode than what I see when running within one single server (embedded mode). Also the performance degrades with 1 additional server node. Can someone help me to optimize this? There was a blog where the author commented that the performance of the product is much similar when run in both client and server. Am I missing something here? https://gridgain.blogspot.com/2015/04/benchmarking-data-grids-apache-ignite.html?showComment=1466104423051 Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
isolate/group ignite instances on same machine based on name
Hi, Is there a way to isolate or group multiple ignite instances on the same machine based on names rather than ports? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: isolate/group ignite instances on same machine based on name
Thanks Denis. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Thursday, June 23, 2016 4:07 AM To: user@ignite.apache.org Subject: Re: isolate/group ignite instances on same machine based on name Hi, No, there is no way to isolate ignite instances by name. The name is just used for convenience by application code. The isolation is achieved by using different configuration for communication and discovery SPIs as shown here https://apacheignite.readme.io/v1.6/docs/cluster-config#isolated-ignite-clusters-on-the-same-set-of-machin — Denis On Jun 19, 2016, at 2:21 AM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, Is there a way to isolate or group multiple ignite instances on the same machine based on names rather than ports? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: performance issues
Thanks Denis. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Friday, June 24, 2016 1:00 AM To: user@ignite.apache.org Subject: Re: performance issues Hi Pradeep, Member-member (server-server) performance is better than client-server one in the scenario because in the first case roughly a half of data will be stored on the server that executes the benchmark (meaning that there won’t be I/O at all). While in case with client-server case the client always has to send the data to a remote server. In fact if you run more servers on different physical machines and start the benchmark using the client node the performance should be better rather with the configuration with less servers. — Denis On Jun 22, 2016, at 6:06 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Denis, Thanks for your response. I ran the benchmark test on a single VM with 8 cores and 2Gb allocated to each server instance (member). All the tests were for optimistic transactions with no backup and with the default JVM settings in benchmark.properties. I see that the performance of client-member is lower than the member-member setup. The client was configured using –client in the benchmark.properties. I have attached the configuration for 1 client 1 server mode. I was trying to run it on a single server with no clients but I was not able to configure that in the benchmark test. I am not sure if it is worth to test that scenario, as all the calls would be local and latency would be lot less. Please let me know if the member-member performance is lot better compared to client-member performance. Clients Servers Threads Latency (ms) Min Avg Max 0 2 8 0.341 0.451 0.881 0 2 8 0.362 0.470 0.874 1 2 8 0.695 0.749 1.070 1 1 8 0.576 0.726 1.102 Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Thursday, June 16, 2016 6:46 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: performance issues Hi, In a single server mode (embedded) there is no I/O (networking) at all. All the requests are executed locally. When you use the client node you’ll have I/O delays. The performance here can depend on several factors: - latency and throughput of your network; - CPU saturation; So take a look at these system resources usage. Also make sure that there are no long GC pauses or that GC Threads don’t consume much of CPUs. Refer to this doc for JVM tuning settings https://apacheignite.readme.io/docs/jvm-and-system-tuning Finally, share your benchmark source and configuration for validation. — Denis On Jun 16, 2016, at 11:04 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am trying to run the yardstick ignite benchmark test on my local VM having 8 Cores and 16GB RAM. I could see that the performance of Optimistic PUT/GET is way low for a client-server mode than what I see when running within one single server (embedded mode). Also the performance degrades with 1 additional server node. Can someone help me to optimize this? There was a blog where the author commented that the performance of the product is much similar when run in both client and server. Am I missing something here? https://gridgain.blogspot.com/2015/04/benchmarking-data-grids-apache-ignite.html?showComment=1466104423051 Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Evicted entry appears in Write-behind cache
Hi, I am trying to evaluate Apache Ignite and trying to explore eviction policy and write behind features. I am seeing that whenever a cache is configured with eviction policy and write behind feature, the write behind cache always have all the changed entries including the ones that are evicted, before the write cache is flushed. But soon after it is flushed, the store loads again from DB. Is this the expected behavior? Is there a documentation on how the write behind cache works? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Evicted entry appears in Write-behind cache
Thanks Vladislav From: Vladislav Pyatkov [mailto:vldpyat...@gmail.com] Sent: Wednesday, October 26, 2016 5:08 AM To: user@ignite.apache.org Subject: Re: Evicted entry appears in Write-behind cache Hi, Yes, write behind buffer gets locks on entries which stores between loading to CacheStore. So that this entries cannot be evicted. If "get" invocation can not find value in cache, it will try to get value from CacheStore. On Fri, Oct 14, 2016 at 6:55 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: I have some log statements in the load() which gets called when there is no entry in the cache or write behind buffer. What I learnt is that there is a write behind buffer that holds on to the entries (even the evicted ones) and whenever there is a get() for an entry, ignite looks at both the cache and the write behind buffer and loads it. If it doesn’t find it in any of the two, it then uses the read through mechanism to load the entry from the store. Thanks, Pradeep V.B. From: Vladislav Pyatkov [mailto:vpyat...@gridgain.com<mailto:vpyat...@gridgain.com>] Sent: Friday, October 14, 2016 4:25 AM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi Paradeep, Why are you think, what the entry could not be read through your persistence storage: .setReadThrough(stateQoS.isReadThroughEnabled()) When cache can not get data from in memory, it will try to get data from storage, which configured as "ReadThrough". On Thu, Oct 13, 2016 at 6:41 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Vladislav, Please see the below cache configuration. LruEvictionPolicy evictionPolicy = new LruEvictionPolicy<>(getIntProperty(envConfig, CACHE_SIZE, 1)); cacheConfiguration .setEvictionPolicy(evictionPolicy) .setWriteBehindFlushSize(getIntProperty(envConfig, CACHE_WB_FLUSH_SIZE, 0)) .setWriteBehindBatchSize(getIntProperty(envConfig, CACHE_WB_BATCH_SIZE, 200)) .setWriteBehindEnabled(stateQoS.isWriteBehindEnabled()) .setWriteBehindFlushFrequency(getIntProperty(envConfig, CACHE_WB_FLUSH_FREQ_MS, 5000)) .setWriteBehindFlushThreadCount(getIntProperty(envConfig, CACHE_WB_FLUSH_THREADS, 10)) .setCacheStoreFactory(new StateCacheStoreFactory<K, V>(cacheName, storageManager)) .setName(cacheName) .setReadThrough(stateQoS.isReadThroughEnabled()) .setWriteThrough(stateQoS.isWriteThroughEnabled()); Thanks, Pradeep V.B. From: Vladislav Pyatkov [mailto:vldpyat...@gmail.com<mailto:vldpyat...@gmail.com>] Sent: Wednesday, October 12, 2016 2:59 AM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi Pradeep, Could you please provide cache configuration? On Tue, Oct 11, 2016 at 6:57 PM, Denis Magda <dma...@gridgain.com<mailto:dma...@gridgain.com>> wrote: Looks like that my initial understanding was wrong. There is a related discussion http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html — Denis On Oct 11, 2016, at 8:55 AM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Denis, I did the get() on the evicted entry from the cache, it still returned me the value without calling the load() on the store. As you said, the entry would be cached in the write behind store even for the evicted entry. Is that true? Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Monday, October 10, 2016 9:13 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi, How do you see that the evicted entries are still in the cache? If you check this by calling cache get like operations then entries can be loaded back from the write-behind store or from your underlying store. — Denis On Oct 8, 2016, at 1:00 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am trying to evaluate Apache Ignite and trying to explore eviction policy
RE: Evicted entry appears in Write-behind cache
I have some log statements in the load() which gets called when there is no entry in the cache or write behind buffer. What I learnt is that there is a write behind buffer that holds on to the entries (even the evicted ones) and whenever there is a get() for an entry, ignite looks at both the cache and the write behind buffer and loads it. If it doesn’t find it in any of the two, it then uses the read through mechanism to load the entry from the store. Thanks, Pradeep V.B. From: Vladislav Pyatkov [mailto:vpyat...@gridgain.com] Sent: Friday, October 14, 2016 4:25 AM To: user@ignite.apache.org Subject: Re: Evicted entry appears in Write-behind cache Hi Paradeep, Why are you think, what the entry could not be read through your persistence storage: .setReadThrough(stateQoS.isReadThroughEnabled()) When cache can not get data from in memory, it will try to get data from storage, which configured as "ReadThrough". On Thu, Oct 13, 2016 at 6:41 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Vladislav, Please see the below cache configuration. LruEvictionPolicy evictionPolicy = new LruEvictionPolicy<>(getIntProperty(envConfig, CACHE_SIZE, 1)); cacheConfiguration .setEvictionPolicy(evictionPolicy) .setWriteBehindFlushSize(getIntProperty(envConfig, CACHE_WB_FLUSH_SIZE, 0)) .setWriteBehindBatchSize(getIntProperty(envConfig, CACHE_WB_BATCH_SIZE, 200)) .setWriteBehindEnabled(stateQoS.isWriteBehindEnabled()) .setWriteBehindFlushFrequency(getIntProperty(envConfig, CACHE_WB_FLUSH_FREQ_MS, 5000)) .setWriteBehindFlushThreadCount(getIntProperty(envConfig, CACHE_WB_FLUSH_THREADS, 10)) .setCacheStoreFactory(new StateCacheStoreFactory<K, V>(cacheName, storageManager)) .setName(cacheName) .setReadThrough(stateQoS.isReadThroughEnabled()) .setWriteThrough(stateQoS.isWriteThroughEnabled()); Thanks, Pradeep V.B. From: Vladislav Pyatkov [mailto:vldpyat...@gmail.com<mailto:vldpyat...@gmail.com>] Sent: Wednesday, October 12, 2016 2:59 AM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi Pradeep, Could you please provide cache configuration? On Tue, Oct 11, 2016 at 6:57 PM, Denis Magda <dma...@gridgain.com<mailto:dma...@gridgain.com>> wrote: Looks like that my initial understanding was wrong. There is a related discussion http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html — Denis On Oct 11, 2016, at 8:55 AM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Denis, I did the get() on the evicted entry from the cache, it still returned me the value without calling the load() on the store. As you said, the entry would be cached in the write behind store even for the evicted entry. Is that true? Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Monday, October 10, 2016 9:13 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi, How do you see that the evicted entries are still in the cache? If you check this by calling cache get like operations then entries can be loaded back from the write-behind store or from your underlying store. — Denis On Oct 8, 2016, at 1:00 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am trying to evaluate Apache Ignite and trying to explore eviction policy and write behind features. I am seeing that whenever a cache is configured with eviction policy and write behind feature, the write behind cache always have all the changed entries including the ones that are evicted, before the write cache is flushed. But soon after it is flushed, the store loads again from DB. Is this the expected behavior? Is there a documentation on how the write behind cache works? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error plea
RE: Evicted entry appears in Write-behind cache
Hi Denis, I did the get() on the evicted entry from the cache, it still returned me the value without calling the load() on the store. As you said, the entry would be cached in the write behind store even for the evicted entry. Is that true? Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Monday, October 10, 2016 9:13 PM To: user@ignite.apache.org Subject: Re: Evicted entry appears in Write-behind cache Hi, How do you see that the evicted entries are still in the cache? If you check this by calling cache get like operations then entries can be loaded back from the write-behind store or from your underlying store. — Denis On Oct 8, 2016, at 1:00 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am trying to evaluate Apache Ignite and trying to explore eviction policy and write behind features. I am seeing that whenever a cache is configured with eviction policy and write behind feature, the write behind cache always have all the changed entries including the ones that are evicted, before the write cache is flushed. But soon after it is flushed, the store loads again from DB. Is this the expected behavior? Is there a documentation on how the write behind cache works? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Evicted entry appears in Write-behind cache
Hi Vladislav, Please see the below cache configuration. LruEvictionPolicy evictionPolicy = new LruEvictionPolicy<>(getIntProperty(envConfig, CACHE_SIZE, 1)); cacheConfiguration .setEvictionPolicy(evictionPolicy) .setWriteBehindFlushSize(getIntProperty(envConfig, CACHE_WB_FLUSH_SIZE, 0)) .setWriteBehindBatchSize(getIntProperty(envConfig, CACHE_WB_BATCH_SIZE, 200)) .setWriteBehindEnabled(stateQoS.isWriteBehindEnabled()) .setWriteBehindFlushFrequency(getIntProperty(envConfig, CACHE_WB_FLUSH_FREQ_MS, 5000)) .setWriteBehindFlushThreadCount(getIntProperty(envConfig, CACHE_WB_FLUSH_THREADS, 10)) .setCacheStoreFactory(new StateCacheStoreFactory<K, V>(cacheName, storageManager)) .setName(cacheName) .setReadThrough(stateQoS.isReadThroughEnabled()) .setWriteThrough(stateQoS.isWriteThroughEnabled()); Thanks, Pradeep V.B. From: Vladislav Pyatkov [mailto:vldpyat...@gmail.com] Sent: Wednesday, October 12, 2016 2:59 AM To: user@ignite.apache.org Subject: Re: Evicted entry appears in Write-behind cache Hi Pradeep, Could you please provide cache configuration? On Tue, Oct 11, 2016 at 6:57 PM, Denis Magda <dma...@gridgain.com<mailto:dma...@gridgain.com>> wrote: Looks like that my initial understanding was wrong. There is a related discussion http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html — Denis On Oct 11, 2016, at 8:55 AM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Denis, I did the get() on the evicted entry from the cache, it still returned me the value without calling the load() on the store. As you said, the entry would be cached in the write behind store even for the evicted entry. Is that true? Thanks, Pradeep V.B. From: Denis Magda [mailto:dma...@gridgain.com] Sent: Monday, October 10, 2016 9:13 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Evicted entry appears in Write-behind cache Hi, How do you see that the evicted entries are still in the cache? If you check this by calling cache get like operations then entries can be loaded back from the write-behind store or from your underlying store. — Denis On Oct 8, 2016, at 1:00 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am trying to evaluate Apache Ignite and trying to explore eviction policy and write behind features. I am seeing that whenever a cache is configured with eviction policy and write behind feature, the write behind cache always have all the changed entries including the ones that are evicted, before the write cache is flushed. But soon after it is flushed, the store loads again from DB. Is this the expected behavior? Is there a documentation on how the write behind cache works? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- Vladislav Pyatkov This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Improve performance of ignite cluster
No, I mean I have one ignite instance running in one JVM and there are several application JVMs that have one embedded instance on each of them and they all talk to each other. From: Alexey Kuznetsov [mailto:akuznet...@apache.org] Sent: Friday, October 14, 2016 12:20 PM To: user@ignite.apache.org Subject: Re: Improve performance of ignite cluster Hi Pradeep, Why did you start several Ignite instances in one JVM? AFAIK it is recommended only for testing. In production it is recommended to start separate JVMs. On Fri, Oct 14, 2016 at 11:01 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am seeing a big drop in performance when more two or more ignite instances embedded within JVMs form a cluster. The throughput I get is 1/10 of what I used to get when working with only one embedded ignite instance inside the application. Can anyone help me in tuning this thing? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- Alexey Kuznetsov This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Improve performance of ignite cluster
Thanks Andrey. From: Andrey Kornev [mailto:andrewkor...@hotmail.com] Sent: Friday, October 14, 2016 12:45 PM To: user@ignite.apache.org Subject: Re: Improve performance of ignite cluster Pradeep, Even though you did not provide any details on how you measure the throughout, I think the drop is expected. It is because as soon as a second (and the third and so on) node joins the Ignite cluster, most of Ignite operations become distributed and involve remote calls. There are ways to minimize the performance impact -- for example, ensuring that the processing is colocated with the data to be processed as opposed to bring the data to a single processing node, etc -- but in all cases it's very application specific. Regards Andrey From: Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> Sent: Friday, October 14, 2016 9:23 AM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: RE: Improve performance of ignite cluster No, I mean I have one ignite instance running in one JVM and there are several application JVMs that have one embedded instance on each of them and they all talk to each other. From: Alexey Kuznetsov [mailto:akuznet...@apache.org] Sent: Friday, October 14, 2016 12:20 PM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Improve performance of ignite cluster Hi Pradeep, Why did you start several Ignite instances in one JVM? AFAIK it is recommended only for testing. In production it is recommended to start separate JVMs. On Fri, Oct 14, 2016 at 11:01 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I am seeing a big drop in performance when more two or more ignite instances embedded within JVMs form a cluster. The throughput I get is 1/10 of what I used to get when working with only one embedded ignite instance inside the application. Can anyone help me in tuning this thing? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- Alexey Kuznetsov This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Binary Marshalling issue
Hi, I have an application which uses apache ignite cache in an embedded mode. On each GC cycle, I am seeing lot of memory getting retained. Cache has around 10K entries and each entry is an object containing a map of 500 entries. The key and value in the map within an object is string of less than 20 bytes. I see lot of time spent during the marshalling process when the cache entry is made. Does ignite generate lot of short lived objects during the marshalling process? What would cause lot of memory to be retained during each GC cycle? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Binary Marshalling issue
Hi Andrey, Thanks for your response. Is there a way I can disable it or reduce it? Do I need to use BinaryObject? Thanks, Pradeep V.B. From: Andrey Mashenkov [mailto:andrey.mashen...@gmail.com] Sent: Friday, December 16, 2016 9:41 AM To: user@ignite.apache.org Subject: Re: Binary Marshalling issue Hi As I understand you have many short-lived Maps as values in cache. Yes, in your case, you can get a lot of garbage due to Map will be marshal\unmarshal along with each of its content at every cache entry access. On Fri, Dec 16, 2016 at 4:26 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I have an application which uses apache ignite cache in an embedded mode. On each GC cycle, I am seeing lot of memory getting retained. Cache has around 10K entries and each entry is an object containing a map of 500 entries. The key and value in the map within an object is string of less than 20 bytes. I see lot of time spent during the marshalling process when the cache entry is made. Does ignite generate lot of short lived objects during the marshalling process? What would cause lot of memory to be retained during each GC cycle? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- С уважением, Машенков Андрей Владимирович Тел. +7-921-932-61-82 Best regards, Andrey V. Mashenkov Cerr: +7-921-932-61-82 This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: Binary Marshalling issue
Thanks Andrey. From: Andrey Mashenkov [mailto:andrey.mashen...@gmail.com] Sent: Friday, December 16, 2016 11:30 AM To: user@ignite.apache.org Subject: Re: Binary Marshalling issue Hi, Unfortunatelly ignite does not support keepBinary option for Maps [1]. Best way is try to avoid using short-lived Maps. But you can try to implementation of BinaryObject that implements Externalizable interface where you will free to choose the way to access map entries. For example, such implementation can have BinaryObject.field() method with same semantic as Map.get() method. [1] http://apacheignite.gridgain.org/docs/binary-marshaller#binaryobject-cache-api On Fri, Dec 16, 2016 at 5:48 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi Andrey, Thanks for your response. Is there a way I can disable it or reduce it? Do I need to use BinaryObject? Thanks, Pradeep V.B. From: Andrey Mashenkov [mailto:andrey.mashen...@gmail.com<mailto:andrey.mashen...@gmail.com>] Sent: Friday, December 16, 2016 9:41 AM To: user@ignite.apache.org<mailto:user@ignite.apache.org> Subject: Re: Binary Marshalling issue Hi As I understand you have many short-lived Maps as values in cache. Yes, in your case, you can get a lot of garbage due to Map will be marshal\unmarshal along with each of its content at every cache entry access. On Fri, Dec 16, 2016 at 4:26 PM, Pradeep Badiger <pradeepbadi...@fico.com<mailto:pradeepbadi...@fico.com>> wrote: Hi, I have an application which uses apache ignite cache in an embedded mode. On each GC cycle, I am seeing lot of memory getting retained. Cache has around 10K entries and each entry is an object containing a map of 500 entries. The key and value in the map within an object is string of less than 20 bytes. I see lot of time spent during the marshalling process when the cache entry is made. Does ignite generate lot of short lived objects during the marshalling process? What would cause lot of memory to be retained during each GC cycle? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- С уважением, Машенков Андрей Владимирович Тел. +7-921-932-61-82 Best regards, Andrey V. Mashenkov Cerr: +7-921-932-61-82 This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- С уважением, Машенков Андрей Владимирович Тел. +7-921-932-61-82 Best regards, Andrey V. Mashenkov Cerr: +7-921-932-61-82 This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
RE: OOM Issue with Eviction Event listener - Ignite 1.9.0
Hi Andrey, I tried with -Xmx3072m -Xmx3072m and I still get OOM. If I try with 4GB heap setting then it works with GC running continuously. With 8GB, it works without any issues. Is it just that it needs more heap to perform unmarshalling and give the evicted entry to the listener? [15:33:08] Ignite node started OK (id=3a14ca7d, grid=IgniteWithCacheEvictListener) [15:33:08] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.0GB] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3236) at java.lang.StringCoding.safeTrim(StringCoding.java:79) at java.lang.StringCoding.encode(StringCoding.java:365) at java.lang.String.getBytes(String.java:941) at org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteString(BinaryWriterExImpl.java:435) at org.apache.ignite.internal.binary.BinaryWriterExImpl.writeStringField(BinaryWriterExImpl.java:1102) at org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:506) at org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:784) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147) at org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134) at org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239) at org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:521) at org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:914) at org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:859) at org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1792) at org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.updateAllInternal(GridLocalAtomicCache.java:834) at org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.put0(GridLocalAtomicCache.java:147) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2276) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2253) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1375) at com.example.IgniteWithCacheEvictListener.main(IgniteWithCacheEvictListener.java:63) -Original Message- From: Andrey Gura [mailto:ag...@apache.org] Sent: Monday, May 01, 2017 11:34 AM To: user@ignite.apache.org Subject: Re: OOM Issue with Eviction Event listener - Ignite 1.9.0 Hi, Listener just lead to additional Event objects instantiation. You should give more memory for your Java process. On Mon, May 1, 2017 at 5:54 PM, Pradeep Badiger <pradeepbadi...@fico.com> wrote: > Hi, > > > > I am facing an OOM Exception when eviction policy is turned on. I have > attached an eclipse project that has two test programs. One is set > with eviction event listener and another one is not. > > > > The test program with eviction listener throws an OOM error almost > immediately after the ignite is initialized. The one without the > listener works fine. > > > > I ran both the test programs with –Xmx512m –Xms512m. > > > > Can someone let me know if there are any issues with my configurations? > > > > Thanks, > > Pradeep V.B. > > This email and any files transmitted with it are confidential, > proprietary and intended solely for the individual or entity to whom they are > addressed. > If you have received this email in error please delete it immediately. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
cache closed or destroyed issue
Hi, We are facing an issue with Ignite cache where it throws an IllegalArgumentException with Cache closed or destroyed. I have two java applications that start the ignite cache in an embedded mode. The cache instances form a cache cluster with the help of zookeeper plugin for discovery. The cache is partitioned. I don't think there is any memory related issues within two applications. I have few entries in the cache. But after sometime, if I try to get an entry from the cache in the application, I get an exception with cache closed or destroyed. I am not sure what would cause this issue. I found this issue in jira. I am not sure if this is applicable for 1.7.0. https://issues.apache.org/jira/browse/IGNITE-2766 Can someone help me with this? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Issue with serialization data security - 2.5.0
Hi, We are running into an issue with serialization security in Ignite 2.5.0 with whitelisting enabled. We start the cache inside an application in embedded mode. The cache is partitioned with read through/write behind enabled. I am getting the below exception while working with the cache. Note that this does not happen always. 2020-08-04 14:05:38.482 [sys-#41] ERROR ignite.internal.processors.continuous.GridContinuousProcessor - Failed to process message (ignoring): GridContinuousMessage [type=MSG_EVT_NOTIFICATION, routineId=e6f15316-b9c4-4316-878f-188401f64acf, data=null, futId=null] org.apache.ignite.IgniteCheckedException: Deserialization of class org.apache.ignite.util.deque.FastSizeDeque is disallowed. at org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9968) [dmipDPC.jar:?] at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$7.onMessage(GridContinuousProcessor.java:266) [dmipDPC.jar:?] at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556) [dmipDPC.jar:?] at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184) [dmipDPC.jar:?] at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125) [dmipDPC.jar:?] at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091) [dmipDPC.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_231] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_231] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_231] Caused by: java.lang.RuntimeException: Deserialization of class org.apache.ignite.util.deque.FastSizeDeque is disallowed. at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8606) ~[dmipDPC.jar:?] at org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349) ~[dmipDPC.jar:?] at org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:688) ~[dmipDPC.jar:?] at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755) ~[dmipDPC.jar:?] at org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714) ~[dmipDPC.jar:?] at org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310) ~[dmipDPC.jar:?] at org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99) ~[dmipDPC.jar:?] at org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82) ~[dmipDPC.jar:?] at org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9962) [dmipDPC.jar:?] ... 8 more I looked at org.apache.ignite.internal.IgniteKernal#classWhiteList and it loads the META-INF/classnames.txt and META-INF/classnames-jdk.txt files before loading the user configured whitelist classes file. I don't see the mention of org.apache.ignite.util.deque.FastSizeDeque class in the META-INF/classnames.txt file. Is this a bug within Ignite? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Ignite 2.7.0 Off-heap evictions and replace()
Hi, We are using Apache Ignite 2.7.0 with the following setup 1. on-heap enabled 2. native persistence disabled 3. loading cache working with a database with write behind. 4. Random2LRU for off-heap evictions We are seeing that call to the replace() on a key returns false even though that was very recently updated and was available before the replace() was called. We found that entry gets evicted from off-heap right before the replace() is called causing it to fail. What is the expected behavior in this case? Since we are using a loading cache, is it not supposed to load it from the store during the replace() call? Why does that get evicted from off-heap? thanks, Pradeep V.B.
