IBM BRMS on system-i (i5) initial loading, performance

Well, this kind of slowdown can be caused by several things, and one of them is certainly "first load" time, especially if you are running in a memory-restricted system, or on a system that has very high CPU and/or disk arm utilization.

First, run the GO BRMS command in a freshly-signed on job, and check the job log for messages.  Locks, errors, damaged objects, communications errors, and other problems can create slowdowns like you describe, too.  Job log messages may give you a clue as to why.

Is it only BRMS that experiences this slow load time, or do other applications take a long time to load, too?  
Is this a new problem, or has it always behaved this way?

If you can identify the objects that are taking a long time to load, you can force them into memory using the SETOBJACC command.  This causes the objects to be loaded into memory.  Keeping an object from being paged out is trickier - you may need to create a private memory pool for the BRMS objects and for jobs that need to access them.

Here's an IBM article on the SETOBJACC comand:

http://www-01.ibm.com/support/docview.wss?uid=nas1dc0a2297bdaefddb86256d6c0069907f

This is a symptom of a system that is very short on memory or has very high  disk utilization (or both) for it's workload, or is improperly tuned.  Bear in mind that setting aside memory for BRMS objects in this fashion may exacerbate an existing problem, and may cause performance issues for other functions.

Sign on to a fresh session in the morning, and print out the results of a WRKSYSSTS command.

Next, in the samej job, use the DSPJOB command (or SysReq 3) to display programs on the call stack, open files, and objects locked to the job.  Also use the DMPJOB command to dump the job.  Do this before and after executing the GO BRMS command and compare the two sets of information to identify BRMS objects that have been loaded.

Now do another WRKSYSSTS and see if memory pool sizes have changed drastically.  This could be one reason for the slowdown.

Once you have identified likely objects, do a DSPOBJD to look at object sizes, and experiment with loading the largest object or objects first.

Feel free to post the results of your troubleshooting if you need more help resolving this issue.  If you do, please post your OS version and BRMS version.

- Gary Patterson

hello Garry Patterson,
thanks a lot for your explanation and advices. According your suggestion, i have checked pool sizes
before and after BRMS activation (i.g. GO BRMS) and found, that machine pool size enlarged after
execution of "GO BRMS".

Before:
 System    Pool-    Reserv.    Max.  -DB-Seiten--  --Nicht-DB--
  Pool   Größe(M)  Größe (M)  Aktiv  fehl.  geles  fehl.  geles
    1     1080,39    236,75   +++++    0,0    0,0    0,4    0,7
    2     4595,89     39,05     395    9,7  187,7   28,3   77,9
    3      493,99      0,00      52    0,0    0,0    1,0    1,6
    4     4633,77      <.01     749    1,3    3,6    6,0   15,0
Afer::
 System    Pool-    Reserv.    Max.  -DB-Seiten--  --Nicht-DB--
  Pool   Größe(M)  Größe (M)  Aktiv  fehl.  geles  fehl.  geles
    1     1378,88    236,85   +++++    0,0    0,0    0,0    0,0
    2     3334,18     39,04     395    0,0    0,0    0,0   10,5
    3      344,96      0,00      52    0,0    0,0    0,0    0,0
    4     5746,02      0,03     749    1,5    7,0    0,0    0,5
also this procedures arised,  during GO BRMS execution:
 Thread:   000002D3
 Art   Programm                 Anweisung         Prozedur
        Q1ACOND    QBRM                            _CXX_PEP__Fv
       Q1ACOND    QBRM          30                main
       Q1AROUT    QBRM                            _CXX_PEP__Fv
       Q1AROUT    QBRM          94                main
       Q1AOL      QBRM          208               q1aConditionExitMain
       Q1AAU      QBRM          102               checkFunctionUsage__25q1aFu >
       QSYFNUSG   QSYS          44                QsyCheckUserFunctionUsage
       QSYUSGUTL  QSYS          14                qsy_check_func_usage__FPvPc >
       QSYUSGUTL  QSYS          35                sy_check_usage_for_user__FP >
       QSYUSGUTL  QSYS          10                qsy_get_auth_users__FPP16_M >
       QSYMIUTLS  QSYS          8                 qsy_matauu__FP16_MAUU_Templ >

 

 


 

Assuming that GO BRMS is the cause (you'd need to repeat this exercise several times and see if the same amount of memory moves each time), Pool 1 and Pool 4 look undersized for this operation, at least as your system is currently configured.

Looks like autotune moved 300MB from pools 2&3 to the machine pool, and over a gig (!) into pool 4.  That seems like a lot for a menu.  I haven't noticed this behavior before when starting BRMS, but I'm not a daily BRMS user.

In order to move all this memory, the OS has to page a bunch of data out to disk to free up memory, and then resize the pools, and THEN load the BRMS objects from disk.  That's a lot of work.  If disk drives are slow or busy, or both, this can take some time.  High CPU utilization can also slow down the paging and resizing process.

Now:

• Is it only BRMS that experiences this slow load time, or do other applications take a long time to load, too?  
• Is this a new problem, or has BRMS always behaved this way?
• What OS version are you running on the AS/400?
• What version of BRMS are you running?
• **** Are you current on your OS and BRMS PTFs? *****
  
• Check the sizes of the various BRMS objects and see if you can account for the gig that moved to pool 4.
  

If BRMS really needs this much memory, then you may be stuck with poor BRMS startup performance unless you are willing to either add more memory, or re-tune just to improve BRMS performance.  Depending on your version, you may want to try using the Windows-based Operations Navigator BRMS Plug-in instead of the green-screen menu to see if it performs better in your environment.

I can't make specific tuning recommendations without doing performance analysis first, since every machine runs different workload is different.  If you will tell me your OS version, I can point you toward some system performance tuning resources specific to your version.

- Gary Patterson

additional requested  info :

- only BRMS "load time"  is focused,  critisised by Sysadmin.
- affected are all l BRMS commands (also dsplogbrm, wrkmedbr, if it is the first BRMS command  
  execution within a  timeframe (about 1 h)  
- OS/400 Version V5R4M0 ( with newest PTF level )
- same situation, problem on serveral systems (about 10).