AFAIK, glibc allocator uses arenas for minimize contention between threads
when they trying to access
or free preallocated bit of memory. But seems that we
use -XX:+AlwaysPreTouch, so heap is allocated
and committed at start time. We allocate memory for durable memory in one
thread.
So I think there will be not so much contention between threads for native
memory pools.

Also, there is another approach -- try to use jemalloc.
This allocator shows better result than default glibc malloc in our
scenarios. (memory consumption) [1]

[1] --
http://ithare.com/testing-memory-allocators-ptmalloc2-tcmalloc-hoard-jemalloc-while-trying-to-simulate-real-world-loads/



чт, 23 июл. 2020 г. в 14:19, Ivan Bessonov <bessonov...@gmail.com>:

> Hello Ivan,
>
> It feels like the problem is more about new starting threads rather than
> the
> allocation of offheap regions. Plus I'd like to see results soon, your
> proposal is
> a major change for Ignite that can't be implemented fast enough.
>
> Anyway, I think this makes sense, considering that one day Unsafe will be
> removed. But I wouldn't think about it right now, maybe as a separate
> proposal...
>
>
>
> чт, 23 июл. 2020 г. в 13:40, Ivan Daschinsky <ivanda...@gmail.com>:
>
> > Ivan, I think that we should use mmap/munmap to allocate huge chunks of
> > memory.
> >
> > I've experimented with JNA and invoke mmap/munmap with it and it works
> > fine.
> > May be we can create module (similar to direct-io) that use mmap/munap on
> > platforms, that support them
> > and fallback to Unsafe if not?
> >
> > чт, 23 июл. 2020 г. в 13:31, Ivan Bessonov <bessonov...@gmail.com>:
> >
> > > Hello Igniters,
> > >
> > > I'd like to discuss the current issue with "out of memory" fails on
> > > TeamCity. Particularly suites [1]
> > > and [2], they have quite a lot of "Exit code 137" failures.
> > >
> > > I investigated the "PDS (Indexing)" suite under [3]. There's another
> > > similar issue as well: [4].
> > > I came to the conclusion that the main problem is inside the default
> > memory
> > > allocator (malloc).
> > > Let me explain the way I see it right now:
> > >
> > > "malloc" is allowed to allocate (for internal usages) up to 8 * (number
> > of
> > > cores) blocks called
> > > ARENA, 64 mb each. This may happen when a program creates/stops threads
> > > frequently and
> > > allocates a lot of memory all the time, which is exactly what our tests
> > do.
> > > Given that TC agents
> > > have 32 cores, 8 * 32 * 64 mb gives 16 gigabytes, that's like the whole
> > > amount of RAM on the
> > > single agent.
> > >
> > > The total amount of arenas can be manually lowered by setting
> > > the MALLOC_ARENA_MAX
> > > environment variable to 4 (or other small value). I tried it locally
> and
> > in
> > > PDS (Indexing) suite
> > > settings on TC, results look very promising: [5]
> > >
> > > It is said that changing this variable may lead to some performance
> > > degradation, but it's hard to tell whether we have it or not, because
> the
> > > suite usually failed before it was completed.
> > >
> > > So, I have two questions right now:
> > >
> > > - can those of you, who are into hardcore Linux and C, confirm that the
> > > solution can help us? Experiments show that it completely solves the
> > > problem.
> > > - can you please point me to a person who usually does TC maintenance?
> > I'm
> > > not entirely sure
> > > that I can propagate this environment variable to all suites by myself,
> > > which is necessary to
> > > avoid occasional error 137 (resulted from the same problem) in future.
> I
> > > just don't know all the
> > > details about suites structure.
> > >
> > > Thank you!
> > >
> > > [1]
> > >
> > >
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing&tab=buildTypeHistoryList&state=failed&branch_IgniteTests24Java8=%3Cdefault%3E
> > > [2]
> > >
> > >
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds4&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E&state=failed
> > > [3] https://issues.apache.org/jira/browse/IGNITE-13266
> > > [4] https://issues.apache.org/jira/browse/IGNITE-13263
> > > [5]
> > >
> > >
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing&tab=buildTypeHistoryList&branch_IgniteTests24Java8=pull%2F8051%2Fhead
> > >
> > > --
> > > Sincerely yours,
> > > Ivan Bessonov
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Sincerely yours,
> Ivan Bessonov
>


-- 
Sincerely yours, Ivan Daschinskiy

Reply via email to