OK, that completes some of the picture. The Quadrant and Compleo are most likely using quite a bit of SQL, as are the the stored procedures of course. That would explain quite a bit of the *MACHINE and *BASE faulting.

With Navigator, check out the advised indexes, and see if there are some indexes taking over about 10 seconds to build being created routinely. Consider building them permanently. Also, the prestart jobs QSQSRVR and QZDASOINIT should be moved into a shared pool away from *BASE. That will help a bunch.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 12/10/2012 10:03 AM, Porterfield, Sean wrote:
Well..... there is very little SQL in the ERP, but we do have add-on products using ODBC and stored procedures. I can't imagine they're a huge portion of the system load, but I don't know what all is in them (meaning I didn't write them, so they may not be optimized, but I don't know). I also don't know what's under the covers of all the utilities used on the system; we have various Quadrant products and Compleo running.
--
Sean Porterfield


-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Monday, December 10, 2012 10:51
To: Midrange Systems Technical Discussion
Subject: Re: Interactive memory pool...how much to allocate per user?

Well now....

The amount of memory in *INTERACT is not too low for the application that is running on this box, but there is not enough memory in *MACHINE and *BASE. The amount of paging / faulting for the system as a whole is
quite high. My first step would be to change the shared pool tuning a
bit to push some more memory into *BASE and *MACHINE. (at the expense
of *INTERACT) That might help push the total faulting down.

Based on what we see here, a guess is all the batch is running in *BASE. That should all be moved to a shared pool to get it out of *BASE. Also something is going on with the *MACHINE pool to have it paging / faulting so high. Are you sure there is very little SQL activity? The OS is working really hard at something.


Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 12/10/2012 9:36 AM, Porterfield, Sean wrote:
> *INTERACT is 4
> Work with System Status
> 12/10/12 10:34:23
> % CPU used . . . . . . . : 30.9 System ASP . . . . . . . : 2512 G
> Elapsed time . . . . . . : 00:12:13 % system ASP used . . . : 64.0984
> Jobs in system . . . . . : 85275 Total aux stg . . . . . : 2512 G
> % perm addresses . . . . : .257 Current unprotect used . : 58121 M
> % temp addresses . . . . : 7.306 Maximum unprotect . . . : 62127 M
>
>
> Sys Pool Reserved Max ----DB----- --Non-DB--- Act- Wait- Act-
> Pool Size M Size M Act Fault Pages Fault Pages Wait Inel Inel
> 1 2107.93 888.21 +++++ .0 .0 9.5 78.9 956.8 .0 .0
> 2 1889.24 35.40 387 20.0 217.1 34.3 233.8 24912 .0 .0
> 3 314.87<.01 105 .0 .3 7.7 17.6 198.9 .0 .0
> 4 27171.59 25.10 788 32.7 191.6 182.0 244.4 2637 .0 .0
> 5 4.34 .00 13 12.3 39.0 182.3 513.6 50.0 .0 .0
>
>
>
>
> Bottom
> ===>
> F21=Select assistance level
>
>
> Sean Porterfield
>
> -----Original Message-----
> From: Jim Oberholtzer
> Sent: Monday, December 10, 2012 09:37
> To: Midrange Systems Technical Discussion
> Subject: Re: Interactive memory pool...how much to allocate per user?
>
> Over a period of about 5 - 8 minutes what does the paging/faulting look like? If you can copy the text to the list showing all of the WRKSYSSTS output then the answer of how much memory for interactive is a bit easier to answer. The WRKSYSSTS screen will tell us quite a bit. (I always change the font to fixed when I paste it to keep columns in
> line) By the way, while your taking the sample, don't refresh
> constantly. Only refresh a couple of times during the observation.
> Refresh can actually alter the results of the sample enough to toss off any analysis.
>
>
> Jim Oberholtzer
> Chief Technical Architect
> Agile Technology Architects
>
>
> On 12/10/2012 8:28 AM, Porterfield, Sean wrote:
>> > No, almost no SQL in our environment. It did drop from 21 to 19 in the 30 seconds I watched (hence "about 20" in my response), but I don't know what is typical. Right now, it's ~27GB for 936 users.
>> > --
>> > Sean Porterfield
>> >
>> > -----Original Message-----
>> > From: Charles Wilt
>> > Sent: Friday, December 07, 2012 16:01
>> > To: Midrange Systems Technical Discussion
>> > Subject: Re: Interactive memory pool...how much to allocate per user?
>> >
>> > Sean,
>> >
>> > That seems pretty high to me....
>> >
>> > Do you by chance have a lot of SQL used by your interactive programs?
>> >
>> > Charles
>> >
>> >
>> > On Fri, Dec 7, 2012 at 12:16 PM, Porterfield, Sean< SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >
>>>> >> > I can't answer for recommendations, but with auto-tune enabled, we
>>>> >> > have around 20 GB (ignoring GB/GiB type math issues) for 953 signed on users.
>>>> >> > Stats according to WRKSHRPOOL and DSPSYSSTS.
>>>> >> > --
>>>> >> > Sean Porterfield
>>>> >> >
>>>> >> >
>>>> >> > -----Original Message-----
>>>> >> > From:midrange-l-bounces@xxxxxxxxxxxx [mailto:
>>>> >> > midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
>>>> >> > Sent: Friday, December 07, 2012 12:08
>>>> >> > To: Midrange Systems Technical Discussion
>>>> >> > Subject: Interactive memory pool...how much to allocate per user?
>>>> >> >
>>>> >> > All,
>>>> >> >
>>>> >> > Looking for a rough guideline of how much memory to initially
>>>> >> > allocate per user in the interactive pool.
>>>> >> >
>>>> >> > Found a older article that mentions 640KB...
>>>> >> >
>>>> >> > Heck even at 1MB per user....me thinks the 16GB (yes gigabytes)
>>>> >> > currently allocated is waaaayy overkill for the just over 300 users
>>>> >> > active..:)
>>>> >> >
>>>> >> > This is on a 9406-825 with 46GB of memory running v5r4.
>>>> >> >
>>>> >> > Thanks!
>>>> >> > Charles

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.