You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Raymond Wilson <ra...@trimble.com> on 2017/10/18 00:01:58 UTC

Running out of memory using ScanQuery. Memory leak?

I have run into something odd using ScanQuery (using Ignite 2.2, C# client
and native persistence). I have a fairly simple piece of scanning code
below, it simple looks through all the keys in a cache and emits them to a
file.



It creates a ScanQuery, sets its page size to 1, and explicitly disposes of
each value once it’s key has been written out (to ensure there are no .Net
GC nasties). SubGridSpatialAffinityKey is a simple struct with a few value
fields in it. This code is running in the context of a client node and is
asking other server nodes for the keys via the ScanQuery.



        private void writeKeysSpatial(string title, StreamWriter writer,
ICache<SubGridSpatialAffinityKey, MemoryStream> cache)

        {

            writer.WriteLine(title);



            var scanQuery = new ScanQuery<SubGridSpatialAffinityKey,
MemoryStream>();

            scanQuery.PageSize = 1; // Restrict the number of keys
requested in each page to reduce memory consumption



            IQueryCursor<ICacheEntry<SubGridSpatialAffinityKey, MemoryStream>>
queryCursor = cache.Query(scanQuery);



            foreach (ICacheEntry<SubGridSpatialAffinityKey, MemoryStream>
cacheEntry in queryCursor)

            {

                writer.WriteLine(cacheEntry.Key.ToString());

                cacheEntry.Value.Dispose();

            }

        }



When I run this code it progresses for quite a while before running into a
crisis in the JVM side of things as seen in the snap from JVisualVM below.
Once it reaches this state no further progress is made, and code execution
hangs inside the foreach loop. My impression here is that the memory
requirements through the process of the scan query should be fairly steady
state, but this does not seem to be the case. The total amount of data held
in the cache being scanned is less than 1 Gb.





Raymond.

RE: Running out of memory using ScanQuery. Memory leak?

Posted by Raymond Wilson <ra...@trimble.com>.
FYI, after some advice from Pavel on another thread regarding using byte[]
in preference to MemoryStream, the ScanQuery code now no longer stalls, and
is radically faster, as below.



        private void writeKeysSpatial(string title, StreamWriter writer,
ICache<SubGridSpatialAffinityKey, byte[]> cache)

        {

            writer.WriteLine(title);



            var scanQuery = new ScanQuery<SubGridSpatialAffinityKey, byte
[]>();

            scanQuery.PageSize = 1; // Restrict the number of keys
requested in each page to reduce memory consumption



            IQueryCursor<ICacheEntry<SubGridSpatialAffinityKey, byte[]>>
queryCursor = cache.Query(scanQuery);



            foreach (ICacheEntry<SubGridSpatialAffinityKey, byte[]>
cacheEntry in queryCursor)

            {

                writer.WriteLine(cacheEntry.Key.ToString());

            }

        }







*From:* Raymond Wilson [mailto:raymond_wilson@trimble.com]
*Sent:* Wednesday, October 18, 2017 1:02 PM
*To:* user@ignite.apache.org
*Subject:* Running out of memory using ScanQuery. Memory leak?



I have run into something odd using ScanQuery (using Ignite 2.2, C# client
and native persistence). I have a fairly simple piece of scanning code
below, it simple looks through all the keys in a cache and emits them to a
file.



It creates a ScanQuery, sets its page size to 1, and explicitly disposes of
each value once it’s key has been written out (to ensure there are no .Net
GC nasties). SubGridSpatialAffinityKey is a simple struct with a few value
fields in it. This code is running in the context of a client node and is
asking other server nodes for the keys via the ScanQuery.



        private void writeKeysSpatial(string title, StreamWriter writer,
ICache<SubGridSpatialAffinityKey, MemoryStream> cache)

        {

            writer.WriteLine(title);



            var scanQuery = new ScanQuery<SubGridSpatialAffinityKey,
MemoryStream>();

            scanQuery.PageSize = 1; // Restrict the number of keys
requested in each page to reduce memory consumption



            IQueryCursor<ICacheEntry<SubGridSpatialAffinityKey, MemoryStream>>
queryCursor = cache.Query(scanQuery);



            foreach (ICacheEntry<SubGridSpatialAffinityKey, MemoryStream>
cacheEntry in queryCursor)

            {

                writer.WriteLine(cacheEntry.Key.ToString());

                cacheEntry.Value.Dispose();

            }

        }



When I run this code it progresses for quite a while before running into a
crisis in the JVM side of things as seen in the snap from JVisualVM below.
Once it reaches this state no further progress is made, and code execution
hangs inside the foreach loop. My impression here is that the memory
requirements through the process of the scan query should be fairly steady
state, but this does not seem to be the case. The total amount of data held
in the cache being scanned is less than 1 Gb.





Raymond.