From: Tom Metro <[email protected]>
Date: Wed, 09 Mar 2011 02:45:19 -0500
Bob Rogers wrote:
> 0. I assume you are already using ulimit to trigger the error
> sooner, rather than later . . .
I haven't gotten to the point of trying to intentionally reproduce the
issue, but ulimit would indeed do the trick. The problem was just
recently discovered when running the code on the QA cluster, which is
composed of VMs that have 1 GB of RAM, rather than the 16 GB of the
production nodes.
That's a plus, but I'm sure you'd rather not have to fill up even 1GB
(plus VM) on every debugging attempt. ;-}
> Out of memory during "large" request for %s
> (F) The malloc() function returned 0, indicating there was
> insufficient remaining memory (or virtual memory) to satisfy the
> request. However, the request was judged large enough
(compile-time
> default is 64K), so a possibility to shut down by trapping this
> error is granted.
I don't think I've ever seen the latter error.
I know I haven't. The only time I've had serious OOM debugging problems
was with code that used a *lot* of closures, which leaked badly in 5.6.
> 3. You might be able to use a "large" request to force a trappable
> OOM error, and inspect memory then.
So inject some code that periodically allocates 100 KB or something?
Maybe, though you'd still have to get lucky.
-Tom
Not necessarily. If you allocate and then free again immediately if you
get no error, then that could be the basis of a fairly reliable
"almost-OOM" detector, if you can manage to call it frequently enough.
And you should be able to trade frequency for size, to some extent: The
larger the test allocation, the less often you would need to run it.
Furthermore, if the failing code is allocating large numbers of smallish
objects, you wouldn't need to be very precise.
But you'd still have to figure out what to do with such a detector.
It would be nice if Perl could tell you the distribution of reachable
object sizes . . . just knowing how big it was would be a big clue to
what it was.
-- Bob
Perl memory debugger
theorist, third class
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
