AIX 6.1 migration: iostat and maxuproc change to their defaults? (Chris's AIX Blog)

The developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.

AIX 6.1 migration: iostat and maxuproc change to their defaults?

cggibbo Mar 1 2010 Comments (7) Visits (38554)

1 person likes this

Before migrating to AIX 6.1 you might want to check that ncargs is set to a value greater than or equal to 256 e.g.

# chdev -l sys0 -a ncargs=256

$ lsattr -El sys0 -a ncargs

ncargs 256 ARG/ENV list size in 4K byte blocks True

Let me elaborate.

Recently we migrated our LPARs from AIX 5.3 to AIX 6.1. Our AIX 5.3 systems were migrating from 5300-07-05-0831 to AIX 6.1 at 6100-03-01-0921.

During the testing of the migration process we noticed that some of the sys0 tunables were being reset to their default settings after the migration had completed. This was rather odd. I’d never had this issue during an AIX migration in the past.

We noticed the following attributes had changed.

fullcore - Was set to true before migration. Set to false after migration.

iostat - Was set to true before migration. Set to false after migration.

maxuproc - Was set to 2048 before migration. Set to 128 after migration.

The maxuproc value was of particular concern as it has an impact on the number of processes an application (user) can start. So when one of our SAP/Oracle test systems was unable to start because maxuproc was set to low, we were very puzzled. After we had discovered that maxuproc was incorrect, we changed it to the appropriate value and restarted SAP/Oracle successfully. We were then very determined to identify the root cause of this issue. We could not see any issue with our migration process (via nimadm) and decided to log a call with IBM.

IBM AIX support were able to assist us in determining the problem.

---------------------

After building more debug methods and performing further debug, which

involves multiple restore attempts, we figured out the root cause.

- During second phase of boot, when cfgsys_chrp run, it tries to set all

customized values for sys0 device. However, in this process, if and

when an error occurs, all customized values for sys0 will be reset to

allow the system to boot. (Instead of hang/crash).

- In the case of the customer's scenario, when cfgsys_chrp() tries to set ncargs

to value of 30, it fails with an error. Reason being, for

AIX 6.1, minimum value for ncargs is 256. If it is less than 256, the kernel

returns an error and then cfgsys_chrp "resets" all customized attribute

values for sys0 to their defaults.

---------------------

IN SETVAR()

Error changing v_ncargs,rc=-1

Error during SYS_SETPARMS, errno=22

Invalid value in SYS_SETPARMS

---------------------

# odmget -q "attribute=ncargs" PdAt

PdAt:

uniquetype = "sys/node/chrp"

attribute = "ncargs"

deflt = "256"

values = "256-1024,1"

width = ""

type = "R"

generic = "DU"

rep = "nr"

nls_index = 71

---------------------

http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/sched_mem_loadcontr.htm

ncargs

Purpose: Specifies the maximum allowable size of the ARG/ENV list (in 4

KB blocks) when running exec() subroutines.

Values: Default: 256; Range: 256 to 1024

Display: lsattr -E -l sys0 -a ncargs

Change: chdev -l sys0 -a ncargs= NewValue Change takes effect

immediately and is preserved over boot.

Diagnosis: Users cannot execute any additional processes because the

argument list passed to the exec() system call is too long. A low

default value might cause some programs to fail with the arg list too

long error message, in which case you might try increasing the ncargs

value with the chdev command above and then rerunning the program.

Tuning: This is a mechanism to prevent the exec() subroutines from

failing if the argument list is too long. Please note that tuning to a

higher ncargs value puts additional constraints on system memory

resources.

---------------------

As per discussion with Architect, this is not an issue with cfgsys_chrp.

However, when the limit for ncargs was changed, it should have changed

appropriately to handle migration cases. I need to follow up with the

team that handles this for a solution.

As per work around, before migration, make sure ncargs is

greater than or equal to 256.

Action Plan :

- More updates to follow about the solution after discussion with team

that handles ncargs.

---------------------

If anyone is interested, I’ll update my blog again, as soon as a fix is available. In the meantime check the ncargs value before you start a migration to AIX 6.1, just in case.

Comments (7)

Add a Comment

Quarantine this Entry

cggibbo commented Oct 15 2012 Comment Permalink

Hi SAPBASIS, Please review the following IBM technote: Kbiod using high CPU: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012846 I'm not sure it is related to your problem but it is worth a look.

SAPBASIS commented Oct 14 2012 Comment Permalink

pls find this output from topas. Name PID CPU% PgSp Owner kbiod 5308606 96.5 1.1 root

SAPBASIS commented Oct 14 2012 Comment Permalink

Hi Chris, We are also # lsattr -El sys0 SW_dist_intr false autorestart true boottype disk capacity_inc 1.00 capped true chown_restrict true conslogin enable cpuguard enable dedicated true enhanced_RBAC true ent_capacity 2.00 frequency 484000000 fullcore false fwversion ghostdev 0 id_to_partition id_to_system iostat true keylock normal log_pg_dealloc true max_capacity 2.00 max_logname 9 maxbuf 20 maxmbuf 0 maxpout 8193 maxuproc 16384 min_capacity 1.00 minpout 4096 modelname ncargs 256 nfs4_acl_compat secure os_uuid pre430core false pre520tune disable realmem 6291456 rtasversion 1 sed_config select systemid variable_weight 0 having issue with AIX migration to 6.1 from 5.3. We have issue that kbiod process using high CPU. Enable SW distribution of interrupts True Automatically REBOOT OS after a crash True N/A False Processor capacity increment False Partition is capped False Chown Restriction Mode True System Console Login False CPU Guard True Partition is dedicated False Enhanced RBAC Mode True Entitled processor capacity False System Bus Frequency False Enable full CORE dump True IBM,RG060917_d79e18_r Firmware version and revision levels False Recreate devices in ODM on system change True 0X036E83741EC6DB01 Partition ID False 0X036E83741EC6DB01 System ID False Continuously maintain DISK I/O history True State of system keylock at boot time False Log predictive memory page deallocation events True Maximum potential processor capacity False Maximum login name length at boot time True Maximum number of pages in block I/O BUFFER CACHE True Maximum Kbytes of real memory allowed for MBUFS True HIGH water mark for pending write I/Os per file True Maximum number of PROCESSES allowed per user True Minimum potential processor capacity False LOW water mark for pending write I/Os per file True IBM,7028-6C4 Machine name False ARG/ENV list size in 4K byte blocks True NFS4 ACL Compatibility Mode True 0fb5f73e-07fd-4d5d-88d5-72f47ab23840 N/A True Use pre-430 style CORE dump True Pre-520 tuning compatibility mode True Amount of usable physical memory in Kbytes False Open Firmware RTAS version False Stack Execution Disable (SED) Mode True IBM,0165178BF Hardware system identifier False Variable processor capacity weight False

cggibbo commented July 19 2012 Comment Permalink

Hi Marcelo, thanks for sharing. It's good to know the problem still exists, but it's also disappointing that the problem has not been resolved. Did you log a call with IBM? Did they give you a PMR number for the problem? Did they mention any specific APARs for the issue? Cheers. Chris

marcelosalinas commented July 18 2012 Comment Permalink

Just for reference... we just experienced the same problem migrating from 5.3 TL12-SP4 to AIX 6.1 TL6 SP6, so the problem still persists. MAXUPROC reset to default.

cggibbo commented Aug 22 2011 Comment Permalink

Take a look at the following APARs: AIX 6.1: IZ87406: MIGRATION DOES NOT PRESERVE MOST OF THE SYS0 ATTRIBUTES https://www-304.ibm.com/support/docview.wss?uid=isg1IZ74150 AIX 7.1: IZ87406: MIGRATION DOES NOT PRESERVE MOST OF THE SYS0 ATTRIBUTES https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87406 Seems that the problem persists even now?

f_b commented Aug 20 2011 Comment Permalink

Hi Chris, Good morning. We just experienced the same issue today, wherein the maxuproc has changed from 16384 to 2048 after the aix6.1 upgrade. Has IBM able to find out the root cause? Thanks in advance. Regards, FB

Blogs

Chris's AIX Blog

About this blog

Tags

Selected Tags

Related Tags

AIX 6.1 migration: iostat and maxuproc change to their defaults?

Send Email Notification

Quarantine this entry

Mark as Duplicate

Comments (7)