Linux system limits when using ontape via rsh
So serverdb1 and serverdb2 were built the same way. Machines loaded with open Suse 13.2 and Informix 11.70.FC5XAAGE. serverdb2 built and made primary without ever needing to increase system limits (entries to /etc/sysctl.conf). serverdb1 built and instated today as a secondary, again with nothing in /etc/sysctl.conf. But look what pops into the online.log during a restore: 13:31:06 sql_listener: ASF_LISTEN failed 13:31:06 Attempting to bring listener thread down. 13:31:06 requested number of KAIO events (2048) exceeds limit (2). using 2. 13:31:06 Linux short of KAIO resources. 13:31:06 Please increase the value in /proc/sys/fs/aio-max-nr. cat /proc/sys/fs/aio-max-nr shows 65536 on both servers and yet serverdb1 wont perform a restore but serverdb2 did. So I add this to /etc/sysctl.conf just on serverdb1: fs.aio-max-nr = 1048576 And now it has restored. But so did serverdb2 even though its showing a limit of 65536 in /proc/sys/fs/aio-max-nr. Can anyone explain this behaviour? The only difference in the way the servers were built, is how the archive was initiated from one server to a restore on the other. The first server was simply built by archiving the other server, transferring the archive and restoring locally. The server exhibiting the issue received an archive via rsh piped into a restore.
Hi,
what value did you set in KAIOON environment when instance was started ? (or
is it just not set at all ?)
Is it only one instance active or is there another instance running (consuming
kaio resources ?
With KAIOON you can specify the amount of aio resources an instance will
consume. (running multiple instances,
you should set it to prevent one instance from having no resources left)
There might be also other processes consuming the resources (check with
/proc/sys/fs/aio-nr, which gives you the occupied number of resources).
Marcus Haarmann
----- Ursprüngliche Mail -----
Von: "STUART STEPHENS" <stuart.stephens@monitorsoft.com>
An: ids@iiug.org
Gesendet: Dienstag, 7. April 2015 15:13:30
Betreff: Linux system limits when using ontape via rsh [34925]
So serverdb1 and serverdb2 were built the same way. Machines loaded with open
Suse 13.2 and Informix 11.70.FC5XAAGE.
serverdb2 built and made primary without ever needing to increase system
limits (entries to /etc/sysctl.conf).
serverdb1 built and instated today as a secondary, again with nothing in
/etc/sysctl.conf. But look what pops into the online.log during a restore:
13:31:06 sql_listener: ASF_LISTEN failed
13:31:06 Attempting to bring listener thread down.
13:31:06 requested number of KAIO events (2048) exceeds limit (2). using 2.
13:31:06 Linux short of KAIO resources.
13:31:06 Please increase the value in /proc/sys/fs/aio-max-nr.
cat /proc/sys/fs/aio-max-nr shows 65536 on both servers and yet serverdb1
wont perform a restore but serverdb2 did.
So I add this to /etc/sysctl.conf just on serverdb1:
fs.aio-max-nr = 1048576
And now it has restored. But so did serverdb2 even though its showing a limit
of 65536 in /proc/sys/fs/aio-max-nr. Can anyone explain this behaviour?
The only difference in the way the servers were built, is how the archive was
initiated from one server to a restore on the other. The first server was
simply built by archiving the other server, transferring the archive and
restoring locally. The server exhibiting the issue received an archive via rsh
piped into a restore.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hi Marcus, I don't set that environment variable and the OS confirms it is not set: informix@serverdb1:~> echo $KAIOON There are no other instance's on this machine. What I have found is that this machine may not have been rebooted since it's first installation. Rebooting after performing OS updates has now shown the engine will restore even though "cat /proc/sys/fs/aio-max-nr" still shows 65536.
Hi Stuart, I don't think the restore is the issue as such: it's instance initialisation. How many instances do you have each on serverdb1 and serverdb2? If it's just one instance per machine I wonder how you got into the situation where there were only 2 unassigned KAIO events remaining. A reboot would certainly solve this. Docs on KAIOON are here: http://www-01.ibm.com/support/knowledgecenter/#!/SSGU8G_12.1.0/com.ibm.admin.doc /ids_admin_0301.htm These are 12.10 but 11.70 is identical in this area. I would recommend using this environment variable otherwise your instance will simply allocate half of what is remaining (presumably half of 65536) to itself and divide resources between the CPU VPs. With multiple instances on the same machine you pretty much have to set KAIOON otherwise whichever instance starts first grabs the lions share. Also did you run 'sysctl -p' after editing sysctl.conf? Ben.