"dbz.c: Can't malloc" during expire
davidsen at tmr.com
Tue Apr 16 13:11:42 UTC 2002
In article <72bsctguf4.fsf at nd1.eng.demon.net>,
Alex Kiernan <alexk at demon.net> wrote:
| Elizabeth Zaenger <liz at eecs.umich.edu> writes:
| > Hi Alex,
| > Thanks, but what does this mean? Or rather, what's the fix?
| Larger ulimit, more swap, more physical RAM, move to 64 bit
| architecure (probably in that order).
Actually, after setting ulimit higher, if you can't add more physical
memory I would consider rebuilding with tagged-hash on. Having run a few
too-small machines I believe that the performance hit will be less than
using a lot of swap and paging heavily.
| > (Someone suggested I needed more swap, but I can't see any evidence of
| > that....)
| > > From: Alex Kiernan <alexk at demon.net>
| > >
| > > Elizabeth Zaenger <liz at eecs.umich.edu> writes:
| > >
| > > > expire begin Mon Apr 1 12:10:24 EST 2002: (-v1)
| > > > dbz.c:1283 Can't malloc 259001196 bytes: Cannot allocate memoryexpire end Mon Apr 1 12:10:27 EST 2002
| > >
| > > You ran out of memory when the history hash spilled from one table to
| > > two (or from two to three etc.).
bill davidsen <davidsen at tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
More information about the inn-workers