We have two systems for SAP DB development: one 8-way system running SAP-DB version 7.3.0.25 Linux Red Hat 7.3 (2.4.18 from Red Hat) and a 2-way system running SAP-DB 7.3.0.29, SuSE 7.3 (2.4.20rc2)
In a parameter session, after having run param_checkall and noting the new calculated values, I observed that some calculated parameters change again after running param_commitsession and many other parameters display as a blank value. The behavior is consistent on sapdb 7.3.0.25 and 7.3.0.29. For example: The description of UKPS (as displayed by dbmcli command param_getfull) states that the calculation for UKPS is: UKPS = MAXCPU + 4. We have MAXCPU (naturally) set to 8 on our 8-way and 2 on our 2-way. I tried the following experiment and discovered that after the param_checkall step (see below) the value of UKPS was correctly set to MAXCPU + 4, but after the param_commitsession, it became 5 no matter what value of MAXCPU I tried: dbmcli -d DBT2 -u dbm,dbm dbmcli on DBT2>param_startsession dbmcli on DBT2>param_put MAXCPU 2 ( or 4 or 8) dbmcli on DBT2>param_checkall dbmcli on DBT2>param_extget UKPS UKPS int2 6 ( or 8 or 12) dbmcli on DBT2>param_commitsession dbmcli on DBT2>param_extget UKPS UKPS int2 5 As another example, TREEHASHLIST changes from the 16,000 range to 1. Many others have no values displayed all (most notably: _USER_PER_UKP, _SERVER_PER_UKP, IOSERVERTASKS). Is this behavior wrong, or am I missing something? I am concerned because UKPS parameter seems to impact the number of active Linux threads and thus possibly our ultimate scalability, although (I admit) I am confused about its precise definition. On our 8-way system, x_cons indicates 5 user threads and 5 non-user threads. ps -aef seems to validate this. If UKPS is the total number of Linux threads, then we appear to have 10, not 5 or 12. Can anyone explain this? _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
