• Search Forums
    Advanced Search Topics Posts
Prev
Next
Forums Infor / Lawson Platforms S3 Systems Administration

Performance Issues

 3 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
mwilliamson
Basic Member Send Private Message
Posts: 7
Basic Member
1/7/2011 3:25 PM
We upgraded from LSF 9.0 to LSF 9.1, Apps 9.0 to Apps 9.1 in August and have been plagued by performance problems ever since.  We applied additional LSF patches and Lawson has helped with a few things on LSF but we recently found that  we were maxing out at 100% of our SAN disk capacity on ios reads, topping at around 1700. We had 6 disks. 2 days ago we added 2 more disks for a total of 8, now we see that we are not totally running @ 100% capacity but are spiking at around 3,000 ios.   We are a purely portal shop and heavily use LBI.  Our users report that when they change parameters on their jobs it is really slow.  So what we are wondering is does anyone have some SQL performance tuning recommendations?  Lawson's recommendation was to enlist professional services....They make you pay for everything... We are on Windows 2003, SQL 2005.
Deleted User
New Member Send Private Message
Posts: 0
New Member
1/7/2011 3:48 PM
Our experience has been that it's rarely a SQL Server problem. It's usually latm and WebSphere. Are your app & db on the same server?
We're in the process of upgrading our environment to LSF9.0.1.6 and we've experienced very slow response in changes to job parameters as well. We thought it was related to domain issues in our lower environment but now I'm concerned it may be more than that. Can you tell me the average time it's taking for your users to change job parms? I'm sorry I don't have any helpful information for you...
Jimmy Chiu
Veteran Member Send Private Message
Posts: 641
Veteran Member
1/7/2011 3:53 PM
There are many things you can do to tune SQL 2005. Some of the obvious things that can improve performance:

- Have dedicated "physical disk" assigned with a LUN only for SQL transaction log. (raid 10 is better than raid 5 for transaction log drives)
- Have dedicated "physical disk" assigned with a LUN only for the tempdb, also increasing the number of tempdb mdf files according to the amount of processors would help also. (same, raid 10 is better suite for tempdb)
- Your data/index filegroups should be on LUNs seperate from the transaction log/tempdb, physically speaking. (You can use raid5, or raid50 for data/index filegroups if storage capacity is a concern)
Increase # of available iscsi nic paths from SAN to the dedicated SAN network, thus, increasing the bandwidth.
- check your database server utilization, cpu usage, memory usage etc.
- what type of HDs you are using on the SAN? you mentioned 6 disks > 8 disks. Are they 15k SAS or 10K SAS or SATA? Can they be upgraded to higher performance drive?
- check your indexes, do they need reorg or rebuild?
just some of the things you can start looking into to increase your database responds.


Question:
What's the memory size of your portal server?
What's the memory size of your lawson application server?
On your app server, laconfig, what's the windows non-interactive desktop heap size?

John Cunningham
Advanced Member Send Private Message
Posts: 31
Advanced Member
1/7/2011 6:15 PM
When you see these issues, try to issue a stoplase - startlase, does this fix your issue temporarily?