"dbz.c: Can't malloc" during expire

[bill davidsen]

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.