|
Thanks for the performance 101 information. I have changed the subsystem to it's own pool and only allocated a little memory to it. This seems to have fixed the initial problem of them taking up all the system resources. Now I will go back and start "fixing" the rest of this system setup. It's sounds like from what you say our system is setup all wrong. I prefer to make only a change or two and "let it ride" for a bit to see the affect it has, as opposed to making a lot of changes and then encountering a problem and not knowing which change caused the problem. Thanks for all the info, it is greatly appreciated John -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Clare Holtham Sent: Friday, June 04, 2004 2:53 AM To: Midrange Systems Technical Discussion Subject: Re: Performance of batch vs other batch and interactive Yes! The first principle of performance tuning is to separate the workloads. Batch in its own pool (not in *Base), and interactive in its own pool. QCTL controlling. If you have lots of ODBC etc you can move that out of *Base also. Lots of important things happen in *Base anyway (file opens, subsystem monitors, client access, etc etc). Check that you have 'Expert Cache' enabled (WRKSYSSTS in Expert mode, then F11 and you should see *Calc not *Fixed against the pools.) If not, change it to *Calc. Over time this will monitor the workload in the pool and optimize it. If you have a mix of batch and interactive or anything else, it cannot do this! Having said this, I think you need to look at how you have these jobs set up anyway. You have given them quite a short timeslice - maybe a longer one would work better. And IBM still ships the QINTER class with a timeslice of 2000 (2 secs) which is way too long, you should change this to around 200 or 300 (you can calculate what it should be, but this is a guesstimate) which will give you better throughput in interactive, which will help generally too. And if you have these 10 batch jobs in their own memory pool, you can always 'constrain' them be reducing the memory. (Don't forget to turn off the automatic tuning though.) I also like the suggestion of having a way to make them wait when you need to! Hope this helps, cheers, Clare Clare Holtham Director, Small Blue Ltd - Archiving for BPCS Web: www.smallblue.co.uk IBM Certified AS/400 Systems Professional E-Mail: Clare.Holtham@xxxxxxxxxxxxxx Mobile: +44 (0)7960 665958 ----- Original Message ----- From: Richard Allen To: 'Midrange Systems Technical Discussion' Sent: Thursday, June 03, 2004 8:46 PM Subject: RE: Performance of batch vs other batch and interactive Here is some additional information, We have a model 720 with two processors 8g memory 400g+ DASD (Running at about 70% capacity) Each of the 10 jobs is doing it's own tasks and barely keeps up with the Data Queue feeding it, so I don't think we can combine them into less jobs. The 10 batch jobs are running in Subsystem pool 2 (same as the interactive and other batch jobs) Is this the problem? Should it be running in it's own pool with a smaller amount of memory? -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx Sent: Thursday, June 03, 2004 9:40 AM To: midrange-l@xxxxxxxxxxxx Subject: Re: Performance of batch vs other batch and interactive I'll preface my advice first, with a disclaimer. I'm a pure programmer and not a system administrator. That being said, I would try the following things. Also, you're asking for some pretty specific information without specific information about your system. Your fellow forum members might have more ideas if you describe you setup a little more (# of processors, subsystem setup, archive method, etc.) 1. If all 10 jobs are doing the same thing, then reduce the number of running jobs. This would probably be the most significant thing to do. This would be especially true on a multiple processor machine, if this applies. 10 jobs could occupy a significant portion of a 12-way processor, while one job might only use 1 processor max. 2. I think I'd increase the jobs run time from 1000 to at least 2000 ms. I'm guessing that the job can get more meaningful stuff done with the greater time, and the shorter times might tend to increase the overall overhead as the thread starts and stops. 3. Perhaps adjust the subsystems memory usage. I'm not sure if more or less would give you better results. 4. Can the actual process performance be improved? If you're using Infoprint Server to archive, make sure you aren't embedding fonts and such in the PDF file. > What I want is for the 10 batch jobs running in their own subsystem to take > the lowest priority when there is high CPU utilization caused from users > running interactive jobs and submitting their own jobs to batch. > > Any suggestions? > Thanks > John -- 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. -- 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.
As an Amazon Associate we earn from qualifying purchases.
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.