large history: 2GB shared memory limit

[Bill Davidsen]

Russ Allbery wrote:
> Patrick Schreurs <patricks at support.nl> writes:
> 
> 
>>Today we hit the 2GB limit in shared memory (mmap) with innd. This is
>>mainly caused by a large history:
> 
> 
>>-rw-rw-r--    1 news     news     9343510653 Jun  9 21:56 history
>>-rw-rw-r--    1 news     news     1352977086 Jun  9 21:56 history.hash
>>-rw-rw-r--    1 news     news     1803969448 Jun  9 21:56 history.index
> 
> 
>>This resulted is this error:
>>Jun  9 16:26:54 news3 innd: CNFS-sm: CNFSinitdisks: mmap for /spool1/13 offset 0 len 4620288 failed: Cannot allocate memory
> 
> 
>>This 2GB limit seems to be a known issue on 32-bit platforms.
> 
> 
> Yeah, there's a limit on the amount of addressable memory (in theory, 4GB,
> but conventionally the kernel reserves 2GB for its own purposes).

Depends on the O/S, of course. If you run Linux you can easily build a 
3GB kernel with recent source, I haven't tried the 4GB setup, I haven't 
read any recent reports of stability issues, some claim there are 
performance issues. I suspect that 3GB will give you a bit of breathing 
room.
> 
> 
>>As a workaround i've disabled INND_DBZINCORE in config.h
> 
> 
> That's the workaround that I'm aware of.
> 
> 
>>Is the only solution for this problem to use a 64-bit platform?
> 
> 
> Right now, yes.
> 
> 
>>I've read something about a history api. Any development on this subject?
> 
> 
> Not yet.  I have a lot of ideas, but haven't had a chance to implement
> anything.  It should be pretty easy to make the text history file smaller,
> but making the hash and/or index smaller is going to be more difficult.
> 
> 
>>Does anyone have any experience with history in ramdisk with inn?
> 
> 
> Not personally, but there isn't any reason I can think of why it wouldn't
> work.

Back where main memory was small we did use external solid state drives, 
and that did wonders for performance. Currently when you use enough 
physical memory you get the effect of having anything you use frequently 
in memory, as disk buffers if not mapped.

I'm not convinced that the "just keep using a bigger hammer" approach is 
the one we want long range.

-- 
    -bill davidsen (davidsen at tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me