dccd mmap problems?

Vernon Schryver vjs@calcite.rhyolite.com
Wed Aug 3 07:01:17 UTC 2005


> From: Jeffrey Collyer 

> I'm getting a ton of these in the logs lately.  Upgraded to 1.3.12 just 
> to be sure it wasn't a bug.
> Machine has 4G of memory, and isn't doing much else.  Running linux on 
> Compaq hardware.  Certainly doesn't seem to be out of memory.
>
> Aug  2 16:53:11 dcc1 dccd[825]: try #1 
> mmap(/var/dcc/dcc_db,0x17f4000,0x23ee0000): Cannot allocate memory
> Aug  2 16:53:11 dcc1 dccd[825]: try #2 
> mmap(/var/dcc/dcc_db,0x17f4000,0x23ee0000) ok

Today I started seeing a lot of those on a 4 GByte FreeBSD 5.4 system.
(Thanks to what I think is sloppiness by the HP/Compaq people in
allocating PCI memory space, it's really only a 3.5 GByte system.
It seems to be industry standard sloppiness.  I can't tell you how
much it bugs me pay for 4 GByte and waste 500 MByte.)

In my case, I think I understand what is going on:

  - The default FreeBSD 5.4 kernel will not allocate more than about
      2.2 GByte of virtual memory to a process, at least not via mmap().

  - Recent versions of dccd and dbclean retry mmap() when it fails,
     after first trying to release some other memory.  This keeps
     things from crashing, but things run somewhat slowly as well
     with a lot of racket.

  - A new bug in dccd causes the flooding thresholds to be 0 if dccd
     is not started with the /var/dcc/libexec/start-dccd script or if
     dccm is not configured with a rejection threshold.  When this
     happens, DCC servers flood everything instead of only likely bulk
     reports.  Some of the public DCC servers installed 1.3.12 in the
     last day or so and have been flooding many more checkums.  That
     has increased the size of the consensus database on DCC servers
     with lots of RAM to more than 2 GBytes.

I'm about to release 1.3.13 which will fix the threshold bug and
reduce the default database window size to 2000 MByte on all systems
except IRIX and SunOS.  I would be happy to hear about other systems
that can really handle large processes.  I'm only guessing based
on histories about IRIX and SunOS.

1.3.13 might help Linux systems.  On the hand, I've seen evidence of
other oddities on Linux with large mmap() spaces.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.