ADSM-L

Re: [ADSM-L] Linux client memory woes

2009-12-31 10:47:54
Subject: Re: [ADSM-L] Linux client memory woes
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 31 Dec 2009 10:46:51 -0500
If it truly is a memory issue you can't get around, you could define
multiple client setups.  Each could backup a couple mount points.  The
details would be messy (separate dsm.opt files and setups, maybe separate
nodes (but not sure about this)), but it would let multiple separate backup
process run.

Rick





             Michael Green
             <mishagreen@GMAIL
             .COM>                                                      To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Linux client memory woes


             12/31/2009 09:27
             AM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






I have a client installation on a Linux TSM server. The server is SLES
10 SP2 x64 running on a hefty IBM x3850 8-way with 32GB or RAM.
The server has over a dozen NFS mounts which need to be backed up. The
total count of objects in all the NFS mounts is now approaching 40
million.
Since years ago this client was configured to use 8 sessions to
complete the backup in time via SHAREDMEM connection to the TSM server
running on the same machine (see above).

The problem has started a week ago from the following error:

ANS1030E The operating system refused a TSM request for memory allocation.

The monitoring of memory consumption of DSMC process during runtime
revealed that the client starts from modest ~47MB and climbs all the
way up to about 4GB at which point the error is received and the
operation is aborted. The server itself still has about 23GB of free
RAM when it happens.

I was able to work around the problem by lowering the amount of
concurrent sessions to 4, but that increases the backup windows
considerably. That's a pity because the server itself has enough
physical resources to run 8 sessions or even more. Running any amount
of sessions higher than 4 leads to ANS1030E.

I haven't tried to use memoryefficient backup and wouldn't want to
even try before I fully understand what's going on.

To me it looks like 32bit memory addressing space limitation. And I've
been thinking that 4GB per process limitation is thing of the past.
Sorry lot of 32-bit systems. Is the LinuxX86 client that IBM
distributes is still limited to 4GB of RAM?

Oh, and I'm runnig
server v 5.5.3 x64
client 5.4.3 with API and API64 RPMs.

Initial memory consumption:
 PPID   PID STAT %CPU %MEM   RSS    VSZ  STARTED CMD
 3910  5729 Sl+   7.3  0.0  5648  47864 13:05:26 dsmc -resourceu=5


Memory consumption immediately after the ANS1030E is issued:
 PPID   PID STAT %CPU %MEM   RSS    VSZ  STARTED CMD
 3910  5729 Sl+   106 12.4 4099600 4150564 13:05:26 dsmc -resourceu=5

12.4% of 32GB is ~4GB.
--
Warm regards,
Michael Green


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

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