This saturday I update two dual VIOS from 220.127.116.11 to combinated 18.104.22.168 + 22.214.171.124 + 126.96.36.199 Fixpack.
one VIOS was using lot of memory (8GB of computational), svmon show that vio_daemon used 12 segments of application stack (it's a joke). In fact, the customer had modified /etc/security/limits with stack, data and rss unlimited for root. Solved by Setting default value and reboot VIOS. See IBM technote.
Why is vio_daemon consuming high memory on PoweVM Virtual I/O Server (VIOS)?
There is a known issue in VIOS 188.8.131.52 thru 184.108.40.206 with vio_daemon memory leak that was fixed at 220.127.116.11 with IV64508.
To check your VIOS level, as padmin, run:
If your VIOS level is 18.104.22.168 or higher, the problem may be due to having values in /etc/security/limits set to "unlimited" (-1). Particularly, the "stack" size setting, which exposes a condition where the system can be allowed to pin as much stack as desired causing vio_daemon to consume a lot of memory.
# vi /etc/security/limits ->check the default stanza
fsize = -1
core = -1
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1
In some cases, the issue with vio_daemon consuming high memory is noticed after a VIOS update to 2.2.3.X. However, a VIOS update will NOT change these settings. It is strongly recommended not to modify these default values as doing so is known to cause unpredictable results. Below is an example of the default values:
fsize = 2097151
core = 2097151
cpu = -1
data = 262144
rss = 65536
stack = 65536
nofiles = 2000
To correct the problem change the settings back to "default" values. Then reboot the VIOS at your earliest convenience.
If the stack size was added to the root and/or padmin stanzas with unlimited setting, it should be removed prior to rebooting the VIOS.
If there clients are not redundant via a second VIOS, a maintenance window should be schedule to bring the clients down before rebooting the VIOS.
SOURCE: IBM technote