The randomize_va_space feature of SQL2043N and linux, linuxspace

The randomize_va_space feature of SQL2043N and linux, linuxspace
After the database server is upgraded from redhat4.6 to redhat5.5, SQL2043N may occasionally occur when TSM backup is used.
View error:

[db2inst1@limt ~]$ db2 ? SQL2043NSQL2043N  Unable to start a child process or thread.Explanation: Unable to start up the child processes or threads required during theprocessing of a database utility. There may not be enough availablememory to create the new process or thread. The utility stopsprocessing.User response: Ensure the system limit for number of processes or threads has not beenreached (either increase the limit or reduce the number of processes orthreads already running). Ensure that there is sufficient memory for thenew process or thread. Resubmit the utility command  

From the description, it seems that the database fails to apply for memory, but the memory should be abundant. The redhat4.6 time is 16 GB, And the redhat5.5
After that, it has been increased to 64 GB, so there should be no insufficient memory, but the backup is done every day, and the occasional failure is acceptable, so I don't care about it. Then I am on duty.
It is found that other systems in the group may occasionally experience SQL2043N. It seems that this is not an occasional phenomenon. In the evening, I went back to Baidu to obtain SQL2043N.
For unexpected gains, find the following explanation on the official website:

Problem(Abstract)ASLR or Address Space Layout Randomization is a feature that is activated by default on some of the newer linux distributions. It is designed to load shared memory objects in random addresses.In DB2, multiple processes map a shared memory object at the same address across the processes. It was found that DB2 cannot guarantee the availability of address for the shared memory object when ASLR is turned on.Important note: DB2 10.1 has been enhanced so that ASLR can be safely enabled.SymptomThis conflict in the address space means that a process trying to attach a shared memory object to a specific address may not be able to do so, resulting in a failure in shmat subroutine. However, on subsequent retry (using a new process) the shared memory attachment may work. The result is a random set of failures. Some processes that have been known to see this error are: db2pd, db2egcf, and db2vend.Some of the behaviors seen include the following:For the db2pd command, it will report no data found even through the instance / database is active:Database SAMPLE not activated on database partition 0.For the db2egcf process, used for HA monitoring, the db2egcf may incorrectly determine the instance is down and initiate a failover.For the db2vend process, backup and log archive methods might fail with an error indicating a child process could not be started:SQL2043N  Unable to start a child process or thread.  Diagnosing the problemWhen this problem is suspected, check db2diag.log for the shmat failure like the following. Note that the same error message can also occur for a different cause. Hence, it's important to note the process that reported this error.FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:180MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG          "No Storage Available for allocation"          DIA8305C Memory allocation failure occurred.CALLED  : OS, -, shmat                    OSERR: EINVAL (22)Resolving the problem1) Disable ASLR temporarily (change is only effective until next boot):Run "sysctl -w kernel.randomize_va_space=0" as root.2) Disable ASLR immediately and on all subsequent reboots:Add the following line to /etc/sysctl.conf:kernel.randomize_va_space=0and then run "sysctl -p" as root to make the change take effect immediately.  

The general meaning is that the random address in LINUX memory causes the DB2 process to fail to attach to a shared memory object correctly. Why should we enable this feature in linux?
Keyword in Baidu randomize_va_space:

Linux Kernel introduces the concept of address space layout randomization, which is proposed for security considerations. Imagine if the address of the stack space is determined, then malicious code is very easy.
Through memory overflow code to access the stack space content, address space layout randomization is to make the process virtual space layout (mainly the starting address of each part) at a random location,
To reduce the possibility of attacks.

If the value in/proc/sys/kernel/randomize_va_space is 0, all randomization is disabled. If the value is 1, The mmap base, stack, and VDSO pages are enabled for randomization.

If the value is 2, heap address randomization is enabled on the basis of 1. Before heap address randomization is enabled, the starting position of the heap is followed by the bss segment of the application.

After learning about this, I suddenly remembered that SQL2043N would also appear when I used db2pd at ordinary times, and it would be normal after I ran it once, because db2pd obtained the database through attach db2 shared memory.

Therefore, db2pd is a lightweight tool with less impact on database performance.

Then the error is not displayed after kernel. randomize_va_space = 0 is set on the server.