Problem:
A few AIX servers have TSM backup error:
ANS1030E The operating system refused a TSM request for memory allocation.
Solution:
- Use the client option MEMORYEFFICIENTBACKUP YES. The maximum virtual memory used by the client process in this case becomes 300 bytes times the maximum number of files in any one directory.
Add the following line in dsm.sys and recycle dsmc scheduler:
memoryefficientbackup yes
- Use the client option MEMORYEFFICIENTBACKUP DISKCACHEMETHOD. This option is only available on the Version 5.4 client, or later. The maximum virtual memory used by the client process in this case is usually less than 20 MB. A significant amount of client disk space might be required. See the Backup-Archive Clients Installation and User’s Guide for details.
For example:
Add the following line in dsm.sys and recycle dsmc scheduler:
INCLUDE.FS /your_filesystem_name MEMORYEFFICIENTBACKUP=DISKCACHEMETHOD DISKCACHELOCATION=/TSM_disk_cache
- Use the Tivoli Storage Manager journal-based incremental backup function (Windows® client, and AIX® with a Version 5.3.2 client, or later). A full incremental backup must be completed before |a journal-based backup is possible.
- Use the Tivoli Storage Manager image |backup function to back up the entire volume. This might require less time and resources than using incremental backups on some file systems with a very large number of very small files.
More explanation:
For incremental backups the client uses an average of about 300 bytes of memory for each file system object (a file or directory). These 300 bytes include the path and name of the object and attributes. The average memory requirement increases if longer file or directory names or more deeply nested directories are used. For a file system with 1 million files and directories, |for example, the client would require about 300 MB of virtual memory.
The size of a file system in gigabytes is not an important factor in determining the backup-archive client virtual memory requirements, except as it relates to the number of files and directories in that file system.
Virtual memory refers to the memory that is addressable by an application |process. The virtual memory size can be greater or smaller than the computer’s|real (physical) memory size. For example, a 32-bit application can address 4 GB of virtual memory. The application might be running on a workstation |that has only 512 MB of real memory, or it might be running on a server that has 8 GB of real memory.
|
Only part of an application’s virtual memory might be used for allocating |data structures. The maximum virtual memory available for allocation by a |32-bit process depends on the operating system. For Windows, |this is 2 GB for most processes. The Version 5.3.2 (and later) Windows client |can use up to 3 GB for data structures if the client system has been booted |using the /3gb boot.ini flag – . See Microsoft® Knowledge Base article 291988 |(http://support.microsoft.com/kb/291988). For AIX 5L™, this is nine memory |segments, or 2.25 GB. Other operating systems might have different limits. |Operating system quotas or limits might need to be set to allow a process |to use the maximum virtual memory. Refer to the ulimit command on UNIX systems.
|
The maximum number of files and directories that Tivoli Storage Manager can |back up on a 32-bit system (2 GB of process memory) using a single incremental |backup process and the default option MEMORYEFFICIENTBACKUP NO is about 7 |million: (2 * 1024 * 1024 * 1024) / (300 * 1000 * 1000). If the client process |tries to exceed the operating system process virtual memory limit, the backup |fails. If the client process memory requirements exceed the amount of real |memory on the system but do not exceed the virtual memory limit, then the |backup might succeed but is likely to exhibit poor performance due to paging.
Using a 64-bit client, if available for the platform in question, essentially |eliminates any concern about the virtual memory requirements, but might still |require significant real memory for optimal performance.
