Folks, I filed a ticket [1] to address the concern of starting too many nodes. Please review it.
[1] https://issues.apache.org/jira/browse/IGNITE-6003 Thanks, Sergey. On Mon, Aug 7, 2017 at 12:53 PM, Sergey Chugunov <sergey.chugu...@gmail.com> wrote: > Dmitriy, > > When Ignite node "allocates memory" it actually just reserves a chunk in > its address space, almost no physical RAM is used. > > I can easily start half a dozen of ignite nodes with current defaults on > my laptop with only 16 Gigs of RAM; and each node will "allocate" around 12 > Gigs; 72 gigabytes in total. > The laptop will do easily with it so far I don't stream any data to the > grid. > > But when I put some pressure to the grid, massive swapping of memory pages > will show up as OS begins trying to keep a huge amount of pages of > different processes in memory. > > So indicator "we are running out of memory" just doesn't work here. > > Thanks, > Sergey. > > On Fri, Aug 4, 2017 at 1:01 PM, <dsetrak...@apache.org> wrote: > >> But why? We allocate the memory, so we should know when it runs out. What >> am i missing? >> >> D. >> >> On Aug 4, 2017, 11:55 AM, at 11:55 AM, Sergey Chugunov < >> sergey.chugu...@gmail.com> wrote: >> >I used GC and java only as an example, they are not applicable to >> >Ignite >> >case where we manage offheap memory. >> > >> >My point is that there is no easy way to implement this feature in >> >Ignite, >> >and more time is needed to properly design it and account for all >> >risks. >> > >> >Thanks, >> >Sergey. >> > >> >On Fri, Aug 4, 2017 at 12:44 PM, <dsetrak...@apache.org> wrote: >> > >> >> Hang on. I thought we were talking about offheap size, GC should not >> >be >> >> relevant. Am I wrong? >> >> >> >> D. >> >> >> >> On Aug 4, 2017, 11:38 AM, at 11:38 AM, Sergey Chugunov < >> >> sergey.chugu...@gmail.com> wrote: >> >> >Do you see an obvious way of implementing it? >> >> > >> >> >In java there is a heap and GC working on it. And for instance, it >> >is >> >> >possible to make a decision to throw an OOM based on some gc >> >metrics. >> >> > >> >> >I may be wrong but I don't see a mechanism in Ignite to use it right >> >> >away >> >> >for such purposes. >> >> >And implementing something without thorough planning brings huge >> >risk >> >> >of >> >> >false positives with nodes stopping when they don't have to. >> >> > >> >> >That's why I think it must be implemented and intensively tested as >> >> >part of >> >> >a separate ticket. >> >> > >> >> >Thanks, >> >> >Sergey. >> >> > >> >> >On Fri, Aug 4, 2017 at 12:18 PM, <dsetrak...@apache.org> wrote: >> >> > >> >> >> Without #3, the #1 and #2 make little sense. >> >> >> >> >> >> Why is #3 so difficult? >> >> >> >> >> >> D. >> >> >> >> >> >> On Aug 4, 2017, 10:46 AM, at 10:46 AM, Sergey Chugunov < >> >> >> sergey.chugu...@gmail.com> wrote: >> >> >> >Dmitriy, >> >> >> > >> >> >> >Last item makes perfect sense to me, one may think of it as an >> >> >> >"OutOfMemoryException" in java. >> >> >> >However, it looks like such feature requires considerable efforts >> >to >> >> >> >properly design and implement it, so I would propose to create a >> >> >> >separate >> >> >> >ticket and agree upon target version for it. >> >> >> > >> >> >> >Items #1 and #2 will be implemented under IGNITE-5717. Makes >> >sense? >> >> >> > >> >> >> >Thanks, >> >> >> >Sergey. >> >> >> > >> >> >> >On Thu, Aug 3, 2017 at 4:34 AM, Dmitriy Setrakyan >> >> >> ><dsetrak...@apache.org> >> >> >> >wrote: >> >> >> > >> >> >> >> Here is what we should do: >> >> >> >> >> >> >> >> 1. Pick an acceptable number. Does not matter if it is 10% >> >or >> >> >50%. >> >> >> >> 2. Print the allocated memory in *BOLD* letters into the >> >log. >> >> >> >> 3. Make sure that Ignite server never hangs due to the low >> >> >memory >> >> >> >issue. >> >> >> >> We should sense it and kick the node out automatically, >> >again >> >> >with >> >> >> >a >> >> >> >> *BOLD* >> >> >> >> message in the log. >> >> >> >> >> >> >> >> Is this possible? >> >> >> >> >> >> >> >> D. >> >> >> >> >> >> >> >> On Wed, Aug 2, 2017 at 6:09 PM, Vladimir Ozerov >> >> >> ><voze...@gridgain.com> >> >> >> >> wrote: >> >> >> >> >> >> >> >> > My proposal is 10% instead of 80%. >> >> >> >> > >> >> >> >> > ср, 2 авг. 2017 г. в 18:54, Denis Magda <dma...@apache.org>: >> >> >> >> > >> >> >> >> > > Vladimir, Dmitriy P., >> >> >> >> > > >> >> >> >> > > Please see inline >> >> >> >> > > >> >> >> >> > > > On Aug 2, 2017, at 7:20 AM, Vladimir Ozerov >> >> >> ><voze...@gridgain.com> >> >> >> >> > > wrote: >> >> >> >> > > > >> >> >> >> > > > Denis, >> >> >> >> > > > >> >> >> >> > > > The reason is that product should not hang user's >> >computer. >> >> >How >> >> >> >else >> >> >> >> > this >> >> >> >> > > > could be explained? I am developer. I start Ignite, 1 >> >node, >> >> >2 >> >> >> >nodes, >> >> >> >> X >> >> >> >> > > > nodes, observe how they join topology. Add one key, 10 >> >keys, >> >> >1M >> >> >> >keys. >> >> >> >> > > Then >> >> >> >> > > > I do a bug in example and load 100M keys accidentally - >> >> >restart >> >> >> >the >> >> >> >> > > > computer. Correct behavior is to have small "maxMemory" >> >by >> >> >> >default to >> >> >> >> > > avoid >> >> >> >> > > > that. User should get exception instead of hang. E.g. >> >Java's >> >> >> >"-Xmx" >> >> >> >> is >> >> >> >> > > > typically 25% of RAM - more adequate value, comparing to >> >> >> >Ignite. >> >> >> >> > > > >> >> >> >> > > >> >> >> >> > > Right, the developer was educated about the Java heap >> >> >parameters >> >> >> >and >> >> >> >> > > limited the overall space preferring OOM to the laptop >> >> >> >suspension. Who >> >> >> >> > > knows how he got to the point that 25% RAM should be used. >> >> >That >> >> >> >might >> >> >> >> > have >> >> >> >> > > been deep knowledge about JVM or he faced several hangs >> >while >> >> >> >testing >> >> >> >> the >> >> >> >> > > application. >> >> >> >> > > >> >> >> >> > > Anyway, JVM creators didn’t decide to predefine the Java >> >heap >> >> >to >> >> >> >a >> >> >> >> static >> >> >> >> > > value to avoid the situations like above. So should not we >> >as >> >> >a >> >> >> >> platform. >> >> >> >> > > Educate people about the Ignite memory behavior like Sun >> >did >> >> >for >> >> >> >the >> >> >> >> Java >> >> >> >> > > heap but do not try to solve the lack of knowledge with the >> >> >> >default >> >> >> >> > static >> >> >> >> > > memory size. >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > > It doesn't matter whether you use persistence or not. >> >> >> >Persistent case >> >> >> >> > > just >> >> >> >> > > > makes this flaw more obvious - you have virtually >> >unlimited >> >> >> >disk, and >> >> >> >> > yet >> >> >> >> > > > you end up with swapping and hang when using Ignite with >> >> >> >default >> >> >> >> > > > configuration. As already explained, the problem is not >> >> >about >> >> >> >> > allocating >> >> >> >> > > > "maxMemory" right away, but about the value of >> >"maxMemory" - >> >> >it >> >> >> >is >> >> >> >> too >> >> >> >> > > big. >> >> >> >> > > > >> >> >> >> > > >> >> >> >> > > How do you know what should be the default then? Why 1 GB? >> >For >> >> >> >> instance, >> >> >> >> > > if I end up having only 1 GB of free memory left and try to >> >> >start >> >> >> >2 >> >> >> >> > server >> >> >> >> > > nodes and an application I will face the laptop suspension >> >> >again. >> >> >> >> > > >> >> >> >> > > — >> >> >> >> > > Denis >> >> >> >> > > >> >> >> >> > > > "We had this behavior before" is never an argument. >> >Previous >> >> >> >offheap >> >> >> >> > > > implementation had a lot of flaws, so let's just forget >> >> >about >> >> >> >it. >> >> >> >> > > > >> >> >> >> > > > On Wed, Aug 2, 2017 at 5:08 PM, Denis Magda >> >> ><dma...@apache.org> >> >> >> >> wrote: >> >> >> >> > > > >> >> >> >> > > >> Sergey, >> >> >> >> > > >> >> >> >> >> > > >> That’s expectable because as we revealed from this >> >> >discussion >> >> >> >the >> >> >> >> > > >> allocation works different depending on whether the >> >> >> >persistence is >> >> >> >> > used >> >> >> >> > > or >> >> >> >> > > >> not: >> >> >> >> > > >> >> >> >> >> > > >> 1) In-memory mode (the persistence is disabled) - the >> >space >> >> >> >will be >> >> >> >> > > >> allocated incrementally until the max threshold is >> >reached. >> >> >> >Good! >> >> >> >> > > >> >> >> >> >> > > >> 2) The persistence mode - the whole space (limited by >> >the >> >> >max >> >> >> >> > threshold) >> >> >> >> > > >> is allocated right away. It’s not surprising that your >> >> >laptop >> >> >> >starts >> >> >> >> > > >> choking. >> >> >> >> > > >> >> >> >> >> > > >> So, in my previous response I tried to explain that I >> >can’t >> >> >> >find any >> >> >> >> > > >> reason why we should adjust 1). Any reasons except for >> >the >> >> >> >massive >> >> >> >> > > >> preloading? >> >> >> >> > > >> >> >> >> >> > > >> As for 2), that was a big surprise to reveal this after >> >2.1 >> >> >> >release. >> >> >> >> > > >> Definitely we have to fix this somehow. >> >> >> >> > > >> >> >> >> >> > > >> — >> >> >> >> > > >> Denis >> >> >> >> > > >> >> >> >> >> > > >>> On Aug 2, 2017, at 6:59 AM, Sergey Chugunov < >> >> >> >> > sergey.chugu...@gmail.com >> >> >> >> > > > >> >> >> >> > > >> wrote: >> >> >> >> > > >>> >> >> >> >> > > >>> Denis, >> >> >> >> > > >>> >> >> >> >> > > >>> Just a simple example from our own codebase: I tried to >> >> >> >execute >> >> >> >> > > >>> PersistentStoreExample with default settings and two >> >> >server >> >> >> >nodes >> >> >> >> and >> >> >> >> > > >>> client node got frozen even on initial load of data >> >into >> >> >the >> >> >> >grid. >> >> >> >> > > >>> Although with one server node the example finishes >> >pretty >> >> >> >quickly. >> >> >> >> > > >>> >> >> >> >> > > >>> And my laptop isn't the weakest one and has 16 gigs of >> >> >> >memory, but >> >> >> >> it >> >> >> >> > > >>> cannot deal with it. >> >> >> >> > > >>> >> >> >> >> > > >>> >> >> >> >> > > >>> On Wed, Aug 2, 2017 at 4:58 PM, Denis Magda >> >> >> ><dma...@apache.org> >> >> >> >> > wrote: >> >> >> >> > > >>> >> >> >> >> > > >>>>> As far as allocating 80% of available RAM - I was >> >> >against >> >> >> >this >> >> >> >> even >> >> >> >> > > for >> >> >> >> > > >>>>> In-memory mode and still think that this is a wrong >> >> >> >default. >> >> >> >> > Looking >> >> >> >> > > at >> >> >> >> > > >>>>> free RAM is even worse because it gives you undefined >> >> >> >behavior. >> >> >> >> > > >>>> >> >> >> >> > > >>>> Guys, I can not understand how this dynamic memory >> >> >> >allocation's >> >> >> >> > > >> high-level >> >> >> >> > > >>>> behavior (with the persistence DISABLED) is different >> >> >from >> >> >> >the >> >> >> >> > legacy >> >> >> >> > > >>>> off-heap memory we had in 1.x. Both off-heap memories >> >> >> >allocate the >> >> >> >> > > >> space on >> >> >> >> > > >>>> demand, the current just does this more aggressively >> >> >> >requesting >> >> >> >> big >> >> >> >> > > >> chunks. >> >> >> >> > > >>>> >> >> >> >> > > >>>> Next, the legacy one was unlimited by default and the >> >> >user >> >> >> >can >> >> >> >> start >> >> >> >> > > as >> >> >> >> > > >>>> many nodes as he wanted on a laptop and preload as >> >much >> >> >data >> >> >> >as he >> >> >> >> > > >> needed. >> >> >> >> > > >>>> Sure he could bring down the laptop if too many >> >entries >> >> >were >> >> >> >> > injected >> >> >> >> > > >> into >> >> >> >> > > >>>> the local cluster. But that’s about too massive >> >> >preloading >> >> >> >and not >> >> >> >> > > >> caused >> >> >> >> > > >>>> by the ability of the legacy off-heap memory to grow >> >> >> >infinitely. >> >> >> >> The >> >> >> >> > > >> same >> >> >> >> > > >>>> preloading would cause a hang if the Java heap memory >> >> >mode >> >> >> >is >> >> >> >> used. >> >> >> >> > > >>>> >> >> >> >> > > >>>> The upshot is that the massive preloading of data on >> >the >> >> >> >local >> >> >> >> > laptop >> >> >> >> > > >>>> should not fixed with repealing of the dynamic memory >> >> >> >allocation. >> >> >> >> > > >>>> Is there any other reason why we have to use the >> >static >> >> >> >memory >> >> >> >> > > >> allocation >> >> >> >> > > >>>> for the case when the persistence is disabled? I think >> >> >the >> >> >> >case >> >> >> >> with >> >> >> >> > > the >> >> >> >> > > >>>> persistence should be reviewed separately. >> >> >> >> > > >>>> >> >> >> >> > > >>>> — >> >> >> >> > > >>>> Denis >> >> >> >> > > >>>> >> >> >> >> > > >>>>> On Aug 2, 2017, at 12:45 AM, Alexey Goncharuk < >> >> >> >> > > >>>> alexey.goncha...@gmail.com> wrote: >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> Dmitriy, >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> The reason behind this is the need to to be able to >> >> >evict >> >> >> >and >> >> >> >> load >> >> >> >> > > >> pages >> >> >> >> > > >>>> to >> >> >> >> > > >>>>> disk, thus we need to preserve a PageId->Pointer >> >mapping >> >> >in >> >> >> >> memory. >> >> >> >> > > In >> >> >> >> > > >>>>> order to do this in the most efficient way, we need >> >to >> >> >know >> >> >> >in >> >> >> >> > > advance >> >> >> >> > > >>>> all >> >> >> >> > > >>>>> the address ranges we work with. We can add dynamic >> >> >memory >> >> >> >> > extension >> >> >> >> > > >> for >> >> >> >> > > >>>>> persistence-enabled config, but this will add yet >> >> >another >> >> >> >step of >> >> >> >> > > >>>>> indirection when resolving every page address, which >> >> >adds a >> >> >> >> > > noticeable >> >> >> >> > > >>>>> performance penalty. >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> 2017-08-02 10:37 GMT+03:00 Dmitriy Setrakyan < >> >> >> >> > dsetrak...@apache.org >> >> >> >> > > >: >> >> >> >> > > >>>>> >> >> >> >> > > >>>>>> On Wed, Aug 2, 2017 at 9:33 AM, Vladimir Ozerov < >> >> >> >> > > voze...@gridgain.com >> >> >> >> > > >>> >> >> >> >> > > >>>>>> wrote: >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>>> Dima, >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>>> Probably folks who worked closely with storage know >> >> >why. >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>> Without knowing why, how can we make a decision? >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>> Alexey Goncharuk, was it you who made the decision >> >> >about >> >> >> >not >> >> >> >> using >> >> >> >> > > >>>>>> increments? Do know remember what was the reason? >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>>> The very problem is that before being started once >> >on >> >> >> >> production >> >> >> >> > > >>>>>>> environment, Ignite will typically be started >> >hundred >> >> >> >times on >> >> >> >> > > >>>>>> developer's >> >> >> >> > > >>>>>>> environment. I think that default should be ~10% of >> >> >total >> >> >> >RAM. >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>> Why not 80% of *free *RAM? >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>> >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>>> On Wed, Aug 2, 2017 at 10:21 AM, Dmitriy Setrakyan >> >< >> >> >> >> > > >>>>>> dsetrak...@apache.org> >> >> >> >> > > >>>>>>> wrote: >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>>>> On Wed, Aug 2, 2017 at 7:27 AM, Vladimir Ozerov < >> >> >> >> > > >> voze...@gridgain.com >> >> >> >> > > >>>>> >> >> >> >> > > >>>>>>>> wrote: >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>>> Please see original Sergey's message - when >> >> >persistence >> >> >> >is >> >> >> >> > > enabled, >> >> >> >> > > >>>>>>>> memory >> >> >> >> > > >>>>>>>>> is not allocated incrementally, maxSize is used. >> >> >> >> > > >>>>>>>>> >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>> Why? >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>>> Default settings must allow for normal work on >> >> >> >developer's >> >> >> >> > > >>>>>> environment. >> >> >> >> > > >>>>>>>>> >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>> Agree, but why not in increments? >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>>>> >> >> >> >> > > >>>>>>>>> ср, 2 авг. 2017 г. в 1:10, Denis Magda >> >> >> ><dma...@apache.org>: >> >> >> >> > > >>>>>>>>> >> >> >> >> > > >>>>>>>>>>> Why not allocate in increments automatically? >> >> >> >> > > >>>>>>>>>> >> >> >> >> > > >>>>>>>>>> This is exactly how the allocation works right >> >now. >> >> >> >The >> >> >> >> memory >> >> >> >> > > >> will >> >> >> >> > > >>>>>>>> grow >> >> >> >> > > >>>>>>>>>> incrementally until the max size is reached (80% >> >of >> >> >> >RAM by >> >> >> >> > > >>>>>> default). >> >> >> >> > > >>>>>>>>>> >> >> >> >> > > >>>>>>>>>> — >> >> >> >> > > >>>>>>>>>> Denis >> >> >> >> > > >>>>>>>>>> >> >> >> >> > > >>>>>>>>>>> On Aug 1, 2017, at 3:03 PM, >> >dsetrak...@apache.org >> >> >> >wrote: >> >> >> >> > > >>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>> Vova, 1GB seems a bit too small for me, and >> >> >frankly i >> >> >> >do >> >> >> >> not >> >> >> >> > > want >> >> >> >> > > >>>>>>> t o >> >> >> >> > > >>>>>>>>>> guess. Why not allocate in increments >> >> >automatically? >> >> >> >> > > >>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>> D. >> >> >> >> > > >>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>> On Aug 1, 2017, 11:03 PM, at 11:03 PM, Vladimir >> >> >> >Ozerov < >> >> >> >> > > >>>>>>>>>> voze...@gridgain.com> wrote: >> >> >> >> > > >>>>>>>>>>>> Denis, >> >> >> >> > > >>>>>>>>>>>> No doubts you haven't heard about it - AI 2.1 >> >> >with >> >> >> >> > > persistence, >> >> >> >> > > >>>>>>> when >> >> >> >> > > >>>>>>>>>>>> 80% of >> >> >> >> > > >>>>>>>>>>>> RAM is allocated right away, was released >> >several >> >> >> >days >> >> >> >> ago. >> >> >> >> > > How >> >> >> >> > > >>>>>> do >> >> >> >> > > >>>>>>>> you >> >> >> >> > > >>>>>>>>>>>> think, how many users tried it already? >> >> >> >> > > >>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>> Guys, >> >> >> >> > > >>>>>>>>>>>> Do you really think allocating 80% of >> >available >> >> >RAM >> >> >> >is a >> >> >> >> > > normal >> >> >> >> > > >>>>>>>> thing? >> >> >> >> > > >>>>>>>>>>>> Take >> >> >> >> > > >>>>>>>>>>>> your laptop and check how many available RAM >> >you >> >> >> >have >> >> >> >> right >> >> >> >> > > now. >> >> >> >> > > >>>>>>> Do >> >> >> >> > > >>>>>>>>> you >> >> >> >> > > >>>>>>>>>>>> fit >> >> >> >> > > >>>>>>>>>>>> to remaining 20%? If not, then running AI with >> >> >> >persistence >> >> >> >> > > with >> >> >> >> > > >>>>>>> all >> >> >> >> > > >>>>>>>>>>>> defaults will bring your machine down. This is >> >> >> >insane. We >> >> >> >> > > shold >> >> >> >> > > >>>>>>>>>>>> allocate no >> >> >> >> > > >>>>>>>>>>>> more than 1Gb, so that user can play with it >> >> >without >> >> >> >any >> >> >> >> > > >>>>>> problems. >> >> >> >> > > >>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>> On Tue, Aug 1, 2017 at 10:26 PM, Denis Magda < >> >> >> >> > > dma...@apache.org >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>>>>> wrote: >> >> >> >> > > >>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>> My vote goes for option #1 too. I don’t think >> >> >that >> >> >> >80% is >> >> >> >> > too >> >> >> >> > > >>>>>>>>>>>> aggressive >> >> >> >> > > >>>>>>>>>>>>> to bring it down. >> >> >> >> > > >>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>> IGNITE-5717 was created to fix the issue of >> >the >> >> >80% >> >> >> >RAM >> >> >> >> > > >>>>>>> allocation >> >> >> >> > > >>>>>>>> on >> >> >> >> > > >>>>>>>>>>>> 64 >> >> >> >> > > >>>>>>>>>>>>> bit systems when Ignite works on top of 32 >> >bit >> >> >JVM. >> >> >> >I’ve >> >> >> >> > not >> >> >> >> > > >>>>>>> heard >> >> >> >> > > >>>>>>>> of >> >> >> >> > > >>>>>>>>>>>> any >> >> >> >> > > >>>>>>>>>>>>> other complaints in regards the default >> >> >allocation >> >> >> >size. >> >> >> >> > > >>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>> — >> >> >> >> > > >>>>>>>>>>>>> Denis >> >> >> >> > > >>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>> On Aug 1, 2017, at 10:58 AM, >> >> >dsetrak...@apache.org >> >> >> >> wrote: >> >> >> >> > > >>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>> I prefer option #1. >> >> >> >> > > >>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>> D. >> >> >> >> > > >>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>> On Aug 1, 2017, 11:20 AM, at 11:20 AM, >> >Sergey >> >> >> >Chugunov < >> >> >> >> > > >>>>>>>>>>>>> sergey.chugu...@gmail.com> wrote: >> >> >> >> > > >>>>>>>>>>>>>>> Folks, >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> I would like to get back to the question >> >about >> >> >> >> > MemoryPolicy >> >> >> >> > > >>>>>>>>>>>> maxMemory >> >> >> >> > > >>>>>>>>>>>>>>> defaults. >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> Although MemoryPolicy may be configured >> >with >> >> >> >initial >> >> >> >> and >> >> >> >> > > >>>>>>>> maxMemory >> >> >> >> > > >>>>>>>>>>>>>>> settings, when persistence is used >> >> >MemoryPolicy >> >> >> >always >> >> >> >> > > >>>>>>> allocates >> >> >> >> > > >>>>>>>>>>>>>>> maxMemory >> >> >> >> > > >>>>>>>>>>>>>>> size for performance reasons. >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> As default size of maxMemory is 80% of >> >> >physical >> >> >> >memory >> >> >> >> it >> >> >> >> > > >>>>>>> causes >> >> >> >> > > >>>>>>>>>>>> OOME >> >> >> >> > > >>>>>>>>>>>>>>> exceptions of 32 bit platforms (either on >> >OS >> >> >or >> >> >> >JVM >> >> >> >> > level) >> >> >> >> > > >>>>>> and >> >> >> >> > > >>>>>>>>>>>> hurts >> >> >> >> > > >>>>>>>>>>>>>>> performance in setups when multiple Ignite >> >> >nodes >> >> >> >are >> >> >> >> > > started >> >> >> >> > > >>>>>> on >> >> >> >> > > >>>>>>>>>>>> the >> >> >> >> > > >>>>>>>>>>>>>>> same >> >> >> >> > > >>>>>>>>>>>>>>> physical server. >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> I suggest to rethink these defaults and >> >switch >> >> >to >> >> >> >other >> >> >> >> > > >>>>>>> options: >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> - Check whether platform is 32 or 64 bits >> >and >> >> >> >adapt >> >> >> >> > > defaults. >> >> >> >> > > >>>>>>> In >> >> >> >> > > >>>>>>>>>>>> this >> >> >> >> > > >>>>>>>>>>>>>>> case we still need to address the issue >> >with >> >> >> >multiple >> >> >> >> > nodes >> >> >> >> > > >>>>>> on >> >> >> >> > > >>>>>>>> one >> >> >> >> > > >>>>>>>>>>>>>>> machine >> >> >> >> > > >>>>>>>>>>>>>>> even on 64 bit systems. >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> - Lower defaults for maxMemory and >> >allocate, >> >> >for >> >> >> >> > instance, >> >> >> >> > > >>>>>>>>>>>> max(0.3 * >> >> >> >> > > >>>>>>>>>>>>>>> availableMemory, 1Gb). >> >> >> >> > > >>>>>>>>>>>>>>> This option allows us to solve all issues >> >with >> >> >> >starting >> >> >> >> > on >> >> >> >> > > 32 >> >> >> >> > > >>>>>>> bit >> >> >> >> > > >>>>>>>>>>>>>>> platforms and reduce instability with >> >multiple >> >> >> >nodes on >> >> >> >> > the >> >> >> >> > > >>>>>>> same >> >> >> >> > > >>>>>>>>>>>>>>> machine. >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> Thoughts and/or other options? >> >> >> >> > > >>>>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>>>> Thanks, >> >> >> >> > > >>>>>>>>>>>>>>> Sergey. >> >> >> >> > > >>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>>>>> >> >> >> >> > > >>>>>>>>>> >> >> >> >> > > >>>>>>>>>> >> >> >> >> > > >>>>>>>>> >> >> >> >> > > >>>>>>>> >> >> >> >> > > >>>>>>> >> >> >> >> > > >>>>>> >> >> >> >> > > >>>> >> >> >> >> > > >>>> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> > > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> > >
