> This suggests there was 5GB free while the allocation failed. > This *can* be a fragmentation issue (e.g., you asked for a 1 GB allocation, > but we couldn't free a 1GB consecutive area), but can also be a malloc() of a > ridiculous amount. Since commit 7ea953ca7d6533c025e535be49ee5bd2567fc8f3 a > malloc() of over the amount of memory we have prints a different error > message, but perhaps you still have some very large (but less than 10GB) > single allocation?
I don’t think so. I’m running the erlang OTP BEAM virtual machine though. > The sad thing is that since we fail in the memory reclaimer, not in the > malloc(), you know which malloc() failed. This is > https://github.com/cloudius-systems/osv/issues/585. > One ad-hoc thing you can try is to connect with gdb, and see which OSv thread > is waiting in malloc - and see what malloc() it is trying to do. It fails allocating 25MB: #9 0x00000000003dde15 in std_malloc (size=size@entry=24117248, alignment=alignment@entry=16) at core/mempool.cc:1559 1559 ret = memory::malloc_large(size, alignment); The size surprises me a little - so I need to understand whats going on. However, as you say, there is plenty of memory available so I guess it is fragmentation. > We also have an issue about huge malloc() calls not actually needing > consecutive memory: https://github.com/cloudius-systems/osv/issues/854 - if > this is fixed it will be easier to allocate large amounts of contiguous > memory with malloc(). Fixing that is probably beyond my understanding of OSv at the moment… Cheers, Rick -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
