[Mono-dev] Boehm GC reaching max_map_count

[pablosa...@terra.es]

Hi there,

We're experiencing problems with a server running on a 64bits box with
plenty of RAM.

After a few hours it crashed and the problem was that it was reaching
the max_map_count limit.

We raised it to two times the default (64k) but it also crashed.

The problem is the following: normally the process has a number close to
100 or 200 mappings, but then, in less than a second, it grows beyond
the limit and crashes.

The process is not allocating memory (it stays stable although quite
high) at this point, so we think it must be related to BoehmGC doing
some collection or something.

The process is heavily multithreaded.

Mono is built with --with-large-heap and runs on a 64 bits box (where
the pointer guessing issues with BoehmGC don't hit us so strongly as it
happens on 32 bit systems).

Well, anyone has any idea why this is happening?

Thanks,

pablo
_______________________________________________
Mono-devel-list mailing list
Mono-de...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Bassam Tabbara]

We are seeing the same issue. Mono is mapping a lot of memory:

> cat /proc/<pid>/maps | wc -l
21880

And it then reaches he max_map_count limit and dies:

Program terminated with signal 6, Aborted.
#0 0x00007f69c02f51b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
in ../nptl/sysdeps/unix/sysv/linux/raise.c
#0 0x00007f69c02f51b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007f69c02f7fc0 in *__GI_abort () at abort.c:92
#2 0x0000000000493859 in mono_handle_native_sigsegv (signal=-1944970304, ctx=<value optimized out>) at mini-exceptions.c:2223
#3 <signal handler called>
#4 0x00007f69c02f51b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5 0x00007f69c02f7fc0 in *__GI_abort () at abort.c:92
#6 0x00000000005f8171 in GC_abort (msg=0x6b4bb1 "mmap(...PROT_NONE...) failed") at misc.c:1099
#7 0x00000000005ea028 in GC_unmap (start=0x7f69956e6000 "\350x\211\002", bytes=8192) at os_dep.c:2040
#8 0x00000000005f9049 in GC_unmap_old () at allchblk.c:383
#9 0x00000000005e73ce in GC_finish_collection () at alloc.c:776
#10 0x00000000005e69ef in GC_try_to_collect_inner (stop_func=0x5e631c <GC_never_stop_func>) at alloc.c:393
#11 0x00000000005e7ae8 in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0) at alloc.c:1045
#12 0x00000000005f6978 in GC_alloc_large (lw=260, k=0, flags=0) at malloc.c:60
#13 0x00000000005f6d65 in GC_generic_malloc (lb=2080, k=0) at malloc.c:204
#14 0x00000000005f6f4e in GC_malloc_atomic (lb=2080) at malloc.c:270
#15 0x00000000005e81db in GC_local_malloc_atomic (bytes=2080) at pthread_support.c:380

mmap returns ENOMEM.

We are going to increase the max_map_count limit, but http://www.novell.com/support/viewContent.do?externalId=7000830&sliceId=1 warns against this (especially that it seems that 128 bytes are allocated in the kernel). For small mmaps like 4K or 8K that we see, this seems quite inefficient.

Any help here appreciated.

Thanks!
Bassam