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