Lawson Performance Poor after upgrade

I'd check my CPU, paging and disk I/O to start.

run nmon and press c, d, m for cpu usage, disk usage and memory. See if you are running out of any of the resources. If your memory paging is going to the root drive move it off to the SAN, you'll see a big improvement in % of swap pages being used.

For Oracle are you using MTS that'll save you a ton of memory by sharing user connections.

you can also use iostat to check your % of disk usage, vmstat is also good for checking system state.

The timestats function can also be helpful for determining performance bottlenecks.

Performance Analysis: Using the timestats function

Article ID:101751

I would use MTS cautiously based on this discussion... I believe Lawson is pooling the use of DB drivers also.

http://www.dba-oracle.com.../shared_pool_mts.htm

We had similar issues on a different platform. There was patch that resolved. As I recall the issue had something rondo with a bug that allowed sibmissions of programs that are not supposed to run concurrently to execute even though the program was in needs recovery. Run a CU201, examine the job log and see if it is spending a huge amount of time creating the prin file even though the COBOL is finished.

Sent from my iPhone.
Please excuse the brevity and any typ0s.

On Jan 30, 2012, at 8:49 AM, forums-lsf-s3-sys-admin@lawsonguru.com wrote:

>
>
> S3 Systems Administration Forum Notification
>
> A message was posted to a thread you are tracking.
>
> Lawson Perfromance Poor after upgrade
> Posted by: slavo
> 01/30/2012 10:46 AM
> Does anyone have any suggestions on improving perfromace on Lawson system? We upgraded a few months ago and performance is really poor. We are using S3, version 9.0.1.6 on Aix 6.1 with Oracle 11g, IIS and AD LDS. Jobs like PR260 or AM275 are running twice as slow now. I checked and tuned WebSphere. Oracle DBA cannot find any issues on DB server either. Any thoughts and suggestions will be greatly appreciated.
> To view the complete thread and reply via your browser, please visit:
> https://www.lawsonguru.co...-poor-after-upgrade/
>
> You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
> To unsubscribe to this thread please visit your user profile page and change your subscription options.
>
> Thank you,
> LawsonGuru.com

You mentioned a database server, during the upgrade did you move the database off the application server? Lawson really doesn't like having a remote db server, it makes LOTS of little queries as it calls records instead of one or two big ones.

We went through that issue during our last hardware upgrade. Our DBAs and systems people were confident a remote database would work fine. We ended up having major issues until we put both boxes in the same location and made sure they had the fastest connections to the network possible.

Joel,

Having the db separate from the app server is not only just fine from a
performance standpoint, it is also recommended for anyone who can afford
two servers.

With that said, having your db accessed across a WAN or an entirely
different subnet NOT recommended, but separate servers are perfectly
acceptable.

Additionally, the Lawson database drivers do support configurable caching
of data to reduce transaction cost. Most performance issues can be
addressed through proper architecture and system tuning. Having the apps
and db on the same server is not the answer to performance issues. They
are almost always implementation specific and should be addressed with
unique solutions for any given situation. A one size fits all mentality to
system administration does not work with any ERP I've ever worked with.

I agree.  Here are some general comments from my DBA... We have been running the application and database on two separate servers now for close to 6 years or more without issues. 1.  You have to size your hardware correctly.   2.  You have to have your network configured correctly.   3.  You have to have your operating systems configured correctly.   4.  You have to run a world class database system like Microsoft or Oracle.

I mentioned it because we had almost the exact same symptoms with our hardware upgrade. We upgraded HP UX LSF 9.0.07 to IBM AIX 6.1 LSF 9.0.1.5.  We were working with LPS on the upgrade and we spent way too long troubleshooting the slow speeds in our dev environment.  Our network guys and DBAs ran their own queries and tests and swore everything was working fine.  We had to prove it by setting up temporary dbs in different loacations/machines.  Not fun.

Lawson's method of reading record by record in some jobs hurts.  Because our dev db is  going over a WAN it was a severe performance hit but we've got a couple other apps that do the same thing without having issues.  

Prod is in the same data center so its a minor speed hit having the remote db, but noticeable on a couple of the long running jobs that hit every employee and read multiple tables.  Our prod db is only 80GB or so, things may change as sizes grow. 

 

If you run on UNIX platform, you can run:

nmon -f -s10 -c 360 (this creates nmon snapshot ever 10 seconds x 360 which is an hours worth of collection, and create an .nmon file in the /tmp directory.

 

The go download nmon analyser spreadsheet from IBM Developerworks. (I attached here too)

 

Using this tool you can produce nice graphs of around 40 metrics.