Re: Strange Performance Problems

Just to throw out a few more possibilities:
What else is running on the machine when the test is running?
A complex interactive pgm could be killing your system performance.
or a web program chewing up cycles.... I've had some problems
w/Apache running cgi including sqlrpgle and sometimes the cursor
does not close right - i get a 64,000 page job log where sql is looping -
other jobs just crawl.
or anything updating or reading the same files you are updating? The fact
that
one test ran slow, but Fri & Wed were ok sounds like something else
going on in 1st test.
Are you calling other programs that used to be in memory (using return) and
now
setting on LR?
Are you calling any clp for each record processed.
You mentioned a change to the conversion pgms?
<quote>The only major change between the two upgrades is that I upgraded the
upgrade programs </quote> Are u saying these are someone elses conversion
pgms and you don't know what's inside them? (be very afraid..) Do they
understand
record locking?
You may have to do a trace to see what is going on here. One extra call to
another
program that sets on LR for a multi-million record file can kill this..
jim

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Mike Wills
> Sent: Monday, June 27, 2005 10:00 AM
> To: Midrange Systems Technical Discussion
> Subject: Strange Performance Problems
>
>
> I hope I can get you accurate information here.
>
> We have an LPARed 810 (we have 66% of the CPU) and just recently started
to
> notice some slow down. Last Thursday a job that normally takes 15 minutes,
> took 4 hours. Friday and Wednesday (without any changes in between) ran
> normally.Now this last weekend, we did a test upgrade of our ERP software
> and many of the jobs are now taking about twice the time. Here are some
> stats on this:
>
> Step 1: Last time I ran one job at a time and took about 12.5 hours. This
> time I ran 3 jobs at a time and it took 14.5 hours. Now to me, I would
think
>
> that I would save somewhere from 1/2 to 1/4 of the time by running more
than
>
> 1 at a time. I know that running 3 at a time will make the jobs run
slower,
> but 2 to 3 times slower? This is using straight reads and writes.
>
> Step 2 and 3: These two steps aren't complete yet, but the trend is the
same
>
> about 2 to 3 times slower. Last time I ran 4-6 jobs at a time, this time I
> ran 6 the entire time. I should not be seeing this trend based on the
> numbers I am seeing. This is using this SQL APIs for reads and writes.
>
> So my conclusion is that there is a problem with performance. Our Admin
says
>
> he doesn't see anything. I don't know what all he checked, but I am coming
> to you guys hoping for more ideas. The disk drives (according to
WRKDSKSTS)
> aren't being hit very hard. CPU has been running 95+ percent the entire
> time, even though job percentages in WRKACTJOB don't add up to 95+%.
> WRKSYSSTS looks to be normal as well. The Admin said that the cache
battery
> isn't low and there isn't a lot of CPU usage on the disk controller. To
our
> knowledge, no PTs or other configuration changes have occurred in the past
> few months.
>
> The only major change between the two upgrades is that I upgraded the
> upgrade programs (rather scary that this happens monthly) and some
tweaking
> on Lawson's config files, mostly to delivered settings. These settings
where
>
> tested with a single job in this upgrade and took about 1/2 the time to
> process. So I would have expected better performance this time, not worse.
>
> Any suggestions on where else to look for this bottle neck would be
greatly
> appreciated!
>
> -- 
> Mike Wills
> koldark@xxxxxxxxx
> http://mikewills.name
> Want Gmail? Email koldark+gmail@xxxxxxxxx to get on my waiting list.
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>