Prev
Next
Forums S3 Systems Administration

Performance Issues

Sort:
You are not authorized to post a reply.
Author
Messages
mwilliamson
Basic Member
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.
    kdcoate
    Veteran Member
    Posts: 44
    Veteran 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
      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
        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?

          You are not authorized to post a reply.