On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew <jfkth...@gmail.com> wrote: > > I took a quick look at a random one of these OOMs[1], and what strikes me > about it is that according to the crash report: > > Total Virtual Memory 2147352576 > > Available Virtual Memory 122331136 > > System Memory Use Percentage 52 > > Available Page File 4932567040 > > Available Physical Memory 1790652416 > > OOM Allocation Size 24 > > it seems like the system is still some way from running out of memory. > Available Virtual Memory is "only" 122MB, which admittedly isn't very much > in present-day terms, but still....why can't we successfully allocate a > 24-byte block? Can those 122MB really be _so_ fragmented?!
I looked at a bunch of these yesterday. It's pretty common for OOM to occur when there is around 200--250 MiB of available virtual memory; 122 MB is probably lower than normal. As bsmedberg said, jemalloc uses 1 MiB chunks so the size of 24 is something of a red herring here. (It's still useful in the sense that it's tiny, so making this allocation fallible is unlikely to be helpful.) More generally, I did a search yesterday of all our "OOM | small" crashes for the past week. About 5% of them occur when the user has > 1 GiB of available virtual memory *and* > 1 GiB of available physical memory, which is surprising. I would love to see a scatter plot showing available physical memory vs. available virtual memory for all our "OOM | small" crashes. bsmedberg, do we have tools to extract that kind of data from crash-stats? Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
