Amanda-Users

Re: memory allocation error

2005-08-30 12:42:35
Subject: Re: memory allocation error
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Tue, 30 Aug 2005 12:23:57 -0400
On Tue, Aug 30, 2005 at 08:57:38AM -0400, Joshua Baker-LePain wrote:
> My amanda server has a changer with 2 drives in it and backs up 4 largeish 
> clients.  So, I run 2 configs, each handling 2 clients.  The first kicks 
> off at 12:01 AM, and the other at 12:06.  Every once in a while, every DLE 
> on one of the clients from the 2nd config has estimate timeouts.  Today, I 
> found this in the amdump.N file for each of those times:
> 
> planner: time 0.084: dgram_send_addr: sendto($ADDRESS.10080) failed: Cannot 
> allocate memory 
> send req failed: Cannot allocate memory
> planner: time 10.104: dgram_send_addr: sendto($ADDRESS.10080) failed:  Cannot 
> allocate memory 
> send req failed: Cannot allocate memory
> planner: time 20.103: dgram_send_addr: sendto($ADDRESS.10080) failed: Cannot 
> allocate memory 
> send req failed: Cannot allocate memory
> 
> Can anyone explain to me exactly what's going on there, and how to fix it?  
> Do I need to stagger the startup times more?  Increase a network buffer 
> somewhere?
> 
> The server is a dual 2.4GHz Xeon system with 2GB of RAM and an e1000 NIC 
> running centos3.
> 

Two areas I ran into recently at a client's might be worth looking into,
to what size are the individual processes growing and how much swap is being 
used.

Not much you can do about the first short of going to a 64-bit system.
Linux's maximum process size is generally 3GB on a 32-bit system.
Swap availability does not impact this limit.  That was my client's
problem, the process size (not amanda) was growing over 3GB.

Swap availability would impact how large in total all process could
grow.  If you are running two configs with lots of dumpers and gzips
etc., maybe you are hitting this as a limit.  But if you are using
lots of swap, you are probably also having performance problems so
you might want to increase physical memory as well.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

<Prev in Thread] Current Thread [Next in Thread>